What Is a Digital Certificate?

A digital certificate is an electronic document that binds a public key to an identity (a person, organization, device, or domain). It is issued and signed by a trusted third party called a certificate authority (CA). Digital certificates are the mechanism that makes encrypted and authenticated communication possible on the internet, from HTTPS websites to signed emails to verified software.

The most common type of digital certificate is the SSL/TLS certificate used by websites, but digital certificates serve many other purposes. This guide explains the concept broadly, covering all major certificate types and the infrastructure that makes them work. For details specific to web certificates, see What Is an SSL Certificate?.

How Digital Certificates Work

The core problem digital certificates solve is identity verification in a world where you cannot physically meet the other party. When you connect to a bank's website, how do you know it is really the bank and not an impersonator? When you download software, how do you know it was actually created by the claimed developer?

Digital certificates solve this through a combination of cryptography and trusted third parties.

The Components

A digital certificate contains:

• Subject: The entity the certificate identifies (a domain name, person, organization, or device).
• Public key: The subject's public key, which is paired with a private key that only the subject holds.
• Issuer: The certificate authority that verified the subject's identity and signed the certificate.
• Validity period: The dates between which the certificate is valid.
• Serial number: A unique identifier assigned by the issuer.
• Signature: The CA's digital signature, created using the CA's private key.
• Extensions: Additional fields like key usage, subject alternative names, and certificate policies.

The Verification Process

When you receive a digital certificate, you verify it by:

1. Checking the CA's signature using the CA's public key (obtained from a trusted root certificate).
2. Verifying that the certificate has not expired.
3. Checking that the certificate has not been revoked.
4. Confirming that the subject matches the expected identity (e.g., the domain name in the URL).

If all checks pass, you can trust that the public key in the certificate belongs to the claimed identity.

The X.509 Standard

Most digital certificates on the internet follow the X.509 standard (defined in RFC 5280). X.509 specifies the format for public key certificates, including the fields, encoding (ASN.1/DER), and extensions.

When people say "digital certificate" in the context of the internet, they almost always mean an X.509 certificate. The format is used for SSL/TLS certificates, code signing certificates, email certificates (S/MIME), and client authentication certificates.

X.509 certificates are typically encoded in one of two formats:

• PEM (Privacy Enhanced Mail): Base64-encoded, text-based format. Files typically end in .pem, .crt, or .cer. The content starts with -----BEGIN CERTIFICATE-----.
• DER (Distinguished Encoding Rules): Binary format. Files typically end in .der or .cer.

Both formats contain the same information; PEM is just a text representation of the binary DER encoding.

Types of Digital Certificates

SSL/TLS Certificates

SSL/TLS certificates authenticate websites and enable HTTPS connections. They are installed on web servers and presented to browsers during the TLS handshake. This is by far the most common type of digital certificate.

SSL/TLS certificates come in variants based on validation level (DV, OV, EV) and domain coverage (single, wildcard, multi-domain). See Types of SSL Certificates for details.

Code Signing Certificates

Code signing certificates verify the identity of software developers and ensure that software has not been tampered with since it was signed. When you download an application and your operating system says "This software is from [Developer Name]," it has verified the code signing certificate.

Without a valid code signature, operating systems display warnings like "Windows protected your PC" or "This app is from an unidentified developer." Code signing certificates are issued by CAs after verifying the developer's identity through an OV or EV process.

Email Certificates (S/MIME)

S/MIME (Secure/Multipurpose Internet Mail Extensions) certificates enable encrypted and digitally signed email. When you receive a signed email, you can verify that it was sent by the claimed sender and has not been modified in transit. When you send an encrypted email, only the recipient can read it.

S/MIME certificates contain the user's email address as the subject and are issued by CAs after verifying the email address or the user's identity.

Client Authentication Certificates

Client certificates authenticate a user or device to a server, rather than the other way around. Standard HTTPS authenticates only the server. With mutual TLS (mTLS), both the server and the client present certificates.

Client certificates are used in enterprise environments for VPN access, API authentication, and zero-trust architectures. See mTLS Explained.

Document Signing Certificates

Document signing certificates are used to digitally sign PDFs, contracts, and other documents. They verify the signer's identity and ensure the document has not been modified after signing. Adobe Acrobat and other PDF readers verify document signatures against a list of trusted CAs.

Public Key Infrastructure (PKI)

Digital certificates exist within a framework called Public Key Infrastructure (PKI). PKI is the set of technologies, policies, and procedures that support the issuance, management, and revocation of digital certificates.

Components of PKI

Certificate Authorities: Organizations that issue and sign certificates after verifying the subject's identity.

Registration Authorities: Entities that verify certificate requests on behalf of the CA. In some models, the RA handles identity verification while the CA handles signing.

Certificate Revocation Lists (CRLs): Lists of certificates that have been revoked before their expiration date. CAs publish CRLs, and relying parties check them to ensure a certificate has not been revoked.

Online Certificate Status Protocol (OCSP): A protocol for checking the revocation status of a specific certificate in real time, as an alternative to downloading and checking CRLs. See SSL Certificate Revocation.

Trust Stores: Collections of root certificates that browsers and operating systems trust. These are the trust anchors that the entire PKI hierarchy depends on.

The Certificate Chain

Digital certificates form a chain of trust:

Root CA Certificate (in browser's trust store)
    |
    +-- Intermediate CA Certificate (signed by Root CA)
            |
            +-- End-Entity Certificate (signed by Intermediate CA)

The root certificate is self-signed and pre-installed in trust stores. The intermediate certificate is signed by the root. The end-entity certificate (your website's certificate) is signed by the intermediate.

This layering serves two purposes:

1. Security: The root CA's private key is kept offline in a hardware security module. If the intermediate CA's key is compromised, only the intermediate is revoked, not the root.
2. Scalability: Multiple intermediate CAs can operate under a single root, distributing the workload of certificate issuance.

For a detailed walkthrough, see SSL Certificate Chain Explained.

Certificate Lifecycle

Every digital certificate goes through a lifecycle:

Request: The subject generates a key pair and sends a Certificate Signing Request (CSR) to the CA. The CSR contains the public key and identifying information.

Validation: The CA verifies the subject's identity according to the certificate type's requirements.

Issuance: The CA signs the certificate with its private key and delivers it to the subject.

Installation: The subject installs the certificate on their server, device, or application.

Usage: The certificate is presented to relying parties (browsers, email clients, operating systems) for verification.

Renewal: Before the certificate expires, the subject requests a new certificate. The validation process may be repeated.

Revocation: If the certificate's private key is compromised or the certificate was issued in error, the CA revokes it. Revocation is published through CRLs and OCSP.

Expiration: When the validity period ends, the certificate is no longer trusted.

Digital Signatures

Digital certificates enable digital signatures, which are used to verify the authenticity and integrity of data.

The signing process:

1. The signer creates a hash (a fixed-size digest) of the data.
2. The signer encrypts the hash with their private key. This encrypted hash is the digital signature.
3. The signature is attached to the data.

The verification process:

1. The verifier decrypts the signature using the signer's public key (from their certificate), recovering the original hash.
2. The verifier creates their own hash of the data.
3. If the two hashes match, the data has not been modified and was signed by the certificate holder.

Digital signatures are used in SSL/TLS (the CA signs the certificate), code signing (the developer signs the software), email (the sender signs the message), and document signing.

Certificate Formats and Files

You will encounter certificates in various file formats:

• .pem: PEM-encoded certificate (text, Base64). Most common on Linux.
• .crt / .cer: Can be PEM or DER encoded. The extension alone does not indicate the format.
• .der: DER-encoded certificate (binary).
• .pfx / .p12: PKCS#12 format. Contains the certificate, intermediate certificates, and private key in a single encrypted file. Common on Windows.
• .key: A private key file (usually PEM-encoded).
• .csr: A Certificate Signing Request.

For decoding and inspecting certificate files, see How to Decode SSL Certificate.

References

1. RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile," May 2008. https://datatracker.ietf.org/doc/html/rfc5280
2. NIST SP 800-32, "Introduction to Public Key Technology and the Federal PKI Infrastructure," February 2001. https://csrc.nist.gov/pubs/sp/800/32/final
3. ITU-T, "X.509: Information technology -- Open Systems Interconnection -- The Directory: Public-key and attribute certificate frameworks," https://www.itu.int/rec/T-REC-X.509