A Public Key Infrastructure (PKI) consists of computing nodes and servers, secure networks and legal agreements plus trusted personnel and operations whose purpose is to issue and manage trusted Digital Certificates.
There are several subtopics under this topic:
A PKI can host any number of certificate hierarchies. They might have several hierarchies for servers (e.g. domain validated, domain and company validated and extended validation) and several hierarchies for client certs (e.g. only email validated, email and name validated and full SubjectDN).
A certificate hierarchy consists items:
- A Trusted Root Certificate (widely published, self signed) and corresponding Root Private Key (very securely stored, e.g. offline in a cryptographic token in a safe). The Root Private Key is needed only to sign the top level intermediate cert, maybe once every 5 years.
- One or more Intermediate Certificates (widely published, signed by parent private key, and corresponding intermediate private keys (typically stored in an HSM). The lowest level intermediate private key is needed to sign end-entity certs in this hiearchcy.
- A potentially large number of end-entity certs, usually distributed to the applicant at the time of creation
- A periodically published CRL (published via HTTPS and/or LDAPS) for this hierarchy
- An OCSP server that can provide revocation information from the hierarchy database or possibly CRLs
- A database containing various items related to the hierarhcy, e.g. all issued certs, revocation status of each cert, etc.
- Management tools that allow review of certificate requests (by an RA) and signing of approved certificates, revocation of certs, etc.
- Automated Email generation to notify certificate owners of imminent expiration, etc.
Each certificate includes a CRL Distribution Point that points to where a user can obtain the current CRL for that certificate, as well as an AIA that indicates where to obtain OCSP connections.
There are two kinds of certificate hierarchies: public and private (this has nothing to do with public and private asymmetric keys).
A public hierarchy has been approved by WebTrust as operating in a secure and reliable manner. The Trusted Root Cert is periodically provided to OS and device vendors to install in the Root folder of their Certificate Store. This means that certificate in that hierarchy will be trusted by all relying parties with no further effort.
You can view the trust chain from a given certificate to a Trusted Root (assuming the complete path exists):
Here “Lawrence Hughes” is the end-entity cert, “DigiCert SHA2 Assured ID CA” is the intermediate cert and “DigiCert” is the Trusted Root Cert. That is a complete certification path. You can double click on any of those certs to view them. The Issuer Distinguished Name of each cert is the same as the Subject Distinguished Name of its parent cert, until the Trusted Root Cert (which is self signed) where the Issuer Distinguished Name and Subject Distinguished Name are the same. That is how you chase a trust path when validating a certificate.
SixWallet Certificate Status
SixWallet allows you to check the current status of any certificate in any of the folders (right click on cert, choose Check Certificate Status):
You can even check the CRL(s) and OCSP.