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.
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” to import the certificate. The “TLS/SSL import wizard” allows you to upload additional intermediate certificates and will check whether the chain is complete.
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.
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.
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
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.
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.
Certificate request procedure
The following steps will outline the procedure for getting a trusted TLS certificate from a CA using a CSR:
Create a CSR
Send CSR to CA
Import certificate generated by CA
Download certificate and private key as password protected PKCS#12 file
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.
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”.