In today’s digital landscape, secure communication over the internet is not just an option – it is a necessity. Whether you’re hosting a website, developing APIs, or building enterprise-grade applications, understanding how digital certificates work is essential for ensuring confidentiality, integrity and trust between systems and users.

This article offers a comprehensive overview of the key concepts and mechanisms behind digital certificates, including certificate types (DV, OV, EV), domain coverage options (single, multi-domain, SAN), cryptographic key usage (public / private), certificate requests (CSR) and the different encoding and file formats such as PEM, DER and PFX. We’ll also cover critical aspects of certificate lifecycle management, including revocation mechanisms like Certificate Revocation Lists (CRLs) and OCSP (Online Certificate Status Protocol), which are essential for maintaining trust in dynamic environments.

1. Certificate types: DV, OV and EV

Digital certificates differ in the level of validation they provide, which impacts the degree of trust they convey to users and systems.

1. Domain Validation (DV)

DV certificates verify that the applicant has administrative control over a specific domain. Validation is typically automated and performed via DNS records, email verification, or HTTP-based challenges.

• Use case: Personal websites, staging environments, microservices.
• Advantages: Fast issuance, low cost (or free), widely supported.
• Limitations: Offers no assurance about the organization behind the domain.
  1. Organization Validation (OV)

OV certificates verify both the domain ownership and the existence of a legitimate organization. The Certificate Authority (CA) validates the organization’s legal status using government or public databases and ensures that the request is authentic.

• Use case: Business websites, SaaS platforms.
• Advantages: Displays organization details in the certificate, increasing user trust.
• Limitations: Requires manual validation, longer issuance time and typically incurs a cost.
  1. Extended Validation (EV)

EV certificates involve the most thorough vetting process, including operational, legal and physical verification of the requesting entity. The organization must prove exclusive control over the domain and go through detailed identity checks.

• Use case: Banks, financial institutions, e-commerce, government portals.
• Advantages: Maximum trust; some browsers display the organization name prominently.
• Limitations: Longer and more rigorous validation process, higher cost.

2. Domain coverage: single, wildcard and multi-domain certificates

A certificate can cover one or more domain names, depending on the use case and the structure of the application or infrastructure.

1. Single-domain certificates

A single-domain certificate secures exactly one domain, such as example.com. It does not automatically cover subdomains like www.example.com unless explicitly included.

• Best for: Simple websites or services with a fixed domain structure.
  1. Wildcard certificates

A wildcard certificate secures all first-level subdomains of a specific domain. For example, *.example.com will secure www.example.com, mail.example.com and api.example.com, but not example.com itself unless that is added separately.

• Best for: Environments with many subdomains that need to be managed dynamically.
  1. Multi-domain certificates

Multi-domain certificates allow multiple, distinct domains and subdomains to be secured within a single certificate. These entries are configured via the Subject Alternative Name (SAN) extension. Unlike wildcard certificates, multi-domain certificates can cover unrelated domain names (e.g., example.com, example.org, anotherdomain.net).

• Best for: Organizations hosting multiple sites or services under different domains that want to simplify certificate management.

Note: Modern browsers validate the domain name against the SAN field. The Common Name (CN) field is no longer used for this purpose when SAN is present.

3. The Certificate Signing Request (CSR)

A Certificate Signing Request (CSR) is the formal request submitted to a CA to obtain a digital certificate. It is generated on the server that will host the certificate and contains:

• The public key, which will be embedded in the certificate.
• Information about the entity (organization name, country, domain, etc.).
• A digital signature, created using the corresponding private key.

The CSR is usually encoded in PEM format and looks like this:

—–BEGIN CERTIFICATE REQUEST—–

MIIC3TCCAcUCAQAwgYUxCzAJBgNVBAYTAk…

—–END CERTIFICATE REQUEST—–

This file is never meant to be published. It is sent to the CA for signing, which will issue a certificate if the validation succeeds.

4. Asymmetric cryptography: public and private keys

At the core of SSL/TLS lies asymmetric cryptography, which uses a key pair:

1. Public Key

• Shared with the world and included in the certificate.
• Used by clients to encrypt data sent to the server or to verify digital signatures from the server.
  1. Private Key
• Kept secret and stored securely on the server.
• Used to decrypt data and create digital signatures.
• If this key is compromised, the certificate is no longer secure.

Security best practice: The private key should never be transferred over the network, emailed, or shared. Always store it in a secure location (e.g., a hardware security module or secure key vault).

5. Certificate encodings and file formats: PEM, DER, PFX explained

Digital certificates and private keys can be stored and transmitted in several file formats, each of which uses a specific data encoding method. It is important to clearly distinguish between:

• the container format (PEM, DER, PFX) and
• the data encoding (Base64 or binary).

Below is a corrected and clarified explanation of the most common formats:

1. PEM (Privacy Enhanced Mail)

• Encoding: Base64-encoded text.
• Structure: Begins and ends with delimiters such as:

—–BEGIN CERTIFICATE—–

(Base64 data)

—–END CERTIFICATE—–

• Content: May include certificates, private keys, CSRs, or CA chains.
• File extensions: .pem, .crt, .cer, .key (Note: extensions alone are not conclusive.)
• Common in: Unix/Linux systems, OpenSSL, Apache, Nginx.
  1. DER (Distinguished Encoding Rules)
• Encoding: Binary (ASN.1 encoded).
• Content: The same information as PEM, just in binary format.
• File extensions: .der, .cer
• Use case: Commonly used in Windows environments or Java-based systems.
• Not human-readable and cannot be safely edited with a text editor.
• Conversion between PEM and DER is possible using tools like OpenSSL.
  1. CRT / CER
• These are generic extensions.
• Files with these extensions may contain either PEM (text/Base64) or DER (binary).
• Always inspect the file (e.g., open in a text editor or check with OpenSSL) to identify the true format.
  1. PFX / PKCS#12
• Encoding: Binary, encoded using the PKCS#12 standard.
• Container: Bundles multiple objects in a single file:
  • The certificate
  • The private key
  • Optional CA chain (intermediate + root certs)
• File extensions: .pfx, .p12
• Encrypted and password protected.
• Used in: Windows (IIS), Java KeyStores, browsers and enterprise tools.

6. Base64 encoding: what it does and why it matters

Base64 is not a file format, but an encoding mechanism used to represent binary data as plain ASCII text. This is essential for safely transferring and storing cryptographic content (certificates, keys) in environments that expect text (e.g., email, scripts, config files).

• PEM format uses Base64 to encode binary certificate/key data and wraps it with headers.
• DER and PFX formats are pure binary and must not be Base64-encoded.
• Base64 is useful for:
  • Preventing corruption during transfer.
  • Embedding in text-based protocols (HTTP, JSON, XML).
  • Making the content editable/viewable in text editors.

7. Certificate Revocation Lists (CRLs)

A Certificate Revocation List (CRL) is a signed file generated by a Certificate Authority (CA) that lists digital certificates that are no longer valid before their scheduled expiration. Revocations can happen for various reasons – such as a compromised private key, policy changes, or administrative errors.

Each CRL contains

• The serial numbers of revoked certificates
• The revocation date for each certificate
• Optionally, a reason code (e.g., keyCompromise, cessationOfOperation)
• A next update field indicating when the CA will issue the next CRL

Clients retrieve the CRL from the location specified in the certificate’s CRL Distribution Point (CDP) extension, typically via HTTP, LDAP, or a file path. During validation, the client checks if the certificate’s serial number appears in the list.

Technical limitations

• Not real-time: there’s a delay between the revocation event and when clients receive the updated list
• Performance impact: large CRLs take longer to download and process
• Stale data: clients need to refresh CRLs regularly to avoid using outdated revocation info

Because of these limitations, many systems supplement CRLs with OCSP (Online Certificate Status Protocol) to get up-to-date revocation status on demand.

8. Online Certificate Status Protocol (OCSP)

OCSP is a protocol designed to provide real-time verification of a digital certificate’s revocation status. Unlike CRLs, which list revoked certificates in bulk and are updated periodically, OCSP allows clients to query an OCSP responder server about the status of a single certificate on demand.

An OCSP request contains the certificate’s serial number, and the responder replies with one of three states:

• Good (the certificate is valid)
• Revoked (the certificate has been revoked)
• Unknown (the responder cannot determine the status)

OCSP responses are digitally signed by the responder to ensure authenticity. The location of the OCSP responder is typically included in the certificate’s Authority Information Access (AIA) extension.

OCSP reduces latency and bandwidth usage compared to CRLs, making it well suited for environments where up-to-date revocation information is critical.

9. Industry update: TLS certificate lifetimes reduced to 47 days

If you manage TLS certificates, take note: the rules are changing. Starting March 15, 2026, the maximum validity for public TLS certificates will drop from 398 days to 200 days. That’s just the first cut. A year later, it’ll be 100 days, and by 2029, certificates will top out at just 47 days.

Why the change? It’s about reducing risk. A short-lived certificate means less time for attackers to exploit a compromised key, and less chance of old or inaccurate info hanging around. The CA/Browser Forum – the group that sets the standards for certificate authorities and browsers – approved the change in April 2025. Now everyone has a few years to adapt.

If you’re still handling certs manually, even once a year, this schedule is going to force a change. Renewing every few months, or even every few weeks, needs automation. It doesn’t have to be complicated, but it must be reliable.

Sources:

https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days

https://www.infosecurity-magazine.com/news/digital-certificate-lifespans-fall/

Practical example: creating a browser-trusted SAN certificate, signed by a Windows internal CA, using KeyStore Explorer

The KeyStore Explorer is a user-friendly, open-source desktop application that helps you manage security certificates and keystores without needing to use command-line tools like Java’s keytool. It lets you create and organize different types of keystores, generate key pairs, handle certificate signing requests, and import or export certificates. Available from here: https://keystore-explorer.org/downloads.html

The following section outlines the step-by-step process of generating a SAN certificate using KeyStore Explorer, from key pair creation to CSR generation with SAN extensions and finally importing the CA-signed certificate – ensuring browser compatibility through proper signing by a trusted internal Windows Certificate Authority.

1. Create a new KeyStore
   
2. Prepare to generate a public-private RSA key pair
   
3. Fill in the subject
   
   
4. Add Certificate Extension  Use Standard Template: TLS/SSL Server
   
5. Specify DNS(s) / IP(s) in Subject Alternative Name (SAN)
   
6. Finalize a public-private key pair: Enter alias and KeyStore password
7. Generate CSR (Certificate Signing Request)
   
8. Go to CA server  Enter the content of the CSR file  Use the Web Server template  Export certificate chain in Base64 encoded.
   
   
9. Import CA Reply (certnew.p7b) into the key pair
   
10. The signed certificate is ready
    
11. Export key pair in PKCS#12 (.pfx)
    
12. Import the signed certificate in IIS  Add a certificate to a site  Restart the site. It works: the connection is secure.