Certificate Authority (CA)

Before issuing a certificate, a CA must rigorously verify the identity of the applicant. This process, defined by Certificate Policies (CP) and Certification Practice Statements (CPS), varies by assurance level:

• Domain Validation (DV): Confirms control over a domain (e.g., via DNS record).
• Organization Validation (OV): Verifies the legal existence and identity of the organization.
• Extended Validation (EV): Involves the most stringent vetting, including legal and operational checks, resulting in the display of the organization's name in the browser address bar. This validation establishes the initial trust anchor for the certificate's lifecycle.

Upon successful validation, the CA cryptographically creates and signs the digital certificate. This involves:

• Constructing the X.509 Certificate: Assembling the standardized data structure containing the applicant's public key, identity information, validity period, and intended uses.
• Applying the Digital Signature: The CA uses its own private root key or an intermediate key to generate a digital signature over the certificate's contents. This signature is mathematically verifiable using the CA's widely distributed public root certificate. This act of signing is the formal attestation that binds the public key to the claimed identity.

A CA must provide mechanisms to invalidate a certificate before its natural expiration, a critical function for responding to security incidents. This is managed through:

• Certificate Revocation Lists (CRLs): Periodically published, signed lists of serial numbers for revoked certificates.
• Online Certificate Status Protocol (OCSP): A real-time query protocol where a client can request the revocation status of a specific certificate. Common reasons for revocation include private key compromise, cessation of operation, or discovery that the validation information was incorrect. The CA maintains and signs these revocation status sources.

For a CA's certificates to be trusted, its root public key must be pre-installed in client software (e.g., browsers, operating systems). This involves:

• Root Program Inclusion: Undergoing rigorous security and operational audits to be included in trust stores like the Microsoft Root Program, Apple Root Program, or Mozilla's CA Certificate Program.
• Root Certificate Distribution: The CA's self-signed root certificate is distributed via software updates. This root becomes the ultimate trust anchor; any certificate signed by a chain terminating at this trusted root is automatically trusted by the client. This function is what makes web PKI scalable and globally interoperable.

Trusted CAs operate under strict regulatory and industry standards (e.g., WebTrust, ETSI). Core to this is maintaining a comprehensive, tamper-evident audit trail of all actions, including:

• All certificate issuance and revocation requests with timestamps and authorized personnel.
• Access logs for critical systems, especially the Hardware Security Modules (HSMs) that protect root and intermediate private keys.
• Periodic key generation and ceremony logs. These audit logs are essential for external auditors to verify the CA's adherence to its published CP and CPS, ensuring operational integrity.

The CA is responsible for the secure generation, storage, rotation, and destruction of its own cryptographic keys, which underpin the entire PKI.

• Key Generation: Root and intermediate keys are generated in FIPS 140-2/3 Level 3+ validated HSMs to prevent extraction.
• Key Storage: Private keys never leave the HSM's secure boundary; all signing operations occur within it.
• Key Rotation: CAs follow strict schedules to periodically generate new intermediate keys and, very rarely, root keys, with careful cross-signing to maintain trust continuity.
• Key Destruction: Decommissioned keys are securely erased according to defined procedures. Mismanagement of the CA's own keys would compromise the trust of every certificate it has ever issued.

Public Key Infrastructure (PKI) is the comprehensive framework that enables the use of public-key cryptography for secure communication. A CA is a critical component within PKI. The system includes:

• Digital Certificates that bind a public key to an entity's identity.
• Registration Authorities (RAs) that verify certificate requests before the CA issues them.
• Certificate Repositories for storing and distributing issued certificates.
• Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) responders for checking if a certificate is still valid. PKI establishes the chain of trust that allows web browsers, operating systems, and applications to verify that a website's SSL/TLS certificate is legitimate and issued by a trusted root CA.

The Automated Certificate Management Environment (ACME) is a protocol, defined in RFC 8555, that automates interactions between a certificate applicant (like a web server) and a CA. It is the protocol behind services like Let's Encrypt. Key functions include:

• Domain Validation: Automatically proving control over a domain (e.g., via HTTP or DNS challenges).
• Certificate Issuance: Requesting and receiving a new certificate.
• Certificate Renewal: Automatically renewing certificates before they expire.
• Certificate Revocation: Requesting that a certificate be invalidated. ACME eliminates manual processes, enabling the widespread use of free, short-lived certificates that enhance security through frequent automatic renewal.

Mutual TLS (mTLS) is an authentication method where both the client and the server present and validate each other's digital certificates, establishing a two-way trusted connection. This contrasts with standard TLS, where only the server authenticates to the client. In mTLS:

• Both parties have a certificate issued by a trusted CA (or a private CA).
• The TLS handshake includes the exchange and verification of these certificates.
• It is crucial for zero-trust architectures, securing microservices, API gateways, and machine-to-machine communication where both ends of the connection must be strongly authenticated. A CA is essential for issuing the client certificates used in mTLS, especially within private enterprise PKI.

A Root Certificate is a self-signed digital certificate that belongs to the root Certificate Authority. Its public key is embedded in trust stores (e.g., in browsers and operating systems) and is the ultimate anchor of trust in a PKI hierarchy. To protect the root key, which is rarely used, CAs employ Intermediate CAs.

• Intermediate CAs are certificates issued by the root CA that are authorized to sign end-entity certificates.
• This creates a chain of trust: End-entity certificate → Intermediate CA certificate → Root CA certificate.
• If an intermediate CA is compromised, it can be revoked without replacing the entire root trust store. This hierarchical model balances security (keeping root keys offline) with operational scalability.

A Certificate Signing Request (CSR) is a standardized message (typically in PKCS#10 format) sent from an applicant to a Certificate Authority to apply for a digital identity certificate. The CSR contains:

• The public key of the entity requesting the certificate.
• Identifying information (the Distinguished Name) such as Common Name (CN), Organization (O), and Country (C).
• A digital signature created with the applicant's corresponding private key, proving possession of that key. The CA validates the information in the CSR and the applicant's control over the domain or entity. Upon successful validation, the CA uses its private key to issue a certificate binding the provided public key to the validated identity.

Certificate Revocation is the process by which a CA invalidates a certificate before its scheduled expiration date. This is a critical security mechanism used when a private key is compromised, an entity is no longer trusted, or details change. Revocation is communicated through:

• Certificate Revocation Lists (CRLs): Periodically published, signed lists of serial numbers for revoked certificates.
• Online Certificate Status Protocol (OCSP): A real-time protocol where a client can query an OCSP responder to check a certificate's status (good, revoked, or unknown).
• OCSP Stapling: Allows the server to provide a time-stamped OCSP response signed by the CA during the TLS handshake, improving privacy and performance. Managing revocation is a core duty of a CA's lifecycle management.