Certificate Purpose Public key certificates are fundamental components of PKI (Public Key Infrastructure), forming the security foundation of modern internet communication. When vulnerabilities emerge in these protocols, the impact on global internet security can be severe. For this discussion, we'll simplify the CA (Certificate Authority) concept as a single-tier certificate issuer.

A certificate primarily consists of three parts: the TBS Certificate (To Be Signed), the signature algorithm, and the signature value. The TBS Certificate contains the certificate's identifier, owner information, issuer information, and most critically, the owner's public key. The core functionality of certificates revolves around this public key information.

Consider two scenarios:

Scenario 1: Key Exchange When two parties, Alice and Bob, need to establish a secure encrypted communication channel to prevent eavesdropping, they need to share a symmetric key. However, transmitting this key direct poses security risks. The asymmetric cryptography system addresses this challenge. After a standard handshake:

1. Alice and Bob exchange their certificates
2. Alice verifies Bob's certificate, extracts his public key, generates a random number, and calculates a shared secret using Bob's public key
3. Bob verifies Alice's certificate, extracts her public key, generates a random number, and calculates the same shared secret using Alice's public key
4. Both parties use their private keys to derive the same symmetric key from the exchanged values
5. They combine these values using a key derivation function to create the final encryption key

This simplified protocol resembles the SSL/TLS handshake process, with HTTPS being a prominent example of such secure communication.

Scenario 2: Digital Signatures For message authentication and integrity:

1. Alice comptues a hash of her message, signs it with her private key, and sends her certificate, signature, and message to Bob
2. Bob verifies Alice's certificate, extracts her public key, computes the message hash, and verifies the signature using the public key

The hash ensures message integrity, while the signature provides non-repudiation.

This raises the question: why not transmit just the public key? The issue is that a public key is simply a large number (binary stream). Without proper verification, there's no guarantee that the key hasn't been intercepted or replaced by a malicious third party.

In physical terms, this is analogous to national identification systems. We need a digital equivalent that proves ownership of a public key while including additional identifying information. This is where digital certificates, issued by trusted authorities, become essential.

Certificate Issuance

Certificate Signing Request (CSR) To obtain a certificate, an entity must submit a request to a Certificate Authority (CA). This request follows the PKCS #10 standard (RFC 2986) and is known as a Certificate Signing Request (CSR).

Let's create a valid CSR using OpenSSL:

First, generate a key pair:

openssl genrsa -out entity_private.pem 2048
openssl rsa -in entity_private.pem -pubout -out entity_public.pem

Create the CSR:

openssl req -new -in entity_public.pem -key entity_private.pem -out entity_request.csr.pem

During the process, you'll be prompted to provide personal information. Alternatively, you can generate both keys and the CSR in one command:

openssl req -new -nodes -sha256 -newkey rsa:2048 -keyout entity_private.pem -out entity_request.csr.pem

To examine the CSR contents:

openssl req -in entity_request.csr.pem -noout -text

The CSR contains:

• Version (typically v1, represented as 0)
• Subject information (country, state, organization, etc.)
• Subject public key information
• Attributes

The structure corresponds to the ASN.1 definition:

CertificationRequestInfo ::= SEQUENCE {
    version INTEGER { v1(0) } (v1,...),
    subject Name,
    subjectPKInfo SubjectPublicKeyInfo,
    attributes [0] Attributes
}

Certificate Authority (CA) A Certificate Authority is the trusted entity that issues and manages digital certificates. Its primary role is to verify the requester's identity and sign their public key to create a valid certificate.

When a CA receives a CSR, it performs several verification steps:

1. Validates the CSR's signature using the contained public key
2. Verifies the requester's identity information
3. Ensures the public key meets security requirements

Upon approval, the CA issues:

• The entity's certificate
• The CA's own certificate (which may be self-signed)

In practice, browsers come pre-installed with trusted root CA certificates. If a certificate is issued by an untrusted CA, the application will display a security warning.

X.509 Certificate Format Let's examine a real certificate using OpenSSL:

openssl x509 -in certificate.pem -text -noout

The output shows the certificate structure:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Example Inc, CN = Example CA
        Validity
            Not Before: Jan 1 00:00:00 2023 GMT
            Not After : Jan 1 00:00:00 2024 GMT
        Subject: C = US, ST = California, L = San Francisco, O = Example Corp, CN = example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage: 
                Server Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
    Signature Algorithm: sha256WithRSAEncryption
        ...

The ASN.1 structure of an X.509 certificate is:

Certificate ::= SEQUENCE {
    tbsCertificate TBSCertificate,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue BIT STRING
}

TBSCertificate The TBS (To Be Signed) Certificate contains the core information:

TBSCertificate ::= SEQUENCE {
    version [0] EXPLICIT Version DEFAULT v1,
    serialNumber CertificateSerialNumber,
    signature AlgorithmIdentifier,
    issuer Name,
    validity Validity,
    subject Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo,
    extensions [3] EXPLICIT Extensions OPTIONAL
}

Key fields include:

• Version: Currently v3 (0x2) when extensions are present
• Serial Number: Unique identifier for the certificate
• Issuer: The CA's identity information
• Subject: The certificate holder's identity
• Validity: Start and end dates
• Subject Public Key: The cryptographic key being certified

Certificate Extensions X.509 v3 extensions provide additional functionality:

Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension

Extension ::= SEQUENCE {
    extnID OBJECT IDENTIFIER,
    critical BOOLEAN DEFAULT FALSE,
    extnValue OCTET STRING
}

Common extensions include:

• Key Usage: Specifies permitted purposes (digital signature, key encipherment, etc.)
• Extended Key Usage: Specific purposes (server authentication, client authentication)
• Subject Alternative Name: Additional domain names or IP addresses
• Authority Key Identifier: Identifies the CA's public key
• Subject Key Identifier: Uniquely identifies the subject's public key
• Certificate Policies: Intended use of the certificate
• Authority Information Access: CA certificate and OCSP locations

Certificate Revocation

Certificate Revocation List (CRL) When a private key is compromised or other security issues arise, a certificate must be revoked before its expiration date. CRLs provide a list of revoked certificates.

To download a CRL:

openssl crl -in crl.pem -text -noout

The CRL structure is:

CertificateList ::= SEQUENCE {
    tbsCertList TBSCertList,
    signatureAlgorithm AlgorithmIdentifier,
    signatureValue BIT STRING
}

TBSCertList ::= SEQUENCE {
    version Version OPTIONAL,
    signature AlgorithmIdentifier,
    issuer Name,
    thisUpdate Time,
    nextUpdate Time OPTIONAL,
    revokedCertificates SEQUENCE OF SEQUENCE {
        userCertificate CertificateSerialNumber,
        revocationDate Time,
        crlEntryExtensions Extensions OPTIONAL
    } OPTIONAL,
    crlExtensions [0] EXPLICIT Extensions OPTIONAL
}

The revokedCertificates section lists serial numbers of certificates that have been revoked along with the revocation date and reason.

Online Certificate Status Protocol (OCSP) CRLs have limitations in size and timeliness. OCSP provides a more efficient alternative by allowing real-time certificate status checks.

An OCSP request has the following structure:

OCSPRequest ::= SEQUENCE {
    tbsRequest TBSRequest,
    optionalSignature [0] EXPLICIT Signature OPTIONAL
}

TBSRequest ::= SEQUENCE {
    version [0] EXPLICIT Version DEFAULT v1,
    requestorName [1] EXPLICIT GeneralName OPTIONAL,
    requestList SEQUENCE OF Request,
    requestExtensions [2] EXPLICIT Extensions OPTIONAL
}

Request ::= SEQUENCE {
    reqCert CertID,
    singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL
}

CertID ::= SEQUENCE {
    hashAlgorithm AlgorithmIdentifier,
    issuerNameHash OCTET STRING,
    issuerKeyHash OCTET STRING,
    serialNumber CertificateSerialNumber
}

The OCSP response provides immediate verification of a certificate's status without downloading large lists.

The underlying format of certificates is ASN.1 DER encoded data, which appears as hexadecimal bytes when viewed directly:

00000000: 3082 04c8 3082 03b0 a003 0201 0202 1100
...

Understanding this binary structure is essential for low-level certificate processing and validation.