Common Mistakes in SSL Certificate Management & Implementation

This document (7015502) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server

Situation

Common Mistakes in SSL Certificate Implementation
Frequent Pitfalls of SSL Certificate Creation & Implementation
Mistakes to avoid while installing an SSL Certificate

Resolution

SSL certificate management is a complex endeavor that can be difficult to do well. Below is a summary of common mistakes that are made when manually managing SSL certificate:

Choose a trusted certificate provider & check compatibility before installing the certificate:
The purchased certificate must be digitally signed by another certificate that is already in the trusted store of users' web browsers. This way, the web browser will automatically trust the certificate because it is issued by someone that it already trusts. If it isn’t signed by a trusted root certificate, or if links in the certificate chain are missing, then the web browser will give a warning message that the web site may not be trusted. So browser compatibility means that the certificate you buy is signed by a root certificate that is already trusted by most web browsers that your customers may be using.
Missing attributes from a Certificate Signing Request (CSR):
The Common Name attribute is very important and is commonly misunderstood. This is the DNS name that the client will use to connect to the server. In wildcard certificates, this can be *domain.com. Otherwise, it is generally recommended to fill in the Country Name, State or Province Name, Locality Name, Organization Name, Organizational Unit Name, Common Name, Email Address.
Not using text transfer mode when copying crt files to Linux systems:
This is probably one of the biggest catches when updating SSL Certificates, especially when they are generated in a Windows system and then copied to a Linux system. The ASCII text file formats are a little different. If you don’t use text mode file transfer in WinSCP or other secure copy tools you will find additional unwanted characters (^M) in your certificate files. This will corrupt the file and render it useless unless corrected. Fortunately this is very easy to correct. Either copy the files again using text mode file transfer, or alternatively follow the process outlined in TID 7014821 - How to remove CTRL-M (^M) characters from a file in Linux.
Not having the full CA key chain in the certificate:
It is important that the signed certificate (public crt) can be chained to the Root CA that is trusted by the browser. Often times, 3rd party Certificate Authorities will package Intermediate Certificate(s) that should be used as part of the certificate. For more details, see TID 7013103 - How to create a .pem File for SSL Certificate Installations.
Mismatching public key certificate and private key:
The private key and public key form a pair: the private key is used for encryption, while the public key can only be used for decryption. Verify the keys belong to one another - see TID 7015500 - How to determine if private key belongs to public key (certificate).
Certificate has expired:
See TID 7015501 - How to determine SSL certificate expiration date from the crt file itself

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.