I’ve often noticed that it can be difficult to find information in one place around PKI solutions and what makes them secure, so I’ve decided to create this ongoing series outlining the elements that make up a secure PKI.
At PowerON we regularly deploy services which rely on certificates for security. As part of this we have to assess if the certificate platform secure and provides sufficient security for the services relying on it.
Now, apart from the obvious server security aspects such as patching, with PKI solutions there are also considerations relating to cryptography and even physical access. These are rarely documented as a consolidated list and often use language not common in typical systems administration circles, so we decided to try and lay out what we look for and why, when it comes to identifying a secure PKI solution.
What is PKI?
Public Key Infrastructure (or PKI for short) is the concept of using mathematically verified methods to securely transfer data between trusted parties, using keys which are often referred to as certificates. A good introduction to the basics of PKI can be found here.
In this first blog I’ll be talking through multiple tiers.
When designing any infrastructure, there is always a trade-off between security, manageability and complexity of the design and implementation. Specifically within PKI, as it is central to the security of the services and data within the organisation it serves, this is even more crucial to get right the first time.
You are able to create PKI in many different configurations and layers of services and this is largely dependant on the type of organisation and the intended usage of PKI within it. Going from the very simple single-tier infrastructure where the root CA and issuing CA co-exist on a single server, to the more complex three-tiered approach with offline roots and intermediate servers where different departments require granular control or enhanced security.
Complexity vs. security
Whereas the single-tier might appear favourable in terms of complexity it essentially compromises its own security as the root CA server is online and vulnerable to attack if internal networks or resources are compromised.
Additionally, if it is compromised you cannot revoke this CA, which would render all other certificates without a valid trust path.
On the other extreme, a three-tier infrastructure which comprises of an offline root, offline intermediate servers and online issuing servers is normally overkill for most organisations as the footprint of the infrastructure alone is not justifiable in most cases. Some exceptions would be use cases such as nuclear organisations or government entities where security between departments is as important as from the outside world.
The main advantages of the third tier (i.e. the intermediate server layer) are that it allows CA policy to be defined at this layer that restricts certain types of certificates to be issued at the issuing layer, and in case of key compromises this can be revoked at the intermediate tier whilst leaving other branches unaffected.
A different approach
A third option however is available, a two-tier infrastructure that gives us an offline root CA server and an online issuing CA server layer. Additional services such as CRL (Certification Revocation List) infrastructure also needs to be included to maximise the functionality of this solution as with the three-tier approach but from management, footprint and security perspectives this is the usual deployment that most enterprise organisations go to for their deployment models.
This approach is simpler to maintain and deploy, with a vastly reduced footprint to that of a three-tier organisation (albeit with a trade-off for fine-grain control) but negates the inherent security vulnerability of the single tier-approach by having a non-domain-joined offline root.
Further information on tiering approaches can be found within the Microsoft documentation here.
Rest of the Series
Here’s the series in full – I’ll be updating here each week as each part is released:
If you have any questions on what I’ve discussed here or security in general, feel free to email in on firstname.lastname@example.org and I’ll be happy to answer any queries you have.