Rate this article: (4 votes, average: 3.00)
PKI, or public key infrastructure, is a vital component of the modern internet. It’s a hierarchy of trust that uses digital certificates to authenticate the party they’ve been issued to. It serves as the cybersecurity and encryption framework that protects data transmissions between clients and your server(s). This trust model forms the basis for HTTPS, code signing, email & document signing, and even two-factor authentication (2FA).
This article will serve as an introduction to PKI and PKI certificates — from the trust model to the actual kinds of PKI certificate — and will discuss how PKI infrastructure works.
Certificate Authorities (CAs) are the entities that have been entrusted with the responsibility of issuing digital certificates. They’re strictly regulated and regularly audited — even the smallest deviation from best practice is dealt with harshly. The reason for this is that CAs are at the center of the entire PKI trust model. In order for everything to work as intended, there needs to be a trusted party that can validate the entities the certificates are being issued to. If the CAs don’t validate entities properly, everything breaks down.
So, before a CA can issue any PKI certificate, it must first validate the party it’s issuing it to. The rigorousness of the validation varies by the type of PKI certificate – but it must occur in some capacity for the issuance to be legitimate.
At the heart of PKI is the root certificate. Those are collected and administered by the various root programs pending CA compliance. Some root programs, like Mozilla’s, have even more stringent standards than the CA/B Forum does. There are four major root programs of note:
The collection of root certificates included in any root program are contained in a root store. These are usually handled at the OS level, though some browsers use their own or create rules on top of the root stores they’re leveraging. A root store is a collection of trusted root certificates that reside on the device. That includes the certificate itself and their public key(s).
When a CA issues a PKI certificate, it starts by performing validation of the entity its issuing to. Once that’s complete, it issues a certificate that contains the validated information and signs it with its private key.
Any PKI certificate signed by a trusted root is trusted. But CAs almost never sign directly from their trusted roots. It’s too risky and can cause technical problems. Instead, the CAs issue intermediate roots and sign those with their trust roots. Those intermediate roots are then used to issue end user or leaf certificates.
PKI infrastructure relies on handshakes to handle authentication (and in the case of SSL/TLS to negotiate encryption parameters). Anytime PKI is involved, at the outset of the connection or session, the server or end user presents the other party with its certificate and public key.
The client then performs a series of checks (which vary based on context), one of which is authentication of the signature on the certificate. This is why it’s sometimes necessary to install intermediate SSL certificates on your server — to complete the certificate chain. Those intermediates are presented alongside the leaf certificate.
First, the client checks the validity of the certificate, then it looks at the signature on it — the one left by the issuing intermediate root. To verify the signature, it takes the intermediate’s public key and authenticates its signature on the leaf certificate. Provided it checks out, it moves on to the intermediate certificate and the signature that was affixed to it during its issuance. That could be from another intermediate or one of the roots in its root store.
Either way, the process is the same: the client takes the issuing certificate’s public key and verifies its signature. It continues to do this until it either reaches one of the trusted roots, or the chain can’t be completed (at that point, it issues an error). Provided the end-user certificate is descendant from one of the trusted roots, it’s trusted.
This is the entire PKI trust model. It uses certificate chains and CA hierarchies to create a system where entities can be authenticated using digital certificates and signatures.
PKI certificates are all X.509 certificates with different key usage configurations. They include:
Tip: You can typically save a significant amount by buying your SSL certificate direct instead of through your web hosting company. We sell all Comodo SSL certificates at up to 75% off. Compare SSL Certificates
All public key infrastructure certificates handle authentication and identity. Some also feature the ability to encrypt — though authentication is the common thread between them all.
PKI infrastructure is the connective tissue that helps us conduct business on the internet. It cobbles together trust and, in some cases, security. And does it in a way that modern computers can do it all in just milliseconds.
And it’s all thanks to PKI certificates.