(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

September 13, 2018 2

Let’s Talk About Some Common PKI Certificate Management Mistakes

in Everything Encryption

There are a lot of moving parts with Public Key Infrastructure, which means there’s plenty of room for PKI certificate management mistakes

Public Key Infrastructure is the backbone of most organizations’ encryption implementations. A well-constructed PKI can handle a range of responsibilities for your organization, everything from authentication to encryption to ensuring file and email integrity. But PKI is complicated, there are a number of common PKI certificate management mistakes that any company or organization can make.

Especially if it’s not large enough to hire a specialist to manage its PKI.

And even when organizations can afford to hire a specialist (or even a team of them), there’s no guarantee that their approach will be correct. After all, PKI is constantly evolving and as you’ll see, if you don’t stay on the cutting edge you’re going to end up making some pretty egregious PKI certificate management mistakes.

Today we’re going to talk about some of those common errors and what your company can do to avoid making these PKI certificate management mistakes.

Let’s hash it out…

Let’s start with a quick refresher on Public Key Infrastructure

Public Key Infrastructure, or PKI, seems like a difficult concept to grasp at first glance, but once you unravel it a bit, it all makes sense. PKI is facilitated by two things: digital certificates and public/private key pairs.

For the sake of this discussion I’m going to simplify things a bit, but let’s start with root certificates. Root certificates sit at the heart of PKI. These digital certificates are universally trusted, a copy of each is saved in the root store of every user’s computer system. Root Certificate Authorities, that is, CAs that own one of these trusted roots, can issue certificates off those roots.

When we say issue certificates, what’s really meant is that a certificate signing request is presented to the CA, which then uses its root’s private key to digitally sign the certificate. Or at least, in theory that’s how it works. In reality, the threat of having a root compromised is so severe that CAs spin up Intermediate Roots. An intermediate Root is signed by the trusted root, which grants it trusted status despite not being a part of the root store. The CA can then issue certificates by using the intermediate root’s private key to sign the end-user or leaf certificate.

One more thing, there can be multiple intermediates. Sometimes a CA spins up an intermediate for itself, or it can issue another intermediate root to a Sub-CA for the Sub-CA to issue from. All of this creates something called a certificate chain. When a client is presented with a leaf certificate, it looks at the digital signature on the certificate and follows the chain back to the certificate who’s private key signed it. It continues reading signatures and following the chain until it arrives at one of the roots in its trust store. As long as the leaf certificate can be chained back to a trusted root it will be trusted. If it can’t the client’s browser issues an error.

What I’ve just described, from the Root CA all the way down to the leaf certificates is what comprises Public Key Infrastructure. In an SSL/TLS context, when this is deployed correctly, any client can use the publicly available key to authenticate the end point it’s associated with, and securely send it a symmetric session key to use for communication.

That’s PKI in a nutshell.

Hashing out some common PKI Certificate Management Mistakes

Now let’s talk about some of the most frequent PKI certificate management mistakes we see. We’ve worked with Enterprise clients, large companies and SMBs. All of them have different needs and pain points, but there are some common issues that almost everyone runs into, too.

While this list is far from comprehensive, hopefully it will give you a nice jump on correcting any PKI certificate management mistakes that are currently plaguing your organization’s implementation.

Spending too much time on CA Hierarchies

At the outset of creating your PKI, provided you’re rolling your own, you’ll want to map everything out. And let’s face it, for the IT crowd diagramming all of these boxes and lines can be a lot of fun. Almost sexy in that weird way that only someone who truly understands system architecture can appreciate. Unfortunately, one of the most common PKI certificate management mistakes we see is that it’s a little too easy to get distracted with all that—worrying about your hierarchy of offline roots, policy/intermediate CAs, Online issuing CAs, etc.

And yes, if you’re building your own you’re going to need to start by setting up a truly offline Root CA, spinning up a couple of intermediate roots to issue off of and you’ll need to protect them with a solid Hardware Security Module (HSM). But, there are a whole lot of other things you’ll also need to worry about, too. And those are no less important. We’ll get to those in a minute.

But first, the tendency when diagramming all of this is that you can end up making everything far too complex. This is only going to cause you headaches down the road because it’s going to end up being more expensive and more complex to manage. Ideally, well-managed PKI ends up saving you time and stress—not adding to it.

Not spending enough time on other configuration details

While it’s easy to spend too much time on CA hierarchies, another one of the most common PKI certificate management mistakes we see is not spending enough time on the other moving parts. And that’s a mistake, because failing to make the right decisions during this stage of your setup means that you’ll have to completely re-deploy everything if you want to change anything later.

You may have never thought about what goes into a certificate security policy, you may not even know what one is, but you definitely shouldn’t let that stop you from defining one. For instance, when you use a commercial CA for SSL certificates, you don’t have to worry about certificate revocation lists (the CA does), but if you’re spinning up your own PKI that responsibility falls to you. Are you going to need to set up one or two OSCP (online certificate status protocol) servers for this internally? Will you need one for external use?

As Ted Shorter, the CTO of Certified Security Solutions puts it:

PKI enjoys a well-defined structure for policy and practices definition, in the form of Certificate Policy (CP) and Certification Practices Statements (CPS). These are excellent frameworks for defining the requirements governing a PKI, and the means by which an implementation would meet those requirements. Creating these documents can be a daunting task. However, it’s important to note that simply copying someone else’s set of CP/CPS documents verbatim will not suffice; these tools only have value if they truly represent your organization’s PKI requirements and operational processes.

Let’s look at a few more configuration-style PKI certificate management mistakes…

Using outdated algorithms, ciphers and protocols

You want your PKI to have two key attributes from a big picture standpoint: scalability and long-term viability. Both of those attributes are borne out of picking the correct configurations. And perhaps no where is that more important than when it comes to picking ciphers and protocols. Public Key Cryptography is constantly evolving, algorithms come and go, ciphers change—if you’re not careful your entire PKI can become outmoded within a few years of implementing it.

That’s why it’s so critical to do your research and pick the correct algorithms and ciphers for your PKI implementation. Here are a few examples:

• SHA-1 was deprecated back in 2015, we now use SHA-2. If you were building out your PKI in 2014 and chose SHA-1, you’d be in trouble right now.
• TLS 1.3 was just finalized by the IETF and published as RFC 8446. This represents the most recent, most secure version of the TLS protocol. SSL 2.0, 3.0 and TLS 1.0 should never be used. TLS 1.1 is ill-advised, too.
• Pretty soon the industry will have to decide whether continuing to use RSA for asymmetric encryption is still more efficient than using Elliptic Curve Cryptography.

Choosing the wrong Key Sizes

Keys are critical in PKI—it’s even in the name. Keys are used to both encrypt and decrypt data, and they need to be sufficiently robust so that nobody can guess their value, copy them or decipher your encryption. PKI specifically refers to asymmetric encryption (though symmetric encryption also plays a role, too).

How robust a key is, or its hardness, is determined by its length. The longer a key is, the more secure it is. For instance, a standard RSA private key is 2,048 bits long. Back in 2002, 1024-bit keys were sufficient, today they’re not. In another ten years, 2048-bit keys will likely be obsolete, too. Where it starts to get tricky, and this hearkens back to our previous point, is that as asymmetric keys get larger the processing power required to use them increases at a much greater rate than the actual key strength does. Eventually, we’ll have to switch algorithms because RSA will become unwieldy.

That’s something to consider. Like, really consider.

Ultimately you’ll have to weigh your security needs against the performance costs and also factor in any regulatory or compliance requirements before making a final decision.

Not anticipating the extra traffic PKI adds to your network

Regardless of how you configure your PKI, it’s going to add traffic to your network load. One of the easiest PKI certificate management mistakes to make is forgetting to factor in the effect PKI will have on your organization’s network. Exactly how much of an effect depends on your architectural choices. Again, this is something you want to figure out at the outset—not as you go.

Here’s a breakdown of where you can expect some extra traffic from:

Certificate Issuance

You’re going to have to account for directory or database requests when querying for user details and responses, plus bandwidth for any certificate requests being made to the CA. Obviously, this traffic is going to peak around your initial rollout and anytime you have to do renewals or mass re-issues.

Email Usage

One of the additional applications of PKI is for email and document signing. If you decide to deploy your PKI with this capability, you can count on additional traffic when sending signed or encrypted emails. Not only do those emails cost more bandwidth to send, they each require a directory lookup, too.

Certificate Revocation Lists

As we covered earlier: if you’ve spun up your own CA you’re going to need to maintain your own CRLs. And the bigger your PKI, the faster your CRLs grow. If every user has to download the entire CRL on a regular basis not only is it going to add traffic it’s also going to increase the time verification takes. Granted, this can be mitigated somewhat by using OCSPs.

Directory Replication

Depending on how you’re storing certificates, you may be looking at some additional traffic here, too. If you’re using LDAP (Lightweight Directory Access Protocol) directories, in larger implementations those directories are going to be replicated across the network. And while LDAP is designed and optimized for fast, inexpensive lookups and replication, configuring this correctly – and getting it to play nicely with the rest of your existing network security policies – is a challenging task.

Not Storing Certificate and Keys Securely

While we’re on the topic of certificate storage, let’s talk about another genre of common PKI certificate management mistakes: improper storage of keys and certificates. We talk all the time about how important key security is, and that’s for good reason. Key compromise can cripple an organization.

Bruce Schneier, a universally respected American cryptographer and security researcher, writes about key security with so much severity that you can’t help but feel a little guilty at everything you’re not doing:

One of the biggest risks in any CA-based system is with your own private signing key. How do you protect it? You almost certainly don’t own a secure computing system with physical access controls, TEMPEST shielding, “air wall” network security, and other protections; you store your private key on a conventional computer. There, it’s subject to attack by viruses and other malicious programs. Even if your private key is safe on your computer, is your computer in a locked room, with video surveillance, so that you know no one but you ever uses it? If it’s protected by a password, how hard is it to guess that password? If your key is stored on a smartcard, how attack-resistant is the card? [Most arevery weak.] If it is stored in a truly attack-resistant device, can an infected driving computer get the trustworthy device to sign something you didn’t intend to sign?

While that may be taking things to their extreme, if you’re saving key-strings in a spreadsheet, on a thumb drive, on a normal hard drive or even somewhere online that is remotely accessible—you are making a mistake. Frankly, you probably should be using an HSM.

But, failing that, at least make sure that you have adequately locked down the database or directory you’re using. It’s also a good idea to limit who has access to the keystore to just a select few high-level individuals.

Bad Certificate Life-cycle Choices

This is more than just determining when your certificates will expire—though that is a big part of it. If you’re using your own private CA on your own network you can issue certificates for however long or short you’d like.

Longer certificates need to be replaced less frequently but can eventually become outmoded as new algorithms and ciphers come into favor.

Shorter certificates need to be replaced more often, which isn’t a problem if you have automation, but as we’ll discuss in a moment, quicker key rotation is a good security choice.

Figuring out what’s best for your organization and its PKI is a calculus you’ll need to work through on your own, but you’ll need to come up with an entire plan – an issuance process – that covers not just the initial roll out but the entire certificate life-cycle.

It’s probably also a good idea to figure out how you’re going to handle revocations, key archival, key recovery and all other contingencies.

Infrequent Key and PKI Certificate rotation

As we just mentioned, rotating certificates and keys regularly is a good call. Just how regularly goes back to your organization’s own issuance and life-cycle policies, but it’s best if it occurs at regular intervals – every six months or less is considered best practice. If your PKI includes your own Private CA, issuing these certificates isn’t going to cost you anything but bandwidth.

As security researcher Scott Helme suggests, don’t wait until expiry to rotate keys:

With a 39 month, or even an 825 day certificate, we’re realistically going to see keys rotated at most at those intervals and not before. This is bad hygiene and the longer a given cryptographic key is in use the more likely it is to face compromise, I’d much rather see a push towards ephemeral keys than static keys wherever possible.

Ephemeral is a fancy way of saying “session” key. Anyway, by swapping out certificates and keys with a regular cadence, you’re minimizing risk. Even if there were some sort of compromise, the certificate and key would be obsolete within a few weeks anyway.

Misusing self-signed certificates

For large enterprises with their own private CAs and large PKIs, the use of self-signed certificates is commonplace. And within your own network, where you can manually add the right roots to your organization’s trust stores, these self-signed certificates function just fine (they’re also good for test environments).

But one of the most common PKI certificate management mistakes we see is organizations trying to use a self-signed certificate on a public facing domain or IP. This doesn’t work. Anyone outside of your organization that tries to access the site, server, application – whatever – is going to get a connection error. That’s going to send the wrong signals about your organization.

At least for public facing properties, use a trusted CA.

Lack of Automation

Automation is almost a necessity once you get to a certain size, but even if you don’t think you’re big enough it’s still an option that might be worth exploring. As with any form of automation, automating aspects of your PKI improves efficiency and reduces the potential for human mistakes. Automation helps with the renewal of certificates and keys. It can also track and store data related to your certificates and keys, things like:

• How many certificates have been issued?
• What are those certificates for?
• How many keys are we currently in possession of?
• Who requested these?
• Who has access to them?

You know, things that would be good to keep track of. Without automation, you’re left trying to keep information organized across spread sheets that are maintained by humans and there are a litany of problems that can come from that.

Lack of Visibility

The last of the PKI certificate management mistakes we’ll cover is also one of the most dangerous: a lack of visibility over your PKI. Specifically, your leaf certificates. You need to be able to see all of the certificates you have issued, who they were issued by, when they expire—you need a complete inventory accounting.

This is really the only way you can guard against rogue certificates—valid certificates that have been compromised. If the certificate has the name of one of your domains in it, an attacker could impersonate your organization and do all kinds of harm. The point isn’t to get into the weeds about rogue certificates, it’s to undergird our point about the need to have visibility over your entire PKI. This is a function of proper certificate management.

Fortunately, there are a number of great tools that can help you with certificate management both from Certificate Authorities like Comodo and DigiCert, and also from world class third-party security companies like Venafi. What works best for you and your organization comes down to your own unique circumstances, but there is a certain size where you would be remiss not to have some kind of management apparatus – even if you build it yourself – that can give you visibility and control over your entire PKI.

Avoiding the most common PKI certificate management mistakes

As we’ve discussed, there is not shortage of potential PKI certificate management mistakes to make when setting up your organization’s PKI, but if I may, perhaps the best piece of advice that supersedes all of this is just two words:

Don’t rush.

Take your time when you’re implementing PKI for your organization. Do the requisite research on setting the right policies and choosing the correct configurations. Make sure to consult with anyone who is going to be a stakeholder, try to anticipate where this could conflict with other network security policies.

Just take your time.

And don’t be afraid to ask for help. This is complicated. Sometimes even the experts need experts. It’s better to find the right people to put the right implementation in place – one that scales and maintains long-term viability – than to try to do it all in-house and muck it up. That will only end up costing you more in the long run.

As always, leave any comments or questions below…

• #PKI