![\"pki](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/bigstock-Crypto-Protection-Icon-Modern-238971124-300x300.jpg\"){kind=icon}
Especially if it\u2019s not large enough to hire a specialist to manage its PKI.<\/p>\nPublic Key Infrastructure is the backbone of most organizations\u2019 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.<\/p>\n
Especially if it\u2019s not large enough to hire a specialist to manage its PKI.<\/p>\n
And even when organizations can afford to hire a specialist (or even a team of them), there\u2019s no guarantee that their approach will be correct. After all, PKI is constantly evolving and as you\u2019ll see, if you don\u2019t stay on the cutting edge you\u2019re going to end up making some pretty egregious PKI certificate management mistakes.<\/p>\n
Today we\u2019re going to talk about some of those common errors and what your company can do to avoid making these PKI certificate management mistakes.<\/p>\n
Let\u2019s hash it out\u2026<\/span><\/p>\n<\/span><\/span>\n 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<\/a> and public\/private key pairs<\/a>.<\/p>\n For the sake of this discussion I\u2019m going to simplify things a bit, but let\u2019s start with root certificates<\/a>. 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\u2019s computer system. Root Certificate Authorities, that is, CAs that own one of these trusted roots, can issue certificates off those roots.<\/p>\n 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\u2019s 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\u2019t the client\u2019s browser issues an error.<\/p>\n What I\u2019ve 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\u2019s associated with, and securely send it a symmetric session key to use for communication.<\/p>\n That\u2019s PKI in a nutshell.<\/p>\n Now let\u2019s talk about some of the most frequent PKI certificate management mistakes we see. We\u2019ve worked with Enterprise clients<\/a>, 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.<\/p>\n 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.<\/p>\n At the outset of creating your PKI, provided you\u2019re rolling your own, you\u2019ll want to map everything out. And let\u2019s 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\u2014worrying about your hierarchy of offline roots, policy\/intermediate CAs, Online issuing CAs, etc.<\/p>\n 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\u2019s going to end up being more expensive and more complex to manage. Ideally, well-managed PKI ends up saving you time and stress\u2014not adding to it.<\/p>\n<\/span><\/span>\n While it\u2019s 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\u2019s a mistake, because failing to make the right decisions during this stage of your setup means that you\u2019ll have to completely re-deploy everything if you want to change anything later.<\/p>\n 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\u2019t let that stop you from defining one. For instance, when you use a commercial CA for SSL certificates, you don\u2019t have to worry about certificate revocation lists (the CA does), but if you\u2019re 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?<\/p>\n As Ted Shorter, the CTO of Certified Security Solutions<\/a> puts it:<\/p>\n 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\u2019s important to note that simply copying someone else\u2019s set of CP\/CPS documents verbatim will not suffice; these tools only have value if they truly represent your<\/em><\/strong> organization\u2019s PKI requirements and operational processes.<\/p><\/blockquote>\n Let\u2019s look at a few more configuration-style PKI certificate management mistakes\u2026<\/p>\n 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<\/a> come and go, ciphers<\/a> change\u2014if you\u2019re not careful your entire PKI can become outmoded within a few years of implementing it.<\/p>\n That\u2019s why it\u2019s so critical to do your research and pick the correct algorithms and ciphers for your PKI implementation. Here are a few examples: Keys are critical in PKI\u2014it\u2019s 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).<\/p>\n That\u2019s something to consider.\u00a0Like, really consider.<\/p>\n 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.<\/p>\n Regardless of how you configure your PKI, it\u2019s 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\u2014not as you go.<\/p>\n Here\u2019s a breakdown of where you can expect some extra traffic from:<\/p>\n Certificate Issuance<\/strong><\/p>\n You\u2019re 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.<\/em><\/p>\n Email Usage<\/strong><\/p>\n 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<\/a>. Not only do those emails cost more bandwidth to send, they each require a directory lookup, too.<\/em><\/p>\n Certificate Revocation Lists<\/strong><\/p>\n As we covered earlier: if you\u2019ve spun up your own CA you\u2019re 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\u2019s also going to increase the time verification takes. Granted, this can be mitigated somewhat by using OCSPs<\/a>.<\/em><\/p>\n Directory Replication <\/strong><\/p>\n Depending on how you\u2019re storing certificates, you may be looking at some additional traffic here, too. If you\u2019re 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 \u2013 and getting it to play nicely with the rest of your existing network security policies \u2013 is a challenging task.<\/em><\/p>\n While we\u2019re on the topic of certificate storage, let\u2019s 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<\/a>, and that\u2019s for good reason. Key compromise can cripple an organization<\/a>.<\/p>\n Bruce Schneier, a universally respected American cryptographer and security researcher, writes about key security<\/a> with so much severity that you can’t help but feel a little guilty at everything you’re not doing:<\/p>\n 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\u2019t own a secure computing system with physical access controls, TEMPEST shielding, \u201cair wall\u201d network security, and other protections; you store your private key on a conventional computer. There, it\u2019s 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\u2019s 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\u2019t intend to sign?<\/p><\/blockquote>\n While that may be taking things to their extreme, if you\u2019re saving key-strings in a spreadsheet, on a thumb drive, on a normal hard drive or even somewhere online that is remotely accessible\u2014you are making a mistake. Frankly, you probably should be using an HSM.<\/p>\n But, failing that, at least make sure that you have adequately locked down the database or directory you\u2019re using. It\u2019s also a good idea to limit who has access to the keystore to just a select few high-level individuals.<\/p>\n This is more than just determining when your certificates will expire<\/a>\u2014though that is a big part of it. If you\u2019re using your own private CA on your own network you can issue certificates for however long or short you\u2019d like.<\/p>\n Shorter certificates need to be replaced more often<\/a>, which isn\u2019t a problem if you have automation, but as we\u2019ll discuss in a moment, quicker key rotation is a good security choice.<\/p>\n Figuring out what\u2019s best for your organization and its PKI is a calculus you\u2019ll need to work through on your own, but you\u2019ll need to come up with an entire plan \u2013 an issuance process \u2013 that covers not just the initial roll out but the entire certificate life-cycle.<\/p>\n It\u2019s probably also a good idea to figure out how you\u2019re going to handle revocations, key archival, key recovery and all other contingencies.<\/p>\n As we just mentioned, rotating certificates and keys regularly is a good call. Just how regularly goes back to your organization\u2019s own issuance and life-cycle policies, but it\u2019s best if it occurs at regular intervals \u2013 every six months or less is considered best practice<\/a>. If your PKI includes your own Private CA, issuing these certificates isn\u2019t going to cost you anything but bandwidth.<\/p>\n As security researcher Scott Helme suggests, don’t wait until expiry to rotate keys<\/a>:<\/p>\n 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.<\/p><\/blockquote>\n Ephemeral is a fancy way of saying “session<\/a>” key. Anyway, by swapping out certificates and keys with a regular cadence, you\u2019re minimizing risk. Even if there were some sort of compromise, the certificate and key would be obsolete within a few weeks anyway.<\/p>\n 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\u2019t work. Anyone outside of your organization that tries to access the site, server, application \u2013 whatever \u2013 is going to get a connection error. That\u2019s going to send the wrong signals about your organization.<\/p>\n At least for public facing properties, use a trusted CA.<\/p>\n Automation is almost a necessity once you get to a certain size, but even if you don\u2019t think you\u2019re big enough it\u2019s 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<\/a>. Automation helps with the renewal of certificates and keys. It can also track and store data related to your certificates and keys, things like:<\/p>\n You know, things that would be good to keep track of. Without automation, you\u2019re 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<\/a>.<\/p>\n 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\u2014you need a complete inventory accounting.<\/p>\n Fortunately, there are a number of great tools that can help you with certificate management both from Certificate Authorities like Comodo<\/a> and DigiCert<\/a>, and also from world class third-party security companies like Venafi<\/a>. 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 \u2013 even if you build it yourself<\/a> \u2013 that can give you visibility and control over your entire PKI.<\/p>\n As we\u2019ve discussed, there is not shortage of potential PKI certificate management mistakes to make when setting up your organization\u2019s PKI, but if I may, perhaps the best piece of advice that supersedes all of this is just two words:<\/p>\n Don\u2019t rush.<\/strong><\/span><\/p>\n Take your time when you\u2019re 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.<\/p>\n Just take your time.<\/p>\nLet\u2019s start with a quick refresher on Public Key Infrastructure<\/h2>\n
![\"pki](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/bigstock-Electronic-Key-Line-Icon-Priv-244556431-300x300.jpg\"){kind=icon}
When we say issue certificates, what\u2019s really meant is that a certificate signing request is presented to the CA, which then uses its root\u2019s private key to digitally sign the certificate. Or at least, in theory that\u2019s how it works. In reality, the threat of having a root compromised is so severe that CAs spin up Intermediate Roots<\/a>. 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\u2019s private key to sign the end-user or leaf certificate.<\/p>\nHashing out some common PKI Certificate Management Mistakes<\/h2>\n
Spending too much time on CA Hierarchies<\/h2>\n
![\"pki](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/CA-Hierarchy-300x300.jpg\")
And yes, if you’re building your own you\u2019re 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\u2019ll need to protect them with a solid Hardware Security Module (HSM). But, there are a whole lot of other things you\u2019ll also need to worry about, too. And those are no less important. We\u2019ll get to those in a minute.<\/p>\nNot spending enough time on other configuration details<\/h2>\n
Using outdated algorithms, ciphers and protocols<\/h2>\n
\n![\"pki](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/bigstock-Documentation-With-Algorithm-L-255750634-300x243.jpg\")
<\/p>\n\n
Choosing the wrong Key Sizes<\/h2>\n
![\"pki](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/bigstock-195032344-300x300.jpg\")
How robust a key is, or its hardness, is determined by its length<\/a>. The longer a key is, the more secure it is. For instance, a standard RSA private key is 2,048<\/a> bits long. Back in 2002, 1024-bit keys were sufficient, today they\u2019re 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\u2019ll have to switch algorithms because RSA will become unwieldy.<\/p>\nNot anticipating the extra traffic PKI adds to your network<\/h2>\n
Not Storing Certificate and Keys Securely<\/h2>\n
![\"pki](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/bigstock-216922033.jpg\")
<\/p>\n<\/span><\/span>\nBad Certificate Life-cycle Choices<\/h2>\n
![\"what](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/bigstock-180724507-300x300.jpg\")
Longer certificates need to be replaced less frequently but can eventually become outmoded as new algorithms and ciphers come into favor<\/a>.<\/p>\nInfrequent Key and PKI Certificate rotation<\/h2>\n
Misusing self-signed certificates<\/h2>\n
![\"pki](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/bigstock-195615934-300x300.jpg\")
For large enterprises with their own private CAs and large PKIs<\/a>, the use of self-signed certificates is commonplace. And within your own network, where you can manually add the right roots to your organization\u2019s trust stores, these self-signed certificates function just fine (they\u2019re also good for test environments).<\/p>\nLack of Automation<\/h2>\n
\n
Lack of Visibility<\/h2>\n
![\"pki](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/bigstock-Network-Icon-Isolated-On-White-228222082-300x300.jpg\"){kind=icon}
This is really the only way you can guard against rogue certificates\u2014valid 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\u2019t to get into the weeds about rogue certificates, it\u2019s to undergird our point about the need to have visibility over your entire PKI. This is a function of proper certificate management.<\/p>\nAvoiding the most common PKI certificate management mistakes<\/h2>\n
![\"Hashed](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/08\/bigstock-222348568.jpg\")
<\/p>\n","protected":false},"excerpt":{"rendered":"