Many services on Linux use TLS certificates, but all of them are doing it their own way.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Certificate problems aren't always easily recognizable. Imagine trying to log in on an LDAP server and the connection times out without noting any error. While you may think there's a problem with your user account, it's more likely related to a certificate. Linux administrators have a hard time keeping up with the different ways to deploy TLS certificates. Bad certificates can cause problems, and the resolution depends on the root cause.
First, check log files to analyze the problem. You should also check network traffic with a tool like tcpdump to see on which port the connection occurs. Many protocols have a secure and an insecure port, which tcpdump helps identify.
Once you confirm the problem lies in the certificate, locate the specific files used by the service. There are always three components involved: the public key certificate, the private key and the certificate authority (CA) key file.
Every service has a specific configuration indicating where to find these files. On an Apache Web Server, for instance, your Linux distribution might use a configuration file with the name mod_ssl.conf, containing lines as following:
Generally, the file name ending in .crt is the server certificate file. This contains the public key, which is signed by a CA. The .key file contains the private key and is used as the identity of the server. Before doing anything else, make sure that the files to which the service refers exist where their configuration file expects to find them.
A common problem with the .crt file is that it uses an unknown CA. A public key certificate is signed by a certificate authority, which guarantees its authenticity and integrity. The CA needs to be an external server that is commonly known on the client. Administrators often generate a self-signed public/private key pair. That's like asking, "Who guarantees that you're really Sander van Vugt?" "Well, I'm Sander van Vugt and I say so, so you can trust me." That isn't too convincing, right?
On some services, finding errors that relate to self-signed certificates is easy. People connected to a Web server that uses a self-signed certificate; the browser gives a clear message; the end user can easily opt out.
Other services aren't as clear. An LDAP client that gets an untrusted certificate will fail, and the only way to find out why is to carefully analyze the log files for errors, indicating the problem relates to a CA. If it does, find where your server expects the CA certificates to be stored. Make sure you get the CA certificate you need and copy it over to that location. Try again, and it should work.
Another common TLS certificate-related error occurs when the name in the certificate doesn't match its target on the other end of the connection. Imagine that you tell your LDAP client to connect to the LDAP server on hnl.example.com. To make sure that works, the certificate should have the subject name hnl.example.com. If it doesn't, the connection will fail. Once you know where the certificate is stored -- typically in /etc/pki/tls/certs on the server that you want to use -- you can use the openssl command to get the subject name: openssl x509 -text < myserver.crt | grep Subject. If the name doesn't match, change how the client connects to the server.
Connections sometimes fail because the certificate expired. The command openssl x509 -text < myserver.crt will tell you when the certificate expires. For expired dates, create a new certificate.
About the author:
Sander van Vugt is an independent trainer and consultant based in the Netherlands. He is an expert in Linux high availability, virtualization and performance. He has authored many books on Linux topics, including Beginning the Linux Command Line, Beginning Ubuntu LTS Server Administration and Pro Ubuntu Server Administration.