SSL/TLS

Web

Access to the Web GUI and portal is protected with TLS. After the first reboot of the virtual appliance a new self-signed TLS certificate was generated.

On the “SSL/TLS configuration for the web GUI” page a new TLS certificate for the Web GUI can be uploaded. The uploaded certificate should be a password protected PKCS#12 file (.p12 or .pfx). After importing a new certificate, the Web server must be restarted.

Attention

The uploaded PKCS#12 file should contain the complete certificate chain, i.e., end-user certificate and intermediate certificates. If the PKCS#12 file does not contain the complete chain, use the “TLS/SSL import wizard” Pro/Ent only to import the certificate. The “TLS/SSL import wizard” allows you to upload additional intermediate certificates and will check whether the chain is complete.

SSL/TLS

Tip

If the certificate is not in PKCS#12 format but in PEM format, you can use the built-in “PEM to PKCS#12” tool to convert the PEM files to a PKCS#12 file. Alternatively you can use openssl on the command line to convert the pem files to a PKCS#12 file.

Note

If the portal functionality is used, for example the PDF reply page, you are advised to install a TLS certificate issued by a trusted Certificate Authority.

SMTP Pro/Ent only

The MTA is protected with TLS. After the first reboot of the virtual appliance a new self-signed TLS certificate was generated.

On the “SSL/TLS configuration for the SMTP server” page a new TLS certificate for the MTA can be uploaded. The uploaded certificate should be a password protected PKCS#12 file (.p12 or .pfx).

The default TLS configuration in Postfix has been modified to exclude protocols and encryption algorithms that are deemed insufficient by NCSC-NL (i.e. those protocols and algorithms that are on the ‘Insufficient’ list). Examples of insufficient protocols and algorithms are SSL 3.0 and RC4. You can download a copy of the latest NCSC-NL TLS guidelines. The default configuration still allows the older TLS 1.0 and 1.1 protocols and 3DES and CBC algorithms for compatibility with legacy systems. These are to be phased out. If you don’t need interoperability with legacy systems, you can modify the Postfix TLS configuration using the /etc/postfix/main.cf configuration file. The relevant settings start with the smtpd_tls and smtp_tls prefixes.

Note that choosing a TLS configuration that is too strict will result in mail being sent without any TLS-based security at all. This is because mail servers usually apply opportunistic TLS on outbound mail, the idea being that unauthenticated TLS is still better than no TLS at all. If a mail server is configured to enforce TLS for sending a certain message, the message will bounce if the receiving mail server does not have overlap in the available TLS configuration.

Also note that, in RHEL 8 and later, cryptographic policies can be managed system-wide. It is possible that the policy in use on your system already enforces a modern configuration. See Chapter 4. Using system-wide cryptographic policies in the RHEL 8 documentation for more information.

CSR Pro/Ent only

Most Certificate Authorities (CAs) require a Certificate Signing Request (CSR) before the CA can issue a certificate. On the “Certificate Signing Request” page a CSR for the Web GUI and SMTP TLS certificate can be generated.

If a CSR is generated, a private/public key pair is generated together with some identifying information (for example the name of the company). After generating the CSR, the CSR should be sent to the CA. The CA then creates a new certificate using the data from the CSR. The certificate should then be imported into the CSR store. The certificate will then be combined with the stored private key and the certificate and private key can then be exported to a password protected PKCS#12 file which can then be imported using the “TLS/SSL import wizard”.

CSRs for which the certificate is not yet imported are printed in yellow. CSRs for which a valid certificate was imported, can be exported to a password protected PKCS#12 file by selecting the CSRs and clicking Download certificates.

TLS CSR

Certificate request procedure

The following steps will outline the procedure for getting a trusted TLS certificate from a CA using a CSR:

  1. Create a CSR

  2. Download CSR

  3. Send CSR to CA

  4. Import certificate generated by CA

  5. Download certificate and private key as password protected PKCS#12 file

  6. Import PKCS#12 file into Web GUI

Create A CSR

Click Create new CSR. On the “Create certificate signing request” page, enter in the request details required by the CA and select the length of the private key. The “Common name” should in most cases be set to the fully qualified domain name of the domain you are requesting. A public/private key pair will be generated and the CSR will be created. The CSR together with the public/private key pair will be stored in the CSR store.

Note

If a wild-card certificate, i.e., a certificate valid for all sub-domains, should be created, some CAs allow the common name to be set to *.example.com. Check the documentation of the CA on how to request a wild-card certificate.

Download CSR

Select the CSR, and click Download CSRs. Save the downloaded CSR.

Send CSR to CA

Send the downloaded CSR to the CA. It depends on the CA how the CSR should be delivered to the CA.

Import certificate generated by CA

The CA will generate a certificate using the details from the CSR. After the CA has issued the certificate, import the certificate into the CSR store by clicking the Upload certificate(s) button and selecting the certificate. After importing the certificate, the certificate and private key belonging to the certificate will be combined.

Download certificate and private key as password protected PKCS#12 file

Select the CSR for which the certificate and private should be exported and click Download certificate. On the “Export CSR certificates and keys” page, select a password for the PKCS#12 file.

Import PKCS#12 file into Web GUI

Import the downloaded PKCS#12 file using the “TLS/SSL import wizard”.