Security Settings

The security settings page allows the administrator to configure all aspects of Cerberus FTP Server SSL/TLS and SSH security.

General

Enable SSL/TLS

This must be enabled to allow secure access to the server. NOTE: A certificate and private key must be available before TLS/SSL encryption will be available.

Enable FIPS 140-2

Enable the FIPS 140-2 certified encryption module for Cerberus FTP Server. Selecting this option enables encryption using only FIPS 140-2 certified algorithms. Only available in the Professional and Enterprise edition.

 

Server Key Pair

 

Digital Certificate Support

Cerberus FTP Server supports RSA, DSA and Elliptical Curve (EC) keys. Support for elliptical curve ciphers with FTPS and HTTPS is available with Cerberus FTP Server 6.0 and higher.

There are generally two options for obtaining a digital certificate (with private key):

1. You can generate your own self-signed certificate using the Cerberus Create Cert button.
2. You can obtain a certificate from a recognized certificate authority (CA)

Which option is more appropriate really depends upon your goals. If you just want to make sure that client and server connections are securely encrypted, then a self-signed certificate is all you need. Self-signed certificates have the benefit of being easily created through Cerberus and are completely free.

If your goal is to make sure that your clients can verify that the server they are connecting to is legitimate, and to ensure that clients do not see any warning messages about being “unable to verify the server”, then you will need to use a certificate signed by a trusted CA. You will have to contact one of the recognized CAs (such as Comodo, Thawte, Verisign, GoDaddy) and request a server certificate. Take a look at our help page on generating Certificate Signing Requests for more information about using a CA-signed certificate.

A note about secure connections: Cerberus supports FTPS, FTPES, SFTP, and HTTPS encryption. To establish a secure connection you must connect to the server with a client that supports one of those secure methods. For secure FTPES, FTPS, or SFTP, this will require a dedicated FTP client, not a web browser. No web browsers natively support any type of secure FTP.

We have documentation available that walks you step-by-step through the process of using a self-signed certificate or importing a certificate from a third-party certificate authority.

Certificate Path

The full path to your public certificate. The public certificate is exchanged with the client during TLS/SSL encryption and is examined by the client to verify the server. Supported key types include RSA, DSA, and Elliptical Curve keys.

Private Key Path

This is the server’s private key. The private key is used to encrypt messages to the client. The client can use the server’s public key to decrypt messages encrypted with the server’s private key. The private key is not sent to the client. If your public and private key are in the same file then set this path to be the same as the Public Certificate.

NOTE: The public and private key can be in the same file. If your public and private key are in the same file then set this path to the same path as your Public Certificate path. Cerberus understands both DER and PEM encoded certificate formats.

Needs Key Password

Check this option if the digital certificate is encrypted. Enter the key password used to decrypt your digital certificate.

CA Certificate Path

A file containing a PEM-encoded list of Certificate Authorities with which to verify client certificates against. Cerberus FTP Server will also use this file to load and send the entire certificate chain for the server certificate when a client connects. Many CAs call this a CA bundle file.

Create Self Signed Cert

Cerberus will generate a Self-Signed Certificate that will allow encrypted connections.

Verify

Cerberus will attempt to verify that the certificate at the Public and Private key path is recognized and readable with the given password. To view Certificate Infomation press the update button. 

 

Advanced TLS Security Options

 

 Security Profiles

These are common security settings. Selecting a security profile from the dropdown list will immediately modify the server’s security settings to match that profile.

 

Server Cipher Preference

During the SSL/TLS session negotiation, the connecting client sends an ordered list of cipher suites to the server. The first suite in the list is the one most preferred by the client. Normally, the server honors the client preference by selecting the suite most preferred by the client among the list of suites that both the client and server support.

If this option is selected, the server selects the suite that the server itself most prefers among those that both the client and server support. This can be used to, for example, enforce that the strongest cipher that both the server and client support be used for the connection.

 

SSL/TLS Protocols

SSL v3.0 protocol is strongly not recommended because it is considered obsolete and insecure. Although SSL v3.0 is the latest available SSL version, SSL is a predecessor of TLS so it is recommended that clients use the latest available TLS protocol instead of SSL when possible. Furthermore, the only scenario where SSL v3.0 should be considered as an option is if the network is very tightly controlled and connections from these legacy services (that won’t or can’t upgrade) have to be allowed.

TLS v1.0 was released as the first version of the TLS protocol in 1999 and published as IETF RFC 2246. Although usage of TLS v1.0 is fairly common, TLS v1.0 is very similar to SSL v3.0 and requires workarounds in both the client and server to work securely for all cipher suites. TLS v1.0 is also unable to use modern cipher suites that offer greater security and efficiency.

TLS v1.1 is the second version of TLS and was released in 2006. TLS v1.1 fixes some security problems in TLS v1.0, such as removing the need for many of the workarounds built into clients and servers. Furthermore, many deployed clients and servers of TLS v1.0 do not implement these workarounds, so TLS v1.1 is a good improvement over TLS v1.0 and considered more secure. More information about the TLS v1.1 protocol can be found in IETF RFC 4346.

TLS v1.2 is the latest available and most secure version of TLS and is recommended for clients to implement. Furthermore, TLS v1.2 is considered the new norm for highly secure websites and is the most used version of TLS. TLS v1.2 also uses the latest available TLS protocol as defined in IETF RFC 5246.

SSL/TLS Ciphers

The ciphers that Cerberus uses during secure connection negotiation for TLS/SSL can be controlled through a text string. The Test button will list the ciphers available with the given string.

An example string:

EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!CAMELLIA

The string follows the same cipher string format as the OpenSSL ciphers string 

 Duo Security Auth API

 

Enable DUO 2FA Integration

Duo combines modern two-factor authentication with advanced endpoint security solutions to protect users from account takeovers and data breaches.

Use this section to integrate the HTTP/S web client with DUO Security's 2-factor authentication API. Enabling this integration will replace the default HOTP-based one-time password system with DUO's implementation.

You may review our Enabling Two-Factor Authentication document for the steps to enable this feature.

Client Certificate Verification

 

About Certificate Authorities

You only need to worry about setting up and validating against a certificate authority if you (the server) want to authenticate the certificates coming from your FTPS and HTTPS clients. If you are not concerned with verifying your FTPS and HTTPS clients using certificates, then you can safely ignore all of the certificate authority configuration information. Just select the No verification setting (the default). 

Note: Client certificate verification is completely separate from SSH SFTP public key authentication.  SSH SFTP public key authentication is configured on a per-user basis.

Cerberus FTP Server can be configured to require FTPS and HTTPS clients to verify themselves using digital certificates. When given a CA file, Cerberus will verify that the client certificate is signed and valid for the given certificate authorities. Cerberus will also make sure the certificate hasn’t been revoked if a CRL is specified. 

This feature is only available in Cerberus FTP Server Professional and Enterprise edition and currently only applies to FTPS, FTPES, and HTTPS connections.

No Verification

This is the default option. Cerberus will not require nor will it verify digital certificates

Verify Certificate

Cerberus will attempt to verify that the certificate presented by the client is signed and valid. It will compare the certificate against the certificate authorities present in the CA Certificates File. Any FTPS or HTTPS connection attempts without a valid certificate will be denied when this option is selected.

CRL File

A file containing a PEM or DER-encoded list of key serial numbers that have been revoked. Note, the CRL must have been signed by the CA certificate.