operational and technical structure of a CA
A CA (Certificate Authority) is a trusted entity (most often a renowned third party) that issues certificates to individuals
and organizations so that they can identify themselves. If an individual or organization request a certificate from a CA,
the CA verifies the identity of the requesting party, and issues the certificate to the relevant party once identification
has been successfully verified. This is the interpersonal/operational aspect of a CA.
The technical implementation of a CA consists of the following components:
- the CA’s private key.
- the CA’s certificate. For a root CA, this a self-signed certificate, signed with the CA’s private key.
- the CA’s CP (Certificate Policy). This is a policy that governs the issuing of certificates by the CA and the handling
and usage
of certificates issued by the CA. See RFC 3647, section 3.1, CP for details. RFC 3647, section 3.2 Certificate Policy Examples contains the description of a CP example.
The CP also defines the revocation method to revoke compromised certificates.
- a list of all certificates that have been issued by the CA.
- a service for publishing the CA’s certificate, i.e., a webserver that offers the certificate for download.
Operating systems have key-stores pre-installed that contain certificates of well-known CAs like DigiCert or Let’s Encrypt.
- a method to revoke lost or compromised certificates, and a service to publish revoked certificates.
the CA’s private key needs to be highly protected. It should never be stored on any device or machine that is connected
to a network and/or without strictly enforced access restrictions.
Best practice is to store the CA’s private key either on a highly secured air-gapped machine with strictly enforced access
restrictions, or on an encrypted medium that is stored away safely.
certificate validation levels
There are three levels of validation:
- DV (Domain Validation) – basic level validation. The CA checks if the requesting party controls the domain via email, DNS
or file upload – where the CA gives you a file to upload, and then checks your site for it.
Usually the CA issues the certificate within minutes. DV is suitable for personal site, i.e., a blog.
- OV (Organization Validation) – medium level validation. First, the CA performs a DV. Then the CA checks entity legal
documents and the physical location. The entity must be located and must be officially registered with respective
state/country. Finally, the CA does a verification phone call. The validation process usually takes
1 or 2 days. Suitable for organizations with public-facing sites, like businesses, corporations, and NGOs.
- EV (Extended Validation) – high level validation. After a DV, the CA runs a strict background check on the entity,
checking registration documents, physical address, and active status, often through official government databases.
For organizations, the requesting entity has to proof that the organization has existed for more than 3 years.
If the organization has existed for more than 3 years, an additional proof of operational status will be required, such
as a Professional/Legal Option Letter (POL) a bank confirmation letter.
Established organizations with public records that are thorough and up to date, usually clear those steps quickly.
An EV level certificate can be issued within 1 and 5 days.
Since every certificate issued by a CA is signed by the issuing CA’s private key, a lost CA’s private key (or a private key
suspected to be compromised) compromises the CA as a whole, including its CRL. Thus, a CA usually consists of a root CA
and at least one, or more intermediate CAs. The intermediate CAs are used to issue certificates for servers and clients.
Such certificates are called end-entity certificates, leaf certificates, or subscriber certificates (the term subscriber
stems from the fact that some certificates like those of web servers are automatically renewed).
The root CA stays offline with its private key stored away safely and is only used to issue an Intermediate CA’s certificate.
If an Intermediate CA’s certificate is suspected or known to be compromised, the root CA revokes the intermediate CA’s
certificate. The root CA and its CRL stay intact. A new Intermediate CA can be created from the private Root CA, and
certificates created by the now defunct Intermediate CA’s are exchanged with certificates from the new Intermediate CA.
When a client (i.e., a user’s browser) connects to a service secured by a certificate, it receives the service’s
leaf certificate and the intermediate certificate. The client checks if the intermediate certificate is signed by a
trusted root CA for which the root CA’s certificate is stored in its system.
Tt also checks the revocation status of the intermediate and leaf certificate via CRL, OCSP, or SCT. If the status of
the intermediate CA that
issued the leaf certificate or the staus of the leaf certificate is indicated as revoked, the chain of trust is broken,
and the client will display a security warning to the user and will abort the connection procedure.
The number of certificates issued by a compromised CA defines the blast radius. Every certificate issued by such a
compromised CA has to be revoked and exchanged with a new certificate issued by an uncompromised CA.
reference
Certificate Policy, RFC 3647, section 3.1, CP