Security Settings

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

General page of the Server Manager

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 is 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 editions.

 

Server Key Pair

Digital Certificate Support

Cerberus FTP Server supports RSA, DSA, and Elliptical Curve (EC) keys. 

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

1. You can generate your 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 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 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, and 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 keys are in the same file then set this path to be the same as the Public Certificate. NOTE: The public and private keys can be in the same file. If your public and private keys 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. This file is generally used for HTTP/S connections and it is not necessary for FTPES and SFTP connections.
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 paths is recognized and readable with the given password. To view Certificate Information press the update button.

 

SSH Server Key Pair

Before Cerberus FTP Server Version 12, a change or renewal of the SSL Server Key Pair generates a new SSH Server Key Pair, requiring SFTP clients to cache the new host key to connect. From Cerberus FTP Server 12 to Cerberus FTP Server 13.0.2, Cerberus creates a permanent SSH Server Key Pair based on the first SSL certificate added to Cerberus. This SSH Server Key Pair is not easily changeable or editable. Future renewals or changes to the SSL Certificate Server Key Pair will not affect or change the SSH Server Key Pair, avoiding having to recache a new host key.

As of Cerberus 13.1.0, SSH Key Pairs can easily be edited and changed. In addition, having multiple SSH Key Pairs is now supported. You can enable one or more of the currently supported key types: RSA, DSA, ECDSA, EdDSA 25519 and EdDSA 448.

Administrators can generate host keys, export public keys, delete key pairs, edit the loaded keys, and control which keys are active. The features are accessed from Server Manager / Security / General as shown in the screenshot below.

This panel shows which keys are loaded in Cerberus.

Each key shows:

• Key Type
• Length
• An administrator customized notes field
• Fingerprint in multiple formats
• Path to the public and private key files.

In the example above, there are two loaded keys: RSA and ECDSA (Elliptical Curve). The default installation of Cerberus servers with SSH enabled will have just one key which will typically be the same type as the TLS certificate.

The panel allows Generating, Exporting, Editing and Deleting via the buttons on the top right. For details on each function, see below.

Generate SSH Key Pair

Clicking the Generate button allows creating a new Key Pair.

• Select a Key Type. Cerberus currently supports five key types: RSA, DSA, Elliptical Curve (ECDSA), ED25519 (EdDSA 25519), and ED448 (EdDSA 448). Note: the Edwards curve EdDSA key types are not currently available in FIPS mode.

Once the type is selected, one of two messages will be displayed in the gray status area at the top of the window as shown in the screenshot below:

• Generate a new TYPE SSH key pair
• Generate another TYPE SSH key pair

These messages indicate whether a new key pair will be created or an existing key may be replaced.

The notes field allows an Administrator to provide some context for the key pair; the field has no function in key signing. For example, this key may be used for a specific set of devices (networking hardware) or perhaps it is a temporary key for a specific user and the note could indicate the user’s name and when it can be removed. The field alleviates the need for external documentation and helps multiple administrators coordinate updates.

Key Length is populated with values specific to the type selected; the Edwards curves have no selectable length and this field will be disabled for that option.

Private Password allows setting a password on the created Private key. Cerberus recommends setting a password. Administrators should securely store the password in another location as they do other passwords as it cannot be recovered if forgotten.

Enable this SSH Key pair immediately: Select this box to enable this SSH key pair immediately or to replace existing the SSH Key pair of this type immediately.

When this option is unchecked, the key pair is just generated and saved. When the option is checked, Cerberus will also load the generated key pair as one of the available SSH Host Key Pairs (replacing the current key pair for that type if one exists). Note: if this is a new key pair, it must be activated (Activating SSH Host Keys) in the list of host keys before Cerberus will offer it to SSH clients.

Generate Keypair: Click the button to create the key pair. All generated host keys are stored in the Cerberus certificates folder as ssh-TYPE-YYYYMMDD_HHMMSS.pem; this naming convention avoids accidentally overwriting an existing key pair. This Privacy Enhanced Mail (PEM) file will contain both the public and private keys.

Export SSH Public Keys

To export the public portion of a loaded Key Pair, click the Pub Export button.

Key Type: From the drop down, select the key type you wish to export.

Public Key Path: Once a key type is selected, the public key path field will be populated with the full path to the selected public key.

Export Format: Defaults to 'RFC 4716' (SSH2), but Administrators can also select 'OpenSSH' and 'X.509 Subject Public Key Information' (RFC 3279) formats.

Click Generate Keypair to download the public key to the browser’s Downloads folder with a default name of ssh-public-hostkey-FORMAT_TYPE.pem

Manage SSH Keys

Click the Edit button to manage loaded SSH keys.

Key Type: Select a Key Type. If no key of the type exists, then a new key will be added; if one exists, it may be updated, replaced or deleted.

After selecting the type, the administrator can add or update the Notes, select or update the Public and Private keys and optional Password.

Check Key: Click Check Key as shown in the screenshot below to update the key pair.

If the values cannot be validated, the status text will contain a message, such as not finding the public or private key or a bad password.

Otherwise, one of three messages will appear:

Add New Key

If a new key is being added, the status text and button text say 'Add Key':

Manage SSH Keys: Add Key

Click Add Key to load the key values into Cerberus.

Update Existing Key

If an existing key is being updated, the status text and button text will say 'Keep Existing Key':

Manage SSH Keys: Update Key

Click Keep Existing Key to update the Notes and/or Password, but otherwise keep the existing key loaded in Cerberus.

Replace Key

If an existing key is being replaced, the status text and button text will appear as in the screenshot below:

Manage SSH Keys: Replace Key

Note: This type of update should be carefully considered and planned. Changing an existing host key will require SSH clients to accept a new fingerprint and may affect automated systems.

Click Replace Key to replace the loaded key in Cerberus.

Delete SSH Key

If the key type corresponds to an existing key, it can also be deleted. Clicking the Delete Key button will display a prompt as shown in the screenshot below. If the Delete button is clicked, then the key will be deleted from Cerberus but the key files will not be removed from the certificates folder, so are not lost.

Manage SSH Keys: Delete Key

Activating SSH Host Keys

When you add new SSH Host Keys, they must be enabled.

To enable (or disable) an SSK Key Pair, navigate to Server Manager > Protocols > SSH SFTP

SSH Security Defaults: Active Host Key

Any of the supported keys may be activated or deactivated; deactivated host keys will not be offered to SSH clients. If there is no host key loaded (as for DSA in the screenshot above) a warning info tooltip is shown. Even if these keys are activated, they will not be offered to SSH clients.

Note: Edwards curve EdDSA key types are not currently available in FIPS mode and will not appear in the list.

Like in Cerberus 12 to 13.0.2, future SSL certificate renewals or changes to the SSL Certificate Server Key Pair will not affect or change the SSH Server Key Pair, avoiding having to recache a new host key. If you do require a change to the host key and you are using Cerberus 12 or above, please reach out to Cerberus Support at support@cerberuftp.com for guidance. 

Advanced TLS Security Settings

As of Cerberus FTP Server 12, the TLS 1.2 and below, and TLS 1.3 sections, have information dropdowns. Click the blue icon to the right of Cipher Strings and Cipher Suites for a description of the format, defaults, and options for each string.

Advanced TLS tab of the Security page

As of Cerberus FTP Server 12.11, click Refresh Cipher List in the Testing section to see an updated list of cipher suites that will be activated by the enabled protocols and requested cipher strings. As you make changes to the various selections, just click refresh to see what the cipher list will contain.

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.

Use 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 on the list is the one most preferred by the client. Normally, the server honors the client's 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.

Prioritize ChaCha20-Poly1305 Ciphers

Administrators with users transferring files from older mobile phones without built-in AES support can select the checkbox 'Prioritize ChaCha20-Poly1305 Ciphers'. This option will allow configurations with 'Use Server Cipher Preference' also enabled to use ChaCha20-Poly1305 when a device offers it at a higher client preference due to power and speed concerns. NOTE: ChaCha20-Poly1305 is not available in FIPS mode.

Cipher Strings for TLS v1.2 and below

SSL v3.0	The SSL v3.0 protocol is considered obsolete and insecure. All clients should be restricted to TLS (preferably 1.2 or higher). The SSL v3.0 option has been available for rare situations where a legacy device or service can only use that protocol, and the network is tightly controlled and segmented. Enabling these options will prompt a server warning that your configuration is insecure. SSL v3.0 should be disabled.
TLS v1.0	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.0 is no longer secure and should be disabled.
TLS v1.1	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 is considered more secure. More information about the TLS v1.1 protocol can be found in IETF RFC 4346. TLS v1.1 is no longer secure and should be disabled.
TLS v1.2	TLS v1.2 is considered the minimum version of TLS to support highly secure traffic. TLS v1.2 is defined in IETF RFC 5246. As of Cerberus FTP Server 12.11, we introduce new capabilities for TLS 1.2 including ARIA and ChaCha20-Poly1305 cipher suites.

 

Cipher Strings for TLS v1.3

SSL v3.0

TLS v1.3 is the most secure version of TLS available in Cerberus FTP Server. TLS 1.3 is now a protocol option for TLS-based transfers, including FTP/S, HTTPS, and SOAP. TLS 1.3 will be automatically enabled for transfers and SOAP. At this time, TLS 1.3 supports five cipher suites: AES128 GCM SHA256 AES256 GCM SHA256 CHACHA20 POLY1305 SHA256 AES128 CCM SHA256 AES128 CCM8 SHA256 The last two require an ECDSA certificate and are not widely supported and therefore are not enabled by default. Although each configuration will be unique, in our testing, we have found OpenSSL 3.0 has a faster connection setup time resulting in lots of smaller transfers being faster overall than with 1.0.2. For maximum security, we recommend enabling TLS v1.3.

 

Upgrade Notes

As of Cerberus 12.11, Cerberus uses OpenSSL v3.0.x or above. Some security changes were made in OpenSSL 3 which will impact clients still enabling TLS 1.0 and TLS 1.1; these now only work at security level 0 except when RSA key exchange without SHA1 is used which Cerberus does not support. In addition, X509 certificates signed using SHA1 will no longer be trusted without setting the security level to 0.

Cerberus currently achieves similar goals as the security level using the Security Profiles dropdown. To maintain compatibility with previous versions of Cerberus, we automatically set the security level to zero. Administrators can override this by adding @SECLEVEL=x to the Cipher Strings where x can be 0 to 5.

Level 1 is OpenSSL’s default requiring at least 80 bits of security;

Level 2 requires 112 bits;

Level 3 requires 128 bits,

Level 4 requires 192 bits;

Level 5 requires 256 bits of security. 

For new installs, TLS 1.0 and 1.1 will be disabled by default.

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 

2FA (Duo Security Auth API)

2FA tab on the Security page of the Server Manager

 

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.

 

Server Verification

Verify Remote Host Certificates	Turning Server Verification off is global, overriding all other settings throughout Cerberus. Turning verification off is the less secure option and is only provided as a temporary fail-safe, such as a certificate issue causing a critical service outage.
Max Verify Depth	This determines how many issuer certificates Cerberus will follow when verifying. Administrators may increase this value if remote hosts have long certificate chains.
Additional Trusted Certificates	Administrators may provide a path to a PEM file containing additional certificates that Cerberus should trust when verifying remote servers. Use this option when Cerberus should trust certificates that cannot or should not be imported to the operating system certificate store.

 

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.