You are here

LINUX CA Certificate Deployment

Creating an in house signing [aka CA] certificate is a common practice; this allows you to generate free cerficates for internal use. For Windows hosts distributing this CA certificate to all the clients and relevant servers can be accomplished using Active Directory GPOs. Certificate management on LINUX hosts on the other hand has always been a swamp of tedium where the certificates often need to be configured into each client or service. Recent distributions have eased this process considerably by including a quasi-standardized set of scripts and certificate store locations. Both CentOS and openSUSE bundle this tool in an RPM named ca-certificates.

Assuming you are using one of these modern mainstream distribtions installing a CA is as easy as copying the PEM file to the appropriate directory and running the update-ca-trust script

[root@myserver ~]# cp myCAcert.pem /usr/share/pki/ca-trust-source/anchors/
[root@myserver ~]# update-ca-trust

Aside: You should probably take a look at man update-ca-trust, it contains a lot of details.

Once the certificate is installed and the CA trust bundle has been updated you should be able to connect to SSL/TLS enabled sites without the dreaded "Verify return code: 19 (self signed certificate in certificate chain)" message.

Legacy Application Compatibility

One issue you will likely encounter with the modern certificate store is that older applications have a variety of places they look for certificates - these paths are sometimes hard-coded into the applications or set via obscure configuration directives. Fortunately update-ca-trust acknowledges this issue - you can enable legacy compatibility.

[root@myserver ~]# update-ca-trust enable

What this actually does is create symbolic links with the appropriate names in places like /etc/ssl/certs/ where legacy applications often expect to find certificate information. These links will point to the files maintained by the scripts which are part of the current certificate scheme.

[fred@myserver ~]# ls -l /etc/ssl/certs/
total 16
lrwxrwxrwx  1 root root   49 Mar 25 08:45 ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

Legacy compatibility is not perfect, you will still have the odd application or service that needs to be pointed directly at the certificate files; there always seems to be something that is-yet-even-more-legacy - however most things it will just work, which we like.

Testing A Connection

Using the openssl command it is possible to TEST HTTPS, XMPP, SMTP, and IMAP encryption. This is vastly superior than attempting to test with a protocol specific client - openssl will clearly report the error or success, which many clients will not reliably do. Note that in these examples for testing we do not specify a -CAfile or -CApath, that is the point - you should be able to establish secure connections without referencing your CA certificate files.


openssl s_client -starttls smtp -connect  -crlf
    Verify return code: 0 (ok)


openssl s_client -starttls imap -connect  -crlf
    Verify return code: 0 (ok)


openssl s_client -ssl3 -connect  -crlf
    Verify return code: 0 (ok)


openssl s_client -starttls xmpp -connect -crlf 
     Verify return code: 0 (ok)


openssl s_client -connect
     Verify return code: 0 (ok)


openssl s_client -connect
    Verify return code: 0 (ok)


Even with legacy compatibility enabled Postfix does not pick-up on the CA certificates. Nor does it readily indicate where it is looking for them. A work around is to simply set the service to use the legacy certificate bundle - do it once and you can forget about it.

Note: This example first disables, by commenting out, the existing CAFile configuration, if any. Then it sets the value of smtp_tls_CAfile. You should always configure postfix using the postconf command, this is less error-prone than manually editing the configuration file - and it is easier to script.

[ ~]# postconf -# smtp_tls_CAfile
[ ~]# postconf -e smtp_tls_CAfile=/etc/ssl/certs/ca-bundle.crt
[ ~]# service postfix reload

Now assuming you have smtp_use_tls = yes and the destination server is correctly configured delivery of mail sent from the local host via postfix will be correctly secured and without filling your logs with "certificate verification failed for..." messages.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer