Solution to CentOS Server TLS Certificate failure

Solution to CentOS Server TLS Certificate failure

Many Linux servers use TLS certificates, but they work in different ways.

Certificate problems are not always easy to discover. If you want to log on to an LDAP server, the connection times out without notifying you of any errors. You may think this is a problem with the user account, but it is often related to the certificate. Linux administrators have a headache in deploying TLS certificates in different ways. A bad certificate may cause problems. Solving the problem depends on the root cause.

First, check the log file to analyze the problem. You also need to use tools like tcpdump to check which connection port causes network congestion. Many protocols have a secure and non-secure port. tcpdump can help you identify the port.

Once you confirm that the problem lies in the certificate and locate the specific file used by the server, the file always contains three components: Public Key Certificate, private key and certificate authorization (CA) key file.

Each service has a specific configuration file to search for these log files. For example, for Apache Web Server, your Linux distributed Server may use a configuration file named mod_ssl.conf, which contains the following code lines:

SSLCertificateFile/etc/pki/tls/certs/myserver. crt

SSLCertificateKeyFile/etc/pki/tls/private/myserver. key

Generally, the server certificate file is suffixed with. crt. It contains the CA signature public key .. The key file contains the private key of the server identity. Before doing other things, make sure that the server file exists in the configuration file you want to find.

A common problem with. crt files is the use of an unknown CA. The public key certificate authorized by the certificate ensures the reliability and integrity of the file. The customer knows that the CA needs to act as an external server. Administrators usually generate their own public/private key pairs. This is like asking "who can ensure that you are a real Sander van Vugt ?" "I'm Sander van Vugt. Now that I have said this, you can trust me ." This method is not convenient, right?

In some services, it is easy to find errors related to self-signed certificates. People use self-signed certificates to connect to the network server. The server provides a clear text, and end users can exit easily.

Other service errors are not so obvious. If an LDAP client obtains a non-trusted Certificate, the connection fails. The cause of the problem is to carefully analyze the log file to find the CA-related error. If yes, find the folder where the server stores the CA certificate. Make sure that you have found the required CA certificate and copied it to overwrite it to the original location. Try again and it will take effect.

Another common TLS Certificate-related error occurs when the certificate name does not match the target terminal on the other end of the connection. Assume that you have notified the LDAP client to connect to the LDAP server hnl.example.com. To make sure the certificate takes effect, a topic name hnl.example.com is required for the certificate. If no topic name exists, the connection fails. Once you know where the certificate is stored, it is generally stored in the/etc/pki/tls/certs file on the server. If you want to use it, you can use the openssl command to get the topic name: opensslx509-text <myserver. crt | grep Subject. If the name does not match, you need to change the client connection method to the server.

The connection will also fail because the certificate expires. Use the openssl x509-text <myserver. crt command to notify you of the certificate validity period. The administrator needs to create a new certificate before the certificate expiration date.