8 Ways You’re Doing PKI Wrong

Your certificates and encryption are only as good as your public key infrastructure (PKI). I could have the strongest mechanical lock on my front door. But if I leave my key where burglars can find it, it won’t be good at all. A lot of really strong ciphers are being used to encrypt data-in-transit these days. They’re so complex that cyber attackers usually won’t bother trying to crack the cipher itself. Often, when a successful attack does occur, it’s because they’ve exploited vulnerabilities in a certificate’s implementation. It’s a pattern I see in cyber attacks that get publicly reported time and again.



 

It’s absolutely crucial that you deploy, implement and configure your PKI the right way, and avoid these very costly yet sadly common mistakes.

1. Failing to revoke certificates
   All TLS certificates expire eventually. Generally shortening the lifespan of a certificate can improve security, because if a certificate falls into the wrong hands, less data is compromised. We saw SSL certificates with multiple year lifespans in the 90s, but now web browsers and certificate authorities prefer TLS certificates to have lifespans of about a year. There’s good reason for that.
   
   Also, sometimes certificates need revocation because there’s a bug in them. One of many such examples is when Let’s Encrypt revoked three million certificates on March 4th. They identified a bug in the certificates’ CAA code, and they had to act quickly.
   
   There are other concerns too. Sometimes certificates are installed in the wrong place. Sometimes certificates go unused. Sometimes errors are made in their Certificate Signing Request (CSR).
   
   A faulty or expired certificate is lucrative for attackers who want to perform man-in-the-middle attacks on your data. They are still keys that can be used, sometimes maliciously. So, your organization absolutely must ensure that all bad, unused or expired certificates are revoked properly. Manual certificate management makes this mistake much more likely to happen!

2. Letting your wildcard certificates run wild
   Wildcard certificates are sometimes necessary when you run a large website with multiple subdomains. Especially if some of your subdomains are used very infrequently. But their usefulness is accompanied by much greater risk if you’re not careful.
   
   Cyber attackers could try to spoof new subdomains onto your domains to impersonate your sites via DNS. It can also be difficult to track which of your machines are using which certificates. When a wildcard certificate expires, it can take a long time to install a new wildcard certificate to cover those subdomains due to complexities of implementation. At best that causes downtime and at worst it could leak sensitive data as cleartext. Proper certificate management can help to implement wildcards more securely and avoid much frustration and risk.

3. Stressing out over CA hierarchies
   Your organization likely implements certificate authority vectors across various points of your PKI. There are offline root CAs which must be kept super secure! There are CAs that issue online. There are policy CAs. To assure the authenticity and integrity of your certificates you will need to implement CAs all over. Unfortunately drawing diagrams of PKIs and their CA implementation can be very confusing, even to the smartest of humans. Just make sure you use good CAs, place them wherever they’re needed, secure them properly, and focus on other aspects of your PKI. Don’t make your hierarchies more complicated than they absolutely must be.

4. Not worrying enough about other aspects of your PKI configuration
   All that energy spent making your CA hierarchies ever more complex is energy that could be better spent worrying about other aspects of your PKI configuration. Do you use any obsolete or depreciated encryption standards or technologies? (I’ll get to that in my next point.) Have you looked at your certificate security policy and tried to improve it? You need to be careful about which certificate names, key sizes and signing algorithms your CA uses, because your PKI must be compatible with them. Have you looked at your certificate revocation lists (CRL)? If your CRL distribution points need to change, every affected certificate must be reissued! And there are so many other little details that can have tremendous consequences in your PKI. Watch out for them!

5. Using obsolete standards and technologies
   Encryption standards are invented, they get published, they get used for a number of years. All the while cyber attackers and security researchers crack those ciphers, and newer and more complex encryption standards are invented. No encryption standard lasts forever. And using old technologies is tremendously risky. Did you know that I have an app on my phone that can crack WEP wifi in a matter of minutes? That’s why all the ciphers and encryption standards your PKI uses must be upgraded as needed. Don’t hash with SHA-1. Upgrade TLS 1.1 to 1.3 if you can. And so on, and so forth.

6. Not accounting for PKI traffic in your network
   It takes a certain amount of network bandwidth and capacity to keep your PKI operating properly. If your network capacity is insufficient, your PKI may fail and take down the security of your data with it. You need room for CRLs, certificate issuance, directory replication, and the list goes on. Consider the traffic patterns in your network and leave room for the various functions of your PKI at all times!

7. Infrequent key rotation
   Similar to why you need to make sure you revoke certificates, you must also rotate them on a frequent basis. If you use a particular cryptographic key in one place for too long, it becomes easier for cyber attackers to compromise your data. TLS certificates are often the most commonly used keys in your PKI. The generally accepted practice these days is to rotate your certificates every six months, or even more frequently. Too many organizations only rotate their certificates once every year or two... or hardly ever!

8. Storing certificates insecurely
   And this calls back to my metaphor about having a strong lock on my front door but leaving the key where a burglar can find it. What good are all of these other security measures if you don’t store your certificates and other keys securely?
   
   Don’t leave keys on USB sticks or optical discs. Don’t store them online in a place where unauthorized parties can reach them. Don’t put them into ZIP archives and attach them to emails. Don’t let them lose on an FTP server or whatever. Make sure they’re stored in a way that only very few authorized parties and processes can access them. And make sure the authentication vectors are strong too.

These mistakes are all too common. Careful planning, conscientious design, and automated certificate management can help you avoid them.



 

Related posts

• What Business Line Managers Should Know about Managing Machine Identities 
• 5 Questions to Ask About Your PKI Certificate Management
• 4 Misconceptions about PKI that Deserve to be Debunked