Digital Certificates

16 March 2025

Digital Certificates are one of the foundation blocks of security in digital world. They are used to authenticate the identity of the device and secure the transactions between devices. Digital certificate is a data structure that contains various parameters that can be used to establish trust. This section provides an overview of the digital certificates.

Let us dive into few concepts:

Symmetric key cryptography

In Symmetric key cryptography same key is used to encrypt and decrypt.

Secure key distribution is a major problem to be solved, and this is where the Asymmetric key cryptography excells

Asymmetric key cryptography (public key cryptography)

Asymmetric key cryptography solves the above mentioned key distribution problem by using 2 keys (key pair) instead of a single shared key.

There are different algorithm choices available for asymmetric key cryptography. Some of the popular ones are:

Some algorithms like RSA technically allows YOU to choose which key is private and which is public. But some others like ECC does not give you a choice as they are dissimilar in computation.

Hybrid approach

The Asymetric encryption is computationally heavy (could be 1000s of times heavy) as compared to the symmetric encryption. In practical usecases a hybrid approach is used where public key cryptography is used for securely sharing symmetric key. After this initial step, the symmetric key is used always.

Majority of the communication encryption usecases follows a hybrid approch.

Assymetric encryption - Key aspects

Sharing

Public keys can be shared via different mechanisms . For example:

Oneway Encryption

Alice shares public key to rest of the world including Bob. Bob uses it to encrypt data and send to Alice. Alice decrypts with private key. Nobody else can decrypt it since they don't have private key

Jac plays the trick

Jac can access Alice's public key since it is shared to the world. Jac uses Alice's public key and sends Alice a message impersonating Bob "Hello, I am Bob !". Alice will be able to decrypt it with her private key. Alice thinks it came from Bob, and may respond to him!

To avoid this, digital signatures are used. Bob signs the message using Bobs private key. Alice always uses Bobs shared public key to verify the signature. Now Jac cannot impersonate Bob since Jac don't have Bobs private key to sign the message.

A protocol like TLS includes the full mechanism to handle all these aspects using digital signatures. To know more about TLS, visit: below article:

TLS Explained

ssl library performs the verification of certificate date, CA signature verification by default. This is part of TLS handshake protocol specficcation.

A check is required to ensure that the domain mentioned in the certificate and the domain is used in the connection is matching. This check is not part of TLS protocol, but it is avalable as part of the ssl libraries. During the TLS connection establishment time, ssl library is given in the input parameter of the domain or IP to validate against. When the digital certificate is downloaded as part of the TLS handshake, ssl library checks the download IP and IP mentioned in the certificate is matching. Certificate validation will be failiing if not matching. This is an optional feature of the ssl library.

Similarly a certificate revocation checks are also done in ssl library, but it is not part of the TLS protocol.

What is a digital certificate ?

A digital certificate is a file that contains following compoenents:

Digital certificate standard

X509 is a standard for publick key digital certificate. All X509 objects are represented in Abstract Syntax Notation One as a byte array.

Digital certificate file encoding formats

Below are the popular certificate file formats:

Signature Algorithms

In a digital certificate (like an X.509 certificate), the portion that gets signed is called the "TBSCertificate"(To Be Signed Certificate). After signing The result is stored in the signatureValue field of the certificate"

Signed Portion of a certificate
Signed Portion of a certificate

Signing process

Various algorithms can be used for signing it. Examples below:

Fingerprint Algorithms

Self signed digital certificates

A self-signed certificate is a digital certificate that is signed by the entity it is issued to, rather than a trusted Certificate Authority (CA).

In a self signed certificate:

You’ll usually also get a big "Not Trusted" warning unless you’ve added it to your trusted store

Types of digital certificates

Although underlying technology is the same, there are different types of digital certificates depending on the usecases. Digital certificates can be categorized based on differences in X.509 fields.

  1. By Validation Level (based on Subject fields and CA checks)
    • These differ mainly in the Subject field and what the CA verifies before issuing
    • Domain Validation (DV) Certificates. Domain ownership only.Basic website encryption.
      • Validates: Only the domain ownership
      • Subject Fields: Minimal — typically just CN or SAN with the domain name
      • Usage: Basic HTTPS for websites
      • SAN field must match the domain
      • Subject fields like Organization (O), Location (L), etc. are often blank or not validated
    • Organization Validation (OV) Certificates
      • Validates: Domain ownership and the organization's identity
      • Subject Fields: CN, O (Organization), C (Country), L (City), ST (State).
      • Usage: Business websites, APIs, internal tools
      • Includes full Subject DN fields with verified organizational info
      • May include organization info in certificate extensions
    • Extended Validation (EV) Certificates
      • Validates: Domain ownership and a rigorous check of the organization's legal identity
      • Subject Fields: Same as OV but with stricter verification
      • Usage: High-trust websites (banks, e-commerce, etc.).
      • Same fields as OV, but often includes special OID in extensions (e.g., EV policy OIDs)
      • Recognized by browsers with visible indicators (green bar in older browsers, etc.).
  2. By Usage (based on Key Usage & Extended Key Usage extensions)
    • These differ in keyUsage and extendedKeyUsage fields
    • SSL/TLS Certificates
      • Purpose: Secure websites (HTTPS).
      • Key Usage: Digital Signature, Key Encipherment
      • Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication
    • Email Certificates (S/MIME)
      • Purpose: Secure email communications
      • Key Usage: Digital Signature, Key Encipherment
      • Extended Key Usage: Email Protection
      • Subject Fields: Often includes an email address
    • Code Signing Certificates
      • Purpose: Verify software/app authenticity
      • Key Usage: Digital Signature
      • Extended Key Usage: Code Signing
      • Subject Fields: Organization name is typically included
    • Client Authentication Certificates
      • Purpose: Authenticate users/systems
      • Extended Key Usage: Client Authentication
    • Document Signing Certificates
      • Purpose: Sign PDFs, Word docs, etc
      • Extended Key Usage: Document Signing
  3. By Trust Model (based on issuer fields)
    • Root Certificates
      • Self-signed
      • Used to sign intermediate CAs
      • Issuer = Subject
    • Intermediate Certificates
      • Issued by a root or another intermediate CA
      • Used to issue end-entity certs (like DV/OV/EV certs).
      • Helps with trust chain hierarchy
    • End-Entity Certificates
      • Issued to servers, users, or devices
      • Used in actual authentication/communication
      • Cannot sign other certificates (CA:FALSE in Basic Constraints). Need for this: If a certificate without CA:FALSE is compromised and it can issue other certificates, an attacker could create fake certs for any domain — a massive security risk.Root & Intermediate CAs: CA:TRUE and Leaf (end-entity) certs: CA:FALSE

Non X.509 digital certificates

PGP Certificates

PGP is based on decentralized trust - There’s no central authority that everyone must trust to verify identities. Instead, you decide who you trust, and you can trust other people's trust. This is in contrast with CA-based (centralized trust).

In centralized trust YOU don’t decide who to trust — your software or OS does. In PGP, you build your own trust relationships

Fields in digital certificates X.509

X.509 digital certificates, commonly used in SSL/TLS for secure communication, have a standardized structure defined by the X.509 specification

Importance of Subject Alternative Name (SAN)

Wildcard digital certificates

A wildcard certificate is a type of SSL/TLS certificate that secures a domain and all of its subdomains at a single level using a wildcard character (*).

Certificate for *.example.com covers: www.example.com, mail.example.comm blog.example.com etc. But it does not cover: sub.mail.example.com (that’s a second-level subdomain) or example.org (different root domain)

Usecases

SHA-1 digital certificate

SHA-2 digital certificate

Working of PKI

  1. You will generate a key-pair
  2. You will keep the private key secret
  3. Certificate Signing Request (CSR) is made for a domain name or multiple domain names. CSR includes your public key information and information about your domain inside a configuration file. CSR is then sent to CA. Below command generate key pair having password protected private key, and a CSR.

    $ openssl req -newkey rsa:2048 -keyout crispinjacob.com.key -out crispinjacob.com.csr

  4. CA verifies crispinjacob.com.csr and signs your public key and related information in the form of a signed public key certificate
  5. You will install your signed certificate in your server
  6. You will install your private key in your server. This private key is password protected while generating it. Only your server can use this private key.
  7. A webbrowwer or client application access your server and TLS handshake occures, and publick key certificate is downloaded to browser as part of HTTPS handshake
  8. Browser verifies the received server certificate before trusting it - validiyt, connected domain and domain name the certificate and so on.
  9. The certificate verification is baed on a trust achor that browser has access to. Trust anchor is a CA certificate that is often distribuited along with browser, or store in the OS that the browser trusts. Browser expects the downloaded server certificate is signed by this CA certificate (trust anchor)
  10. In most cases the server certificate is not signed by the root CA that comes with OS or brower. That will be another CA that the trust anchor CA trusts . This is called an intermediate CA.
    In this case, the brower checks who signed the intermediate certificate. If it is signed by one of the trust Anchors then the brower trusts the downloaded server certificate. This verification is performed by decrypting that intermediate CA signature using trust anchors (root CA) public key.
  11. Often a further lower hierarchy CA might have signed the server certificate.
    in this case, the brower verifies the issuer CA signed the server certificate, by decrypting server certificate signature with issuer CA public key. Then browser verifies the parent CA that signed the CA. This process goes from leaf node server certificate, up till trust anchror which is often the trust anchor certificate. If successful, at that point , the trust is established on the serer certificate.
    Note that if you install one of the intermediate CA certificate in your brower/OS, then that will be your trust anchor, and you dont need to check till root CA. Often the entire chain of certificate is downloaded in single shot during TLS handshake. Note that if your browser misses one of the intermediate certificates, then your certificate's verification will fail.

Trust anchor

A trust anchor is the root certificate (or public key) that your system or application explicitly trusts. It’s the starting point for validating a chain of trust. If a certificate chain ends in a certificate that matches one of your trust anchors, the whole chain is considered trustworthy (as long as everything else checks out, like signatures and validity periods).

An intermediate certificate can be a trust anchor, if you explicitly configure it as one. A trust anchor is stored in the system/browser/application’s trusted root CA store. But technically any certificate (including an intermediate) can be made a trust anchor if you configure it that way. When you do that, validation stops at that certificate, and no parent (like a root) is required. Let’s say you’re in a private network or using enterprise PKI, and you don’t want to trust a public root CA. Then you might trust a private intermediate CA as your trust anchor. This is valid — and often used in custom or constrained environments

When a certificate is configured as a trust anchor, it's not validated like the rest of the chain. You’re telling the system: “I trust this cert — no questions asked.”

Certificate Chain

Server the entire certificate chain (except for the root certificate) is typically sent by the server during a TLS handshake. Certificate chain is based on chain of trust concept.

802.1X components
Certificate Chain(credit technospace.medium.com).

The certificate chain usually includes:

When you view the certificate chain in a browser, sometimes you'll see the root certificate included in the chain. The browser didn’t get that root cert from the server during the TLS handshake. It pulled it from the local trust store and shows it in the chain for completeness. Browser is trying to display the full trust path, from the server cert all the way up to a trusted root. Even though the server didn’t send the root cert, the browser knows it's trusted (because it’s in the OS/browser trust store), so it includes it in the UI

The sender decides the certificates includes in the certificate chain. For example sender may exclude unnecessary certificates, like trusted root certificate. It's considered a best practice to configure your webserver to deliver the full chain.

If the certificate chain size exceeds TCP’s initial congestion window, it caan cause roundtrips to the TLS handshake. As newer TCP stack has initial congestion window increased to 10 TCP segments this is sufficient for most certificate chains.

Certificate validation

Many libraries (like OpenSSL, BoringSSL, Java's PKIXValidator, .NET, etc.) implement certificate validation according to RFC 5280, though behavior can slightly vary in edge cases (e.g., revocation policy, fallback logic).

RFC 5280 is the gold standard for certificate validation rules in most of the internet. Key steps for certificate validation as defined in RFC

In most real-world cases client validates the certificate chain during the TLS handshake

Client should always validate the certificate, but it may not do that in some cases.

Domain name verification is a critical part of certificate validation, especially for TLS/HTTPS. When a client connects to a server using HTTPS (like https://example.com), it must check that the server’s certificate is issued to that exact domain. This is called Hostname (or domain name) verification

The client compares the requested domain name against: The Subject Alternative Name (SAN) field in the certificate, (Legacy fallback) The Common Name (CN) field in the Subject. This is defined in RFC 6125, and reinforced by TLS specs. Example: You go to https://mail.google.com . The server sends a cert with SANs like: DNS:*.google.com, this is valid. But if the cert only says DNS:api.example.com, then it is invalid for mail.google.com

Verifying the domain name (hostname) is an essential part of certificate validation in HTTPS and other secure protocols. This validation is not part of the TLS protocol, but required by applications using TLS (like HTTPS, SMTP, etc.). TLS does not define how to match the certificate to the hostname. That’s left up to the application layer protocol.

TLS itself implement certificate validation via the TLS libraries. not directly in the TLS protocol spec. The TLS protocol (e.g., TLS 1.2, TLS 1.3) defines that certificates are exchanged and must be validated. But it doesn't say how to do that validation in full detail. Instead TLS libraries (like OpenSSL, BoringSSL, GnuTLS, SChannel, etc.) are responsible for implementing Certificate parsing, Chain building, Signature verification, Extension checks (e.g., key usage, constraints), Revocation checking (optional). These libraries typically follow RFC 5280 for validation logic

Revoking a certificate

One method is to periodically download Certificate Revocation List (CRL) and inspect every certificate in the list. If the certificate is in revocation list , the certificate verification will be made to fail. This is not a scalable nechanism.

The alternate mechanism is to use a protocol Online Certificate Status Protocol (OCSP).OCSP helps the client to check the validity of the certificate using a query instead of storing a list. The CA also need to support OCSP protocol.

In OCSP Stapling protocol, the server retrieves OCSP response and sends to client during the handshake. As OCSP resonse is signed by CA, the client can verify it

How OCSP Works:

Optimisation:

Working of CRL:

SAN (Subject Alternative Name) and CN (Common Name)

The difference between SAN (Subject Alternative Name) and CN (Common Name) is a big deal in modern TLS/PKI. SAN is the modern, preferred way to specify valid hostnames. SAN supports multiple domains in one cert (multi-SAN or multi-domain certs). Modern browsers and TLS clients check SAN only. No SAN = invalid cert in most systems today (even if CN matches)

Common Name (CN) is legacy way to specify the hostname. It was, originally used to identify the cert's primary domain. CN is deprecated (but still supported for compatibility)

CA:FALSE constraint in certificates

It means this certificate is not allowed to act as a Certificate Authority (CA). So it cannot issue other certificates — it's an end-entity certificate (also called a leaf certificate).

Assume an attacker gets access to an end-entity cert’s private key, the cert does not have CA:FALSE and validation client is misconfigured or vulnerable. The attacker can then use the stolen private key to Generate new bogus certificates for domains they don’t own like login.microsoft.com, and sign them using the compromised cert as the "issuer". Without CA:FALSE, the only thing preventing a cert from being a CA is... 'Hope'

CA:FALSE is a critical defense-in-depth control.

When validating a certificate chain, the TLS or PKI software will Reject any certificate in the chain (except the last one) that has CA:FALSE because intermediates must be CAs. Accept CA:FALSE only on the leaf

. Think of it like marking a key "For Office Use Only" — it's not just about security, it’s about intent enforcement

CA creating a fake certificate and fake webserver

Often the rootCAs are and trusted. But when it comes to intermediates CAs of small size, there is a possibility of malicios actors. If your intermedicate CA issues a fake certificate using your domain name, you wont come to know about it. This certificate can be used for man in the middle attack since the brower will trust your domain name

Common certificate errors in browser

The reasons for errors (e.g., expired cert, bad hostname, untrusted CA) are defined and consistent across the industry, But the error messages are not standardized across browsers. Don't expect the same code or label, even if the underlying issue is identical

Private key storage