Environment
Novell NetWare 6.5
Situation
NetWare FTP Server (NWFTPD.NLM) supports securing FTP sessions through a SSL tunnel. This is often referred to as "Secure FTP" but should not be confused with SFTP, which is part of the OpenSSH suite. FTP's use of SSL tunneling is defined by RFC 2228, and is often known as FTPS.
Sometimes administrators run into problems when trying to get Secure FTP working on NetWare. From the viewpoint of NWFTPD.NLM, these nothing that needs to be configured to make this work. A standard NetWare Server install will set up the certificate and services that are needed to support this. So from an NWFTPD viewpoint, "it just works" and if not, the problem is usually deeper than NWFTPD.NLM itself.
Given that disclaimer, below is a discussion that might prove helpful.
Resolution
Taken from statements made by a Novell Tech Support Engineer on the Novell user forums, and further refined for placement in this TID. The author is not an expert in SSL, but rather in FTP and has considerable experience using FTP over SSL with NWFTPD.NLM.
NetWare FTP server (NWFTPD.NLM) on NW 6.5 is capable of doing FTPS (aka secure FTP) per RFC 2228. This is one of those things that, as far as what the FTP server (NWFTPD.NLM) can control, it "just works" and there is almost nothing to configure. The only thing which can be done with NWFTPD to effect this is to use the setting which determines whether you will allow both secure and unsecured connections, or just secure ones.
SECURE_CONNECTIONS_ONLY=YES/NO
If it doesn't "just work" then here's the kinds of things to look into:
NWFTPD doesn't support 'implicit' SSL connections, only "explicit." Some FTP clients let you select which type. For this and other client configuration suggestions, see KB 10085857.
Beyond client configuration concerns, something could be wrong with NetWare's Certificate Server or the certificate itself.
NWFTPD is hard coded to use "SSL CertificateDNS - servername" (where "servername" is replaced by the actual server name). This certificate is created by a normal install. For example, if your NetWare server name is"SERV_1" then NWFTPD.NLM running on that server will expect to find "SSL CertificateDNS - SERV_1" in eDirectory. If that certificate doesn't exist, or has a problem, FTP will fail to do secure connections. If this server was installed from an image rather than the normal install procedure, it is possible that not all necessary components will be present in eDirectory. Similarly, if the server was installed into a tree of it's own, and later added to the production tree, it may not have created all the necessary objects in eDirectory. Running PKIDIAG.NLM may help correct this. Doing a new, full install directly into the target tree should correct things as well, though other troubleshooting by a NetWare Certificate Server Expert may be able to repair the setup.
Some people who want to verify SSL and Certificate Server functionality on a NetWare system do a https (secure) connection to Portal (https://ip_addr:8009) to that server, and then if that works they think all is well. However, portal uses "SSL CertificateIP" by default, so that test isn't directly comparable to FTP's use of SSL. For a comparable test, have portal use SSL CertificateDNS. For this, HTTPSTK.NLM must be loaded differently than the AUTOEXEC.NCF normally does it:
NORMAL:
load httpstk.nlm /SSL /keyfile:"SSL CertificateIP"
Beyond client configuration concerns, something could be wrong with NetWare's Certificate Server or the certificate itself.
NWFTPD is hard coded to use "SSL CertificateDNS - servername" (where "servername" is replaced by the actual server name)
Some people who want to verify SSL and Certificate Server functionality on a NetWare system do a https (secure) connection to Portal (https://ip_addr:8009) to that server, and then if that works they think all is well. However, portal uses "SSL CertificateIP" by default, so that test isn't directly comparable to FTP's use of SSL. For a comparable test, have portal use SSL CertificateDNS. For this, HTTPSTK.NLM must be loaded differently than the AUTOEXEC.NCF normally does it:
NORMAL:
load httpstk.nlm /SSL /keyfile:"SSL CertificateIP"
TO TEST THE OTHER CERTIFICATE:
load httpstk.nlm /SSL /keyfile:"SSL CertificateDNS"
(note that the quotes are part of the syntax)
If establishing a secure portal connection fails only with SSL CertificateDNS, then the problem is specific to that certificate. If it fails both ways, it could be a more general SSL or Certificate Server issue. Running PKIDIAG.NLM to test and repair certificates may help, either way.
There is no need to import any certificate to the client. NWFTPD doesn't need to receive a cert from the client. It shouldn't hurt anything to have a client side cert, but it doesn't actually accomplish anything when used with NWFTPD.
load httpstk.nlm /SSL /keyfile:"SSL CertificateDNS"
(note that the quotes are part of the syntax)
If establishing a secure portal connection fails only with SSL CertificateDNS, then the problem is specific to that certificate. If it fails both ways, it could be a more general SSL or Certificate Server issue. Running PKIDIAG.NLM to test and repair certificates may help, either way.
There is no need to import any certificate to the client. NWFTPD doesn't need to receive a cert from the client. It shouldn't hurt anything to have a client side cert, but it doesn't actually accomplish anything when used with NWFTPD.