What you should know about certificate?

What is a Certificate?

A certificate (specifically an X.509 certificate in the context of TLS/HTTPS) is a digital document that binds a public key to an identity (e.g., a website, company, or individual). It’s issued by a trusted Certificate Authority (CA) and used to establish secure, encrypted connections. Think of it as a passport for the internet: it proves who you are and provides the key to lock/unlock communication.

Certificates are critical in TLS (e.g., TLS 1.3) because they:

Enable encryption by sharing the server’s public key.
Verify the server’s identity to prevent impersonation (e.g., man-in-the-middle attacks).

Components Involved in Certificates

Before diving into the certificate’s contents, let’s clarify the related pieces you mentioned:

Private Key:
- A secret key paired with the public key in the certificate.
- Never shared; stored securely on the server.
- Used to decrypt data encrypted with the public key or sign messages.
Certificate Signing Request (CSR):
- A file you generate and send to a CA to request a certificate.
- Contains your public key and identity details (e.g., domain, company name).
- Signed with your private key to prove you own the key pair.
Certificate Chain:
- A sequence of certificates linking your certificate (the “leaf”) to a trusted root CA.
- Includes:
  - Leaf Certificate: Your site’s certificate.
  - Intermediate Certificates: Issued by CAs between you and the root.
  - Root Certificate: Pre-trusted by browsers/OS (not usually sent).
Certificate:
- The final product from the CA, containing your public key and identity, signed by the CA’s private key.

What’s Inside a Certificate? (Detailed Breakdown)

An X.509 certificate is structured in a standard format (encoded in ASN.1 and often PEM/Base64 for readability). Here’s every piece of information it typically includes:

1. Version

What: Specifies the X.509 version (usually “Version 3” or v3).
Why: V3 supports extensions (extra fields), unlike V1 or V2.
Example: Version: 3 (0x2) (in hex).

2. Serial Number

What: A unique identifier assigned by the CA.
Why: Distinguishes this certificate from others issued by the same CA.
Example: Serial Number: 1234567890abcdef.

3. Signature Algorithm

What: The algorithm the CA used to sign the certificate.
Why: Ensures the certificate’s integrity and authenticity.
Example: sha256WithRSAEncryption (SHA-256 hash with RSA signature).
2025 Note: SHA-1 is obsolete; SHA-256 or SHA-384 are standard.

4. Issuer

What: Identifies the CA that issued the certificate.
Details:
- Common Name (CN): e.g., CN=Let’s Encrypt.
- Organization (O): e.g., O=Let’s Encrypt.
- Country (C): e.g., C=US.
Why: Links the certificate to a trusted authority.

5. Validity Period

What: Start and end dates for when the certificate is valid.
Format: Not Before and Not After.
Example:
- Not Before: Mar 24 00:00:00 2025 GMT
- Not After: Jun 22 23:59:59 2025 GMT
Why: Ensures certificates expire (typically 90 days for Let’s Encrypt in 2025) to limit damage if compromised.
2025 Note: Short validity is common due to automation (e.g., ACME).

6. Subject

What: Identifies the entity the certificate is issued to (e.g., your website).
Details:
- Common Name (CN): Historically the domain (e.g., CN=example.com), but often omitted in modern certs.
- Subject Alternative Name (SAN): Lists domains (e.g., DNS:example.com, DNS:www.example.com).
- Organization (O): e.g., O=Your Company (optional for DV certs).
- Organizational Unit (OU): e.g., OU=IT Dept (optional, less common in 2025).
- Country (C): e.g., C=US (optional).
Why: Ties the certificate to your identity/domain.
Types:
- DV (Domain Validated): Only domain (e.g., Let’s Encrypt).
- OV (Organization Validated): Includes company name.
- EV (Extended Validation): Detailed company info (less common in 2025).

7. Subject Public Key Info

What: The public key and its details.
Details:
- Algorithm: e.g., RSA, ECDSA (Elliptic Curve), or Ed25519.
- Key Length: Size of the key:
  - RSA: Typically 2048 or 4096 bits (2048 is standard in 2025).
  - ECDSA: 256 bits (e.g., secp256r1 curve) is common, more efficient than RSA.
- Public Key: The actual key (a large number), e.g., a 2048-bit RSA key in hex.
Example:Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: [long hex string] Exponent: 65537 (0x10001)
Why: The client (browser) uses this to encrypt data the server can decrypt with its private key.

8. Issuer Unique ID / Subject Unique ID (Rare)

What: Optional identifiers for the issuer or subject.
Why: Deprecated in modern certificates; rarely used in 2025.

9. Extensions (Critical and Non-Critical)

What: Additional metadata (V3 feature). Some are mandatory (“critical”).
Common Extensions:
- Subject Alternative Name (SAN): Lists all domains (e.g., DNS:example.com, DNS:*.example.com).
  - Why: Replaces CN for domain validation; supports multiple domains.
- Basic Constraints: Indicates if it’s a CA certificate (e.g., CA:FALSE for leaf certs).
- Key Usage: Defines what the key can do (e.g., Digital Signature, Key Encipherment).
- Extended Key Usage (EKU): Specific purposes (e.g., TLS Web Server Authentication).
- Authority Key Identifier (AKI): Links to the CA’s public key.
- Subject Key Identifier (SKI): Unique hash of the public key.
- CRL Distribution Points: URL for Certificate Revocation List (e.g., http://crl.letsencrypt.org).
- Authority Information Access (AIA): URLs for CA info and OCSP (e.g., http://ocsp.letsencrypt.org).
Why: Adds flexibility and security (e.g., SAN is critical for modern HTTPS).

10. Signature

What: The CA’s digital signature over the certificate.
Details:
- Hash of the certificate (e.g., SHA-256).
- Encrypted with the CA’s private key.
Example: Signature Algorithm: sha256WithRSAEncryption [hex string].
Why: Proves the certificate hasn’t been tampered with; verifiable with the CA’s public key.

Example Certificate (Simplified)

Here’s what a real certificate might look like (parsed with openssl x509 -text):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0x1234567890abcdef
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Let’s Encrypt R3, O=Let’s Encrypt, C=US
        Validity:
            Not Before: Mar 24 00:00:00 2025 GMT
            Not After : Jun 22 23:59:59 2025 GMT
        Subject: CN=example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public-Key: (2048 bit)
            Modulus: [long hex]
            Exponent: 65537 (0x10001)
        X509v3 Extensions:
            X509v3 Subject Alternative Name:
                DNS:example.com, DNS:www.example.com
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Authority Key Identifier:
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value: [hex string]

How It Ties to TLS 1.3

In TLS 1.3:

Server Sends Certificate: During the handshake (after “ServerHello”), the server sends its leaf certificate and intermediate chain.
Client Verifies:
- Checks the signature against the CA’s public key (from the chain or trusted store).
- Confirms the domain matches (via SAN).
- Ensures it’s within validity and not revoked (via OCSP/CRL).
Public Key Used: The client uses the certificate’s public key to establish the session key (via Diffie-Hellman in TLS 1.3, not RSA key exchange).

Summary of Key Contents

Public Key: Yes, with algorithm (e.g., RSA) and length (e.g., 2048 bits).
Company Name: Yes, for OV/EV certs (e.g., O=Your Company); optional for DV.
Key Length: Depends on algorithm (2048-bit RSA, 256-bit ECDSA common in 2025).
Other: Domain (SAN), CA details, validity, signature, usage constraints.

Let me know if you want to explore any part further—like generating a CSR or verifying a chain!

Related posts:

Leave a Comment Cancel Reply