The FTP over TLS mode setting specifies whether the client is disallowed, allowed or required to send a STARTTLS command and switch to FTPES if it has originally connected over an insecure (unencrypted) connection.
The Certificate Management portion allows the virtual server administrator to perform several certificate-related tasks:
•Generate new self-signed certificate: allows you to generate your own X.509 certificate to be used when clients connect via SSL/TLS; clients will see this certificate as "untrusted" and they will need to manually accept and trust it the first time they connect.
•Generate certificate request (CSR): if you want to buy a trusted certificate from a Certification Authority (CA) you will need to generate a CSR; this process creates the CSR to be submitted to the Certification Authority as well as the Private Key that you will need to use later to import the CA's response. Make sure you do not lose the Private Key or you won't be able to import the signed certificate.
•Import Certificate: if you already own a certificate in PFX (PKCS#12) format you can use this function to import it; you can import both self-signed and CA-issued certificates as long as they are in PFX format.
•Export Certificate: you may export your full certificate in PFX format for backup purposes.
The External IP for PASV connections is required when the server doesn't have a public IP address and is run behind a NAT (Network Address Translation) device, such as a firewall for example.
The FTP protocol family is not very firewall-friendly, so if your server runs behind a NAT/PAT device you will need to specify the public (Internet) IP address for clients to connect to when they issue PASV data connection requests.
Of course this "public IP" should not be used with clients connecting from within your own private networks (LANs), therefore it is also recommended to populate the list of IP addresses and Networks to be considered LAN, so that the server knows how to behave in such case.
Since FTP(E/S) is a very verbose protocol family, it supports 4 in-session messages:
•Greeting message: sent to the client upon connection, before authentication
•Successful login message: sent to the client upon a successful authentication
•Failed login message: sent to the client upon an unsuccessful authentication
•Goodbye message: sent to the client when the client sends the "BYE" command, right before it disconnects