Skip to main content
Fundamentals

How Digital Certificates Work

Understand digital certificate contents, validation, and the trust mechanisms behind SSL/TLS authentication.

CertOne5 min read

Digital certificates help authenticate the endpoint you connect to, including sensitive services such as online banking. As part of SSL/TLS, they bind identities to cryptographic keys. This guide explains their structure, validation, and trust mechanisms.

1. What is a digital certificate?​

A digital certificate is an electronic document binding a public key to an entity, such as a website, person, or organization. SSL/TLS certificates are one application of this identity mechanism.

1. Core concepts​

Certificates operate within public key infrastructure (PKI), using asymmetric cryptography for authentication. A certificate contains:

  • Public key: the public component used for signature verification or encryption, depending on the algorithm
  • Identity: domain names and, where validated, organization details
  • Validity: the period during which the certificate is valid
  • Issuer: the certificate authority that signed it
  • Digital signature: the issuer's signature over the certificate contents

2. Purpose​

Certificates support:

Authentication: bind an endpoint identity to a key, helping prevent man-in-the-middle attacks.

Secure communication: provide an authenticated public key for TLS authentication and key establishment.

Integrity: the CA signature detects changes to the signed certificate contents.

2. Certificate structure​

1. X.509 fields​

X.509 certificates contain fields including:

Version: usually version 3 for TLS certificates.

Serial number: an identifier assigned by the issuer.

Signature algorithm: the algorithm used by the issuer, such as SHA256withRSA.

Issuer: the issuing CA's name and identity attributes.

Validity:

  • Not Before: start time
  • Not After: expiration time

Subject: attributes identifying the certificate holder, which may include:

  • Common Name (CN): historically used for a domain name
  • Organization (O)
  • Organizational Unit (OU), where permitted for the certificate profile
  • Country (C)
  • State or Province (ST)
  • Locality (L)

Subject Public Key Info:

  • Public-key algorithm, such as RSA or EC
  • Public-key value

Extensions:

  • Key Usage
  • Extended Key Usage
  • Subject Alternative Name (SAN): the covered domain names or IP addresses
  • Basic Constraints
  • Certificate Transparency-related information

Signature: the CA's digital signature over the certificate.

2. Storage formats​

Certificates and associated keys can be stored in several formats:

PEM: Base64-encoded text with headers; common extensions include .crt, .cer, and .pem.

DER: binary encoding, commonly using .der or .cer.

PFX/P12: a container that can hold certificates and private keys with password protection, commonly used on Windows.

JKS: the Java KeyStore format used by Java applications.

3. How certificates work​

1. Public-key fundamentals​

Certificates use asymmetric cryptography:

Key generation:

  • Generate a public/private key pair
  • The public key can be shared; supported operations depend on the algorithm
  • Keep the private key secret

Public-key encryption, where supported:

  • A sender encrypts data using the recipient's public key
  • The matching private key is needed to decrypt it

Digital signatures:

  • Sign data using the private key
  • Verify the signature with the public key to check authenticity and integrity

2. Issuance process​

Step 1: Generate a key pair

  • Generate an RSA or EC key pair
  • Store the private key securely

Step 2: Create a CSR

  • Include the public key and requested identity information
  • Sign the CSR to demonstrate possession of the matching private key

Step 3: Submit the CSR

  • Send the CSR to the CA
  • Prove domain control through an accepted method such as DNS or HTTP validation

Step 4: CA validation and issuance

  • Validate domain control
  • Validate organization identity where required by the certificate type
  • Sign the certificate using the CA's private key
  • Return the issued certificate

Step 5: Install

  • Install the certificate alongside its private key
  • Configure the web server for HTTPS

3. Validation process​

When a client connects over HTTPS:

Step 1: Receive the certificate

  • The server sends its certificate during the TLS handshake

Step 2: Validate the chain

  • Check that the certificate chains to a trusted CA
  • Validate intermediate certificates when present
  • Follow the path from server certificate through intermediates to the trusted root

Step 3: Check validity

  • Check the validity period
  • Apply revocation checks using available CRL or OCSP information and client policy

Step 4: Check the hostname

  • Match the requested hostname to the certificate's permitted names
  • Apply wildcard matching rules, such as for *.example.com
  • Check the SAN extension for additional names

Step 5: Check permitted usage

  • Verify that key usage is compatible with the handshake
  • Check that Extended Key Usage permits TLS server authentication

4. Trust mechanisms​

1. Certificate chains​

Certificate trust follows a certification path:

Root CA certificate:

  • Typically a self-signed certificate representing a trust anchor
  • Distributed through operating-system and browser trust stores
  • They anchor the trust chain

Intermediate CA certificate:

  • Certified by a root or another intermediate
  • Used to issue end-entity certificates
  • This adds security separation

Server certificate:

  • An end-entity certificate issued by an intermediate or root CA
  • Installed on the web server

2. Trust stores​

Operating systems and browsers maintain trusted root certificates:

Operating-system trust stores:

  • Windows: the Windows certificate store
  • macOS：Keychain
  • Linux: commonly under /etc/ssl/certs/

Browser trust stores:

  • Browsers may maintain their own trust stores
  • They may also integrate with operating-system trust settings

3. Certificate Transparency​

Certificate Transparency uses public, auditable logs:

Purpose:

  • Detect unauthorized or incorrectly issued certificates
  • Logging increases CA transparency
  • Help identify certificate abuse

How it works:

  • The CA submits a certificate or precertificate to CT logs
  • Browsers check for required CT evidence
  • A certificate that fails the browser's CT policy may be rejected

5. Certificate categories​

1. Validation level​

DV — Domain Validation:

  • Validates domain control
  • Quick issuance at low or no cost
  • Suitable for personal sites and many small businesses

OV — Organization Validation:

  • Validates domain control and organization identity
  • Includes a verified organization name
  • Suitable for business identity requirements

EV — Extended Validation:

  • Apply more extensive identity validation
  • Verifies legal existence, address, and other organization details
  • Older browsers displayed a green organization label; this is not a modern browser guarantee
  • Used where extended identity assurance is required, such as some financial or e-commerce services

2. Domain coverage​

Single-domain certificate:

Multi-domain (SAN) certificate:

  • Covers multiple names in one certificate
  • Uses the SAN extension
  • For example, example.com, www.example.com, and api.example.com

Wildcard certificate:

  • Covers matching subdomains at one level; include the apex separately if needed
  • For example, *.example.com covers www.example.com, but not example.com or a.b.example.com

6. Security practices​

1. Key management​

  • Use appropriate key sizes, such as RSA 2048 bits or greater and suitable EC curves of 256 bits or greater
  • Keep private keys confidential and restrict file permissions
  • Rotate keys and certificates according to policy

2. Certificate configuration​

  • Use strong cipher suites
  • Enable HTTP Strict Transport Security (HSTS) when ready
  • Configure OCSP stapling where supported
  • Use TLS 1.2 or later

3. Certificate monitoring​

  • Monitor expiration dates
  • Set expiration reminders
  • Automate renewal
  • Monitor revocation status

Conclusion​

Digital certificates combine public-key cryptography and CA trust to authenticate network endpoints. Understanding their contents and validation helps administrators and developers deploy TLS correctly.

Issuance, chain validation, and transparency mechanisms continue to evolve. Choose the right certificate profile and manage its lifecycle carefully.

As security threats change, keep your certificate practices and TLS configuration current to maintain trustworthy connections.