Certificate management is the practice of managing digital certificates, such as SSL certificates. It involves managing these certificates throughout their lifecycle, from the day they’re issued by a Certificate Authority and installed by the end user, to the day they’re revoked or renewed. Throughout this lifespan, IT admins monitor these certificates for issues, so that if necessary, they can be replaced with minimal interruption.
Many automated certificate management programs can handle the above tasks for you. You don’t need a certificate management program to handle digital certificates, but these services can be very useful, especially if you’re managing hundreds or thousands of certificates.
But before we get any further, let’s discuss the basics of digital certificates and how they operate.
Digital Certificates
Digital certificates, or x.509 certificates, underpin trust over the internet. A certificate issued by a trusted Certificate Authority verifies that someone is who they claim to be, and facilitates secure communications and transactions between two parties.
Every digital certificate is tied to an asymmetric key pair, consisting of a public key and a private key. The public key is displayed on the certificate for all to see. Anything encrypted by a particular public key can only be decrypted by the corresponding private key. Because this private key is known only to the owner of the certificate, data thus encrypted can only be accessed by the owner of the certificate.
Let’s dig in with a common example: the SSL handshake.
The SSL Handshake: How Certificates Work in Practice
Most websites you visit are HTTPS websites; the ‘S’ stands for ‘secure’, and it means the website has an SSL or TLS certificate. We’ll refer to it as an SSL certificate – though HTTPS use TLS certificates nowadays, most people still refer to them as SSL certificates.
Each SSL certificate uses asymmetric encryption to exchange a session key, which is then used for symmetric encryption. This process is called the SSL handshake. Let’s break it down, step-by-step.
- When a user visits an HTTPS website, their web browser automatically requests an HTTPS session. (We’ll refer to the user and their web browser as ‘the client’, though in this instance, it’s the web browser doing most of the work.)
- In response, the web server sends them the certificate containing the website’s public key.
- The client creates a symmetric key – the session key – and uses the website’s public key to encrypt this session key.
- The client then sends this encrypted session key to the web server.
- The website uses its private key to decrypt the session key.
- Now that both parties have the session key, they can then use it to facilitate symmetric encryption for the duration of the session. This is far more efficient than continuing to use asymmetric encryption for every little exchange of data.
That might sound like a lot of effort, but it usually happens so fast you don’t even notice it. The web browser and the website sort it out while the web page loads, and most users never even know what’s going on behind the scenes.
PKI: Public Key Infrastructure
Exchanges such as the above example are supported by Public Key Infrastructure, also known as PKI. PKI is a broad term, covering all the technologies and services that handle digital certificates and public key encryption.
This infrastructure bolsters trust over the internet, and underpins secure communications over the web, an areas such as email, ecommerce transactions, and HTTPS websites, as described above. When you buy from Amazon or another storefront, PKI helps verify the identities of those involved and keep the transaction secure.
Certificate Authorities
At the heart of PKI are Certificate Authorities, or CAs. These companies issue, verify, manage, and revoke digital certificates. Public CAs, including organizations such as Comodo and DigiCert, issue certificates to those who need them.
These public CAs must be highly trustworthy, or else their certificates won’t be worth much. Many companies, such as Apple and Visa, maintain lists of trusted CAs, and warn developers and users against certificates issued by non-trusted CAs.
If a CA is careless, it can lose that trust. Symantec, for example, was once the most popular certificate issuer on the web – until it came to light that they had issued over 30,000 faulty certificates. After that, Google, Apple, and many other companies disavowed thousands of Symantec certificates and de-listed Symantec as a trusted CA.
Many companies also run private CAs, which manage certificates within the organization. These private certificates are only valid on their internal network, and carry no validity on the broader internet. Still, this can be a great way for a company to manage trust internally, without having to rely on a public CA.
Root Certificates & the Chain of Trust
Certificates distribute trust based on the hierarchical chain of trust model, in which trust ladders down from root certificates to intermediate certificates to child certificates, which are issued to the end user.
The CA first creates the root certificate, which will then serve as the foundation of trust for the certificates it issues. This root certificate is maintained under the utmost security, and end users never interact with it directly.
Instead, this root certificate is used to create intermediate certificates, which are then used to create child certificates that are issued to end users and used on a day-to-day basis.
Through the chain of trust, you can trace any given digital certificate to the intermediate certificate that created it, all the way through any additional intermediaries up to the root certificate itself. The root certificate’s high level of trustworthiness ladders down and legitimizes the many child certificates that were created from its intermediate certificates.
This is often referred to as the certificate chain; it shows the relationship from the root certificate through the intermediate certificates to the child certificates.
Should an intermediate certificate be revoked, any child certificates it issued will also be revoked. This is why root certificates are so closely guarded, and why intermediate certificates exist; a root certificate can remain valid even if one of its intermediate certificates has been compromised.
Most operating systems and web browsers include a root certificate store, documenting the root certificates it considers trustworthy. When your web browser visits an HTTPS website, for instance, it checks the website’s SSL certificate against this list to ensure it ladders up to a trusted root certificate via the chain of trust.
The Certificate Lifecycle: 5 Stages
Certificate lifecycle management includes shepherding digital certificates through all stages of their lifespan, from enrollment to renewal. All digital certificates have a set lifespan, making this a continuous process. Managing the stages of this lifecycle comprises much of the work of certificate management.
1. Enrollment
To begin with, the administrator must obtain a certificate from a trusted CA. First, they’ll use a specialized program to create a public and private key pair. They then send the public key to the CA as part of a certificate signing request, alongside information about the purpose of the certificate and the organization applying for this certificate.
Once the CA has the certificate signing request, or CSR, they’ll review the information enclosed and validate the identity of the person or company applying for the certificate. As long as they’re satisfied, they will then create a certificate with the public key and send it to the person who filed the request.
2. Installation
Once the administrator has the certificate, they can proceed to install it on the domain or server. Tools such as Microsoft IIS, Apache, and Microsoft Exchange can aid in this process.
You may also need to install intermediate certificates, clarifying the chain of trust upwards from the child certificate.
3. Monitoring
Many organizations will keep a watch over their certificates, tracking for issues and keeping ahead of the curve on any upcoming renewals. By staying on top of your certificates, you can reduce the risk an expired certificate could have an unexpected impact on your business.
4. Remediation
Under certain circumstances, a certificate may need to be revoked prior to its expiry date. If the private key is exposed publicly, for instance, the key pair and attached certificate become compromised. A CA might also revoke a certificate for other reasons, such as a certificate being used for a different website or purpose from the original intent of the certificate.
When a certificate is revoked, it goes on a certificate revocation list, or CRL, which users can then check when validating certificates.
5. Renewal
All certificates come with an expiry date. TLS certificates, for instance, expire 13 months after being issued, and must be renewed on an annual basis. When the time comes, the administrator goes back to step one and files a new CSR, so they can then install a fresh certificate on the domain or server.
Manual vs Automated Certificate Management
There are two ways to handle certificate management: manual and automated. As you would expect, manual certificate management entails doing it all yourself. You file certificate signing requests, install certificates, and monitor for issues all on your own. You might create a spreadsheet or set calendar reminders to keep track of renewal dates, and when the time comes, you’ll file a fresh certificate signing request and install the renewed certificate all over again.
This approach can work for smaller businesses — but if you need to manage certificates at scale, you’ll want to consider using an automated certificate management service. These companies can track renewal dates, monitor for issues, and handle the renewal process with minimal hands-on intervention. These services are especially valuable for any business that has to manage more than a handful of digital certificates at a time.
Many web hosting providers include certificate management as part of the package. When you pay for an HTTPS website — and for many providers, that’s the default — they’ll manage your website’s SSL certificate for you.