SSL certificates are a common part of system administration, but how much do you know about how SSL certificates work? Sure you've installed certificates before, but what makes the client trust them? Let's look at some of the basics to help understand how SSL certificates function and how to resolve some common types of issues.
Why use SSL certificates?
Before we get into the details, let's review the importance of SSL certificates. At its core, traffic that crosses the network is typically not encrypted. There may be VPNs or other layers that do encrypt the data, but generally speaking, data crossing the local LAN or the open internet is unencrypted and viewable by those who can tap into the connections. However, connections secured by SSL/TLS and SSL certificates provide end-to-end encryption that makes it nearly impossible for data in transit to be viewed by a third party. Specifically, SSL certificates provide a few things:
- Data encryption between the server and the client to prevent snooping
- Assurance that the packets between the server and client are not tampered with
- Confirmation that the server you're talking to is who it says it is (i.e. that your bank's website is actually being served by their servers)
Based on this, it's easy to see the advantages of using SSL to secure client-server interactions.
The most important concept in SSL certificates is the idea of certificate chaining. All SSL certificates are issued by another certificate. This creates a certificate chain, in that the issued cert is tied to the issuing cert in a parent/child type relationship. Typically, public-facing certificates have 3 levels, where a root Certification Authority (commonly shortened as CA) issues a certificate to an intermediate CA, and that intermediate CA is what issues the final cert that gets installed on the server. Visually, you can see the certificate chain by viewing the "Certification Path" tab on a certificate’s properties in Windows. For example, here is the chain for www.microsoft.com
Here, the DigiCert root certificate issued an intermediate certificate named "Microsoft IT TLS CA 4". That, in turn, issued the final cert for the website www.microsoft.com
. For the final certificate to be trusted by the client, all certificates in the chain must be valid. For example, if the intermediate certificate expires, the website certificate will be untrusted, and clients connecting to that site would receive an error. Additionally, the root certificate at the top of the chain must specifically be trusted by the client. In Windows, this is done by adding the root certificate to the Trusted Root Certification Authority store for the computer. For safe, public root CAs, this is done through an automatic update process. For private CAs, such as an Active Directory Certificate Services deployment, this may need to be done manually or deployed via GPO.
When the root certificate is trusted by the client, and all certificates in the chain are valid (for example, not expired or revoked), the final certificate is considered safe and trustworthy. Any break in that chain, such as the root CA not being trusted or an issue with the intermediate cert, will invalidate the server's certificate.
Contrary to a chained certificate, self-signed certificates are issued to themselves rather than by a CA. Here's an example of the Certification Path for a self-signed certificate for "www.example.com
Since there's no issuing CA to verify the server certificate with, there's no way to trust that a self-signed certificate is legitimate. With no issuer to validate them, anyone can generate a self-signed certificate for any server name, which is what makes them untrustworthy.
Self-signed certs are usually automatically generated by software when an SSL certificate is required. Ideally, self-signed certs should be replaced by a certificate that's correctly issued by a trusted authority.
Another key component of SSL certificates is the validity of the certificate from the client's perspective. There are 3 primary things that clients look for in an SSL certificate.
First, does the name on the certificate match the server's advertised name? For example, if you visit www.microsoft.com
, the certificate must present that domain name as a valid name. This protects against a few different types of security issues. If you are attempting to connect to www.microsoft.com
, but are presented a certificate for another domain, like www.proxyinterceptor.com
, the client will not trust the connection because the server's certificate doesn't match the site's URL. This helps prevent against attacks where users get redirected to a malicious server (through malware, a DNS hijack, or something similar).
Second, is the certificate expired? All certificates have an expiration date, typically 1 or 2 years after they are first issued. This requires the server with the certificate to re-validate and get a new certificate from its issuing authority periodically. This provides an occasional check where the certificate issuer can ensure that the system is still valid and should be allowed to keep using the certificate.
Third, has the certificate been revoked? All certificate issuers have the ability to revoke a certificate for various reasons. For example, if the key of a certificate is stolen by a hacker, you can no longer trust that communications protected by that certificate are secure. In that case, the certificate would be revoked. After revocation, clients will no longer trust the affected certificate.
You may come across SSL issues and errors in your day-to-day administration or if you run security scans against your systems. Some of the most common issues, specifically with internal systems, are:
- Common name or domain name mismatch - This type of error is seen when the name on the certificate doesn't match the server name that the client is connecting to. For example, some software will install with a certificate issued to "localhost", but the clients actually connect using the server name. Since the certificate name doesn’t match the name the clients are using, it is invalid. A new certificate would have to be created that contains the server name to resolve this issue.
- A variant of this issue is where the certificate is issued for the server's name, such as MYAPPSVR01, but clients connect using a friendlier name, such as myapplication.contoso.com. If the clients are using the friendly name to connect, that name is what needs to be on the certificate.
- Self-signed certificate - Self-signed certificates are inherently untrustworthy because clients have no way to validate if the certificate is valid. With a properly chained certificate, clients trust the intermediate and root CAs, providing a path to trust the server's cert. Although it's better to not use self-signed certificates at all, it can be added to the Trusted Root Certification Authorities store on the client if you know it's trustworthy. The best approach to resolving this issue is to use certs from a public authority like DigiCert or an internal infrastructure like Active Directory Certificate Services.
- Untrusted certificate authority - Similar to a self-signed certificate, if the certificate chain is broken and one of the issuers isn't trusted by the client, the final certificate presented by the server can't be trusted either. To resolve this type of issue you may need to create a new certificate from a valid authority, or if the certificate is already from a valid issuer, ensure that the proper root certificate is added to the Trusted Root Certification Authorities store.