This post was authored by Jason Wood, founder of Paladin Security, a host on Security Weekly and commentator on Hack Naked News. This post is sponsored by DigiCert.
Ah, the easy, old days when you could buy an SSL/TLS certificate that was valid for up to ten years. You set it up and then relaxed because it was going to be a while until you had to go through that headache again. Well, those days are definitely no more. As of March 1, 2018, the longest lasting SSL/TLS certificate you can get is two years. So let’s take a quick look at what happened, why it was changed and what it means to you.
Information about the vote
This change was something that was decided by the Certificate Authorities and Browsers forum. It was a ballot proposed by the group in response to the SSL/TLS vulnerabilities that have been discovered. These issues included flaws in the SSL/TLS algorithms and methods used to create certificates. The ballot was proposed and voted on by members with a few abstentions, but no votes against it. You can check the final disposition of the ballot at https://cabforum.org/2017/03/17/ballot-193-825-day-certificate-lifetimes/.
Reasons for the Change
One of the reasons for this change is that as flaws were discovered and published, the certificates affected by those vulnerabilities wouldn’t be changed right away. In fact, they’d linger around until the certificate finally expired and was replaced. As a result, we had large numbers of vulnerable certificates that were hanging around. One impact of reducing the certificate lifetime is that it would limit the amount of time that these certificates would be in use.
Here are some examples of when this could be an issue.
-
- The hashing algorithm is found to be weak and is deprecated. Example: MD5
- The key length could be deprecated. Example: RSA-1024 keys
- The validation method for certificates is changed.
What this means for you
Where this impacts those of us managing SSL/TLS certificates is that we will have to go through the process of renewing and installing certificates more often. In a lot of cases, this isn’t too terrible to deal with. The commands to generate a certificate signing request (CSR) vary from platform to platform and can be a bit detailed. Fortunately, the instructions for your platform are usually easy to find on your Certificate Authorities (CA) website. I tend to just have it documented in my own repository of documentation and periodically check to make sure it is still up to date.
With that in hand, you generate the CSR and send it off to your CA to sign. The process varies a bit by CA and the type of certificate you are purchasing. In the end, you get your signed certificate that is ready for deployment. For a regular website, you configure the web server(s) and you are done for two more years.
If you are deploying the certificates across a large number of servers, load balancers, or proxies, the work can be a bit more involved. In particular, you want to make sure that the private key associated with the certificate isn’t accidentally left in the open.
Potential pitfalls
One thing that can make this much more difficult is if you have a web service that is used by third parties and requires a certificate. In this situation, you can’t ignore the expiration of your certificates until the last second. You shouldn’t in any case, but it gets worse in the case of web services. The problem arises when your client’s software is checking the validity of the certificate and expecting it to match something configured on the client server. If you change the certificate without letting your clients know well in advance of the change, then you will have some very angry customers who are stuck doing an emergency deployment to respond to your change. If done right, their software will stop any connections to your site because the certificate doesn’t match what is expected. So plan in advance and communicate well.
Other than the change in frequency to change certificates, it is not too big of an issue. It should be a very invisible change to your users, with the major exception of your API customers. Plan ahead a bit, use automation as much as possible, and it should be a non-event.
Large Numbers of Certificates to Manage?
Encryption certificates are probably one of those things you don’t think much about until you need to manage a large number of certificates across different applications and systems. You can actually automate management to avoid the need to rush to deploy new certificates before expiration. Our Security Weekly Partner, DigiCert, has a REST API that you can use to deploy and renew certificates across your environment. To learn more about their PKI Certificate Management Platform, check out https://www.digicert.com/mpki/.
