So, you’ve been assigned with the ever-important task of creating a new PKI for your organization. You’re most likely wondering, “What are the industry standards for running a PKI?” Well, you have come to the right place! …well unless you want to read the 128 page PKI baseline that must be followed by Public Certificate Authorities Luckily for everyone else, I have read it, so you don’t have to. And don’t worry, I am not going to make a long list to scare you into hiring a PKI consultant. However, I might skip some definitions, and for that I recommend you first watch our PKI Basics series on YouTube.
When creating a new Certificate Authority there are many moving parts that we must consider. First things first, there is the infrastructure required to run the CA (keep in mind the availability of the system). Next, how are we going to distribute the certificates? Even more importantly, how are we going to rotate the certificates? Let’s get into it…
The first step for designing your system is deciding What CA hierarchy you need. We recommend having a two Tier PKI. This allows you to have a Root CA, and then have multiple issuing CAs for different usages (remember even if right now you only need one Issuing CA, Root CAs can be good for up to 20 years. So, planning ahead is always good in PKI).
While creating a CA might look as simple as following a guide and clicking through a wizard in Windows, there are many components to the CAs:
The first one is a hardware security module. HSMs are designed to protects your Keys from hackers. They’re so secure that even if hackers manage to break into your CA, they cannot extract the keys from it since they are in a tamper proof HSM! While HSMs can be a pain to manage and are more expensive than a car, you can now create managed HSMs in Azure or even create a CA using a Key Vault making this technology available to everyone. If you’re an Azure user, there’s no excuse to not set this up as part of your PKI.
The second key player here is the certificate authority, the entity that will issue the certificates. The CA must be a highly guarded server, with restricted access, diligent patching, and it is recommended that this server is only used for this purpose. This reduces the surface area for attacks by limiting the services available in the sever. A good tip for this is if you are doing it in your local datacenter, you can use a small VM for the CA.
Once you have setup the CA, we recommend setting up automated testing that will issue a certificate every few minutes to ensure that the CA is up and issuing certificates (Note: ensure that the template for this test certificate does not store the certificate in the database, legacy CAs cannot scale to that many certificates).
Next we have to set up the certificate revocation list (CRL). This is a list where the revoked certificates are listed, and it is checked each time you authenticate using a certificate. Webtrust CA’s have a revocation list lifetime of 7 days, this means that every 7 days a new one is issued. Before you run and set yours to 1 day to ensure you always have the latest list, I have a question for you: how often do you revoke a certificate? If you do not usually revoke certificates leaving it at something like 7 days saves CRL related outages since your devices can cache the CRL for 7 days rather than get a new one every day.
While uptime is important for the CA, it is not the most critical part of the system. If the CA is down, you will not be able to issue certificates for the time that it is down. However, if CRL or OCSP are down, all your certificates are unable to authenticate until the CRL or OCSP are brought back up. We recommend that you have a more robust geo-redundant CRL setup. For example, for EZCA we use a geo-redundant CDN with tester calling it every few minutes and if the CRL is down it has auto-healing properties that will instruct EZCA to create a new CRL reducing the downtime caused by CRL errors.
CRLs can get very long, this can take its toll on and strain your network. This is the case even on some devices such as network adapters that cannot hold such large files. To help with this, the PKI industry came up with OCSP. This is a protocol where the device asks the OCSP server whether a certificate is valid or not and the server responds with a yes or no. This reduces the overhead of verifying certificates on the client side. While OCSP is great, not all devices support it, so make sure your devices do.
OCSP uptime is paramount for your certificate authentication, since in most cases (we won’t talk about OCSP stappling since we don’t know how you are using your certificates). the OCSP check is real time, it means that if your OCSP server is down, your certificates won’t be validated, having a lower error tolerance than CRLs that can be cached. We recommend having a geo-redundant deployment and having runners running every few seconds to ensure that all your OCSP servers are up and running.
Now that we have planned the infrastructure side of things, we must figure out how are you going to distribute your certificates, when planning this, try to use methods that can be automated, no one wants to manually rotate certificates, it’s not only boring, but it also a very expensive action that can cause outages.
Web enrollment is where the user goes to a website and requests a certificate. While you might be a fan of the classics such as ADCS web enrollment using Internet Explorer, there are modern PKIs that have web portals where you can self-service mange certificates and even integrate with Azure services such as Key Vault to enable automatic rotation of certificates.
While back in the day you had all your devices in one network and you could use GPOs to push certificates, with today’s distributed workforce you need an MDM such as Intune to Issue Certificate using SCEP. This allows your users to get the certificates into their devices without having to do anything. Intune will also take care of the automatic rotation of the certificates.
During our time at Keytos, we have seen a lot of people using certificates for development from Azure IoT certificate authentication to client based authentication in Azure. To enable this, you will want to use a CA that has APIs, and easy to follow guides and code samples to help you get started and reduce your development time.
ACME has become the most popular way to create certificates for websites. However, legacy PKI providers such as ADCS do not support ACME out of the box. We recommend using a private certificate authority that supports acme to enable your internal sites to use the same tools as your external sites to automate your certificate issuance.
So now that we have looked at the best practices for creating a certificate authority, you are ready to create your own CA. However, if you don’t feel like building all this infrastructure, and prefer a cloud CA, we invite you to check out EZCA our cloud-based CA with native Azure certificate management functions that allows you to create and manage your certificate authorities in minutes, and don’t worry about security and uptime, we take care of that as well. The best part? It starts at $200 per CA per month (cheaper than running all these servers in Azure), if you want to learn more about it or just want to chat about PKI you can talk to our PKI experts and learn more about how you can modernize your PKI.
