How SSL/TLS Certificates Work

SSL/TLS certificates are one of the fundamental building blocks of HTTPS. Whenever a browser connects to an HTTPS website, the server presents a certificate that helps the browser verify the server's identity and obtain the public key associated with that identity.

Although the terms SSL certificate and TLS certificate are often used interchangeably, modern systems use TLS rather than the obsolete SSL protocols. The certificate itself is still commonly called an SSL certificate because the older terminology remains widespread.

A certificate does not encrypt an entire website by itself. Instead, it binds an identity, such as a domain name, to a public key and provides a digitally signed statement that clients can validate through a certificate authority trust chain.

What Is an SSL/TLS Certificate?

An SSL/TLS certificate is a digitally signed data structure that associates a public key with an identity. For HTTPS websites, that identity is normally one or more domain names.

The certificate contains information such as the subject identity, Subject Alternative Name entries, public key, issuer, validity period, certificate serial number, and the certificate authority's digital signature.

SSL vs TLS

SSL, or Secure Sockets Layer, was the predecessor to TLS. SSL 2.0 and SSL 3.0 are obsolete and should not be used for modern secure communications.

TLS, or Transport Layer Security, replaced SSL and is the protocol used by modern HTTPS connections. Current deployments generally use TLS 1.2 and TLS 1.3, with TLS 1.3 providing a newer protocol design and removing several legacy cryptographic mechanisms.

Why Does HTTPS Need a Certificate?

Encryption alone does not solve the identity problem. Suppose a browser wants to connect to example.com and an attacker intercepts the connection. The browser needs a way to determine whether the public key it receives actually belongs to example.com.

A certificate provides this binding. A trusted certificate authority signs a certificate stating that a particular public key is associated with specified identities. The browser can then validate the certificate and use the associated public key as part of the TLS connection.

This creates two separate concepts: authentication of the server's identity and establishment of encryption keys. The certificate primarily helps with authentication; the TLS handshake then uses key exchange to establish session keys.

What Information Is Inside a Certificate?

Modern web certificates normally use the X.509 certificate format. X.509 defines the structure used to represent the identity, public key, issuer, validity information, extensions, and digital signature.

Subject Alternative Name

The Subject Alternative Name, usually abbreviated SAN, is one of the most important certificate extensions for HTTPS. It specifies the identities for which the certificate is valid.

DNS:example.com
DNS:www.example.com
DNS:api.example.com

If a browser connects to api.example.com, the certificate must contain an appropriate identity for that hostname. A certificate can be correctly signed, unexpired, and trusted while still being rejected because the requested hostname is not covered.

The Public Key

Every TLS certificate contains a public key. It is the public half of an asymmetric cryptographic key pair. The corresponding private key is kept by the certificate owner and should never be distributed with the certificate.

How Public and Private Keys Are Related

The public and private keys are mathematically related, but knowing the public key should not make it practical to derive the private key. The exact mathematics depends on the algorithm, such as RSA or elliptic-curve cryptography.

The certificate contains the public key. The private key is stored separately, usually on the server, load balancer, CDN, or other system terminating TLS.

What Is a Certificate Authority?

A Certificate Authority, or CA, is an organization trusted to issue and sign digital certificates according to its certificate policies and validation procedures.

Browsers and operating systems contain trust stores with trusted root certificates. If a server certificate can be validated through a chain that leads to an appropriate trusted root, the client can establish trust in the certificate's issuer.

The CA does not normally participate in every HTTPS connection. Once a certificate has been issued, browsers can validate the certificate and its chain locally using the information provided by the server and the client's trust store.

Root and Intermediate Certificate Authorities

Certificate authorities commonly use a hierarchy rather than signing every website certificate directly with a root certificate. A root CA can issue intermediate CA certificates, and intermediate certificates can issue leaf certificates for websites.

What Is a Certificate Chain?

A certificate chain connects a website's leaf certificate to a trusted root certificate. The chain allows a client to verify the signatures of certificates issued by intermediate authorities until it reaches a trusted certificate authority.

For a typical HTTPS website, the server sends its leaf certificate and the required intermediate certificates. The client already has the relevant trusted root certificate in its trust store.

Leaf certificate
example.com

Intermediate CA
Issuing authority

Root CA
Trusted root

The server generally does not need to send the trusted root certificate because the client is expected to obtain trust anchors from its own trust store.

How Certificate Chain Validation Works

When a client receives a certificate chain, it verifies the signatures and constraints between the certificates. It also determines whether the resulting chain terminates at a trusted root or another configured trust anchor.

• The client receives the server's leaf certificate.
• The client identifies the certificate issuer.
• The appropriate intermediate certificate is located or supplied by the server.
• The client verifies the issuer's signature over the certificate.
• The process continues through the chain.
• The chain must terminate at a trusted certificate authority.
• The client also checks hostname, validity, key usage, and other applicable constraints.

Why Certificate Chains Matter

A server can have a valid-looking leaf certificate and still cause TLS errors if it does not provide the necessary intermediate certificates. Clients do not always have the same ability to discover missing intermediates.

This is why inspecting the complete certificate chain is useful when diagnosing browser warnings, API connection failures, or TLS errors.

How a Certificate Is Issued

Before a certificate authority can issue a certificate, the certificate requester generates a key pair and creates a Certificate Signing Request, commonly called a CSR.

The CSR contains the public key and requested identity information. It is signed with the corresponding private key, allowing the CA to verify that the requester controls the private key associated with the submitted public key.

What Is a CSR?

A Certificate Signing Request is a structured request for a certificate. It typically contains a subject name, public key, requested extensions, and a signature created using the corresponding private key.

-----BEGIN CERTIFICATE REQUEST-----
...
-----END CERTIFICATE REQUEST-----

A CSR is not the certificate itself. It is a request that a certificate authority can process to create and sign a certificate.

What Does the CA Verify?

The exact validation depends on the type of certificate and the certificate authority's procedures. For publicly trusted web certificates, domain control validation is commonly used to establish that the requester controls the domain.

Validation can involve DNS records, HTTP resources, or email-based mechanisms depending on the validation method and CA. Higher-assurance certificate types can involve additional organization-related checks.

Domain Validation

Domain Validation, or DV, certificates establish control over a domain rather than providing extensive verification of an organization's legal identity.

DV certificates are commonly used for ordinary websites and APIs where the primary certificate requirement is to authenticate control of the domain.

Organization Validation

Organization Validation, or OV, certificates involve additional validation of organizational information. The certificate can contain organization-related details, subject to the CA's validation procedures.

OV does not mean that the TLS encryption itself is mathematically stronger than a comparable DV certificate. The distinction is primarily about the identity information and validation process.

Extended Validation

Extended Validation, or EV, certificates historically involved more extensive identity validation requirements. Modern browser interfaces generally do not display EV certificates as a special prominent visual treatment in the address bar in the way older browser versions did.

The cryptographic purpose of a certificate remains the same fundamental task: binding an authenticated identity to a public key within a trust system.

How a Browser Validates a Certificate

When a browser receives a certificate during the TLS handshake, it does not simply check whether the certificate exists. It performs a set of validation checks before allowing the connection to be treated as trusted.

• Build a valid certificate chain to a trusted root or trust anchor.
• Verify certificate signatures.
• Check the certificate validity period.
• Verify that the requested hostname is covered by the certificate.
• Check relevant key usage and extended key usage constraints.
• Apply applicable certificate policies and trust-store rules.
• Perform additional revocation or status checks according to the client and configuration.

Certificate Hostname Validation

Hostname validation ensures that a certificate issued for one domain is not automatically accepted for an unrelated domain.

Requested hostname:
shop.example.com

Certificate SAN:
DNS:api.example.com

In this example, the certificate does not cover shop.example.com. Even if the certificate is trusted, unexpired, and correctly signed, a browser should reject it for the requested hostname.

Wildcard Certificates

A wildcard certificate can cover multiple hostnames under a domain according to the wildcard rules used by hostname validation.

*.example.com

A wildcard such as *.example.com can cover hostnames such as api.example.com and www.example.com, but wildcard matching has defined scope and does not mean every possible subdomain or unrelated domain is covered.

Certificate Validity Period

Certificates contain Not Before and Not After timestamps. A client normally rejects a certificate if the current time falls outside this validity period.

Certificate expiration is operationally important because an otherwise correctly configured HTTPS service can suddenly begin producing certificate errors when its certificate expires.

Certificate Renewal

Certificate renewal replaces an existing certificate with a new certificate before the old one expires. Automated certificate issuance and renewal have become common because manually tracking certificates across many services is error-prone.

A renewal can involve generating a new key pair or reusing an existing key according to the organization's security and certificate-management policy. After obtaining the new certificate, the server or TLS termination layer must be configured to use it.

Certificate Revocation

A certificate may need to be revoked before its natural expiration date. Reasons can include compromise of the private key, incorrect issuance, or other events defined by certificate policies.

Certificate revocation and status checking involve mechanisms such as Certificate Revocation Lists and the Online Certificate Status Protocol. Actual browser behavior varies, and modern certificate ecosystems use additional mechanisms to improve revocation information delivery.

Does a Certificate Encrypt HTTPS Traffic?

Not by itself. The certificate provides identity and public-key information used by the TLS protocol. The TLS handshake then establishes shared session keys, and those symmetric keys protect the application data.

This distinction is important because replacing a certificate does not mean that the website suddenly switches from one type of bulk encryption to another. The certificate and the negotiated TLS session algorithms perform different roles.

How the Certificate Fits Into the TLS Handshake

The certificate is presented during the TLS handshake. The exact messages depend on the TLS version, but the general process involves the server presenting its certificate and proving possession of the corresponding private key.

The client validates the certificate and then participates in key exchange. After the handshake is successfully completed, symmetric traffic keys protect the HTTPS application data.

TLS 1.2 and Certificates

TLS 1.2 can use certificates with several authentication and key-exchange configurations. Modern deployments commonly use certificates for server authentication while using ephemeral Diffie-Hellman key exchange for session key establishment.

The certificate's public key algorithm and the selected TLS authentication mechanism must be compatible with the server configuration and client capabilities.

TLS 1.3 and Certificates

TLS 1.3 continues to use certificates for server authentication, but it separates certificate authentication from key exchange more clearly. Modern TLS 1.3 connections use ephemeral key exchange and authenticated encryption.

The server's Certificate message contains the certificate chain, while CertificateVerify proves possession of the private key corresponding to the authentication certificate.

RSA Certificates vs ECC Certificates

Certificates can contain public keys based on different cryptographic algorithms. RSA and elliptic-curve algorithms are two important families used in TLS deployments.

The choice of certificate key algorithm should account for the server software, clients, infrastructure, operational requirements, and compatibility constraints. Certificate key type and TLS key exchange are related but are not necessarily the same thing.

Certificate Signature vs Server Key

A certificate contains both a public key associated with the subject and a signature created by the issuer. These serve different purposes.

What Is a Self-Signed Certificate?

A self-signed certificate is signed by the same key represented by the certificate rather than by a separate trusted certificate authority.

Self-signed certificates can be useful in development, testing, private environments, or systems with an explicitly configured private trust infrastructure. A public browser will not automatically trust an arbitrary self-signed certificate.

Private Certificate Authorities

Organizations can operate private certificate authorities for internal services. Devices and applications that should trust these certificates can be configured with the organization's private root certificate.

Private PKI is common in enterprise environments, internal networks, service-to-service systems, and other situations where public browser trust is not required.

PEM Certificates

PEM is a common text-based encoding used to store certificates, certificate signing requests, and private keys. PEM data is typically Base64-encoded and surrounded by BEGIN and END markers.

-----BEGIN CERTIFICATE-----
MIIC...
...
-----END CERTIFICATE-----

The PEM wrapper identifies the type of object contained in the encoded data. A certificate, CSR, and private key use different PEM labels.

DER vs PEM

DER and PEM are commonly encountered certificate representations. DER is a binary encoding based on ASN.1 Distinguished Encoding Rules, while PEM typically contains Base64-encoded DER wrapped in text markers.

Certificate File Extensions

Certificate file extensions do not always tell you everything about the underlying encoding. Common extensions include .crt, .cer, and .pem, but their exact contents depend on how the file was created.

When the file format is uncertain, inspecting the certificate contents is more reliable than assuming the encoding from the extension alone.

How to Read a Certificate

A certificate viewer can expose the fields that are otherwise difficult to read in their encoded representation. Useful fields to inspect include the subject alternative names, issuer, validity dates, public key algorithm, key size or curve, signature algorithm, key usage, and basic constraints.

A PEM Certificate Viewer is particularly useful when you have a PEM certificate and need to inspect its metadata without manually parsing the ASN.1 structure.

How to Inspect a Certificate Chain

When a website has TLS problems, inspecting the entire chain can reveal issues that are invisible when looking only at the leaf certificate.

• Identify the leaf certificate for the requested hostname.
• Check the issuer of the leaf certificate.
• Verify that the expected intermediate certificate is present.
• Check the intermediate certificate's issuer.
• Confirm that the chain reaches an appropriate trusted root.
• Look for expired, revoked, or incorrectly constrained certificates.

A Certificate Chain Viewer can make this process easier by presenting the certificates in the chain together rather than requiring each certificate to be inspected separately.

Common Certificate Errors

Certificate Error vs TLS Version Error

Certificate problems and TLS protocol problems occur at different parts of the connection process. A certificate can be perfectly valid while the client and server still fail to negotiate a compatible TLS version.

Conversely, a client and server can successfully negotiate TLS while certificate validation fails. Troubleshooting should therefore distinguish certificate validation errors from protocol negotiation errors.

How to Troubleshoot Certificate Problems

• Check the exact hostname requested by the client.
• Inspect the certificate's Subject Alternative Name entries.
• Check the Not Before and Not After dates.
• Inspect the issuer and certificate chain.
• Verify that all required intermediate certificates are configured.
• Check whether the client trusts the root certificate.
• Inspect key usage and extended key usage.
• Confirm that the server has access to the correct private key.
• Determine whether a CDN, reverse proxy, or load balancer terminates TLS.
• Check the negotiated TLS version separately from certificate validation.

What Happens If the Private Key Is Lost?

A certificate is not sufficient to operate the corresponding TLS endpoint. The server needs the private key associated with the public key in the certificate.

If the private key is permanently lost, the certificate cannot simply be used with a different unrelated private key. A new key pair and certificate are normally required.

What Happens If the Private Key Is Compromised?

If an unauthorized party obtains a private key, the certificate's security assumptions can be compromised. The appropriate response depends on the circumstances, but certificate replacement and revocation may be necessary.

Certificates and CDNs

When a website uses a CDN or reverse proxy, the certificate visible to the browser may be installed on the CDN rather than the origin server.

There can therefore be multiple TLS connections in the architecture. For example, a browser can establish TLS with the CDN while the CDN establishes another TLS connection with the origin. Each connection can have its own certificate and configuration.

Certificates and Load Balancers

A load balancer can terminate TLS before forwarding requests to application servers. This centralizes certificate management and allows multiple backend servers to receive already-decrypted application traffic.

Alternatively, an organization can use TLS between the load balancer and backend servers as well. In that architecture, the internal connection requires its own certificate configuration.

How Long Should a Certificate Be Valid?

Publicly trusted TLS certificates have limited validity periods, and the maximum permitted lifetime has become progressively shorter over time. The exact maximum depends on the applicable industry rules and issuance date.

Shorter certificate lifetimes increase the importance of automated renewal. Organizations should avoid designing certificate management around manual renewal as the only operational process.

Certificate Transparency

Certificate Transparency, commonly abbreviated CT, is a system for publicly logging certificates issued by participating certificate authorities. The goal is to make certificate issuance observable and auditable.

Modern publicly trusted certificates are generally expected to satisfy applicable Certificate Transparency requirements. CT logs can also be useful when monitoring which certificates have been issued for a domain.

Are SSL/TLS Certificates Free?

The cost of a certificate depends on the certificate authority, certificate type, validation requirements, and services included. Publicly trusted domain certificates can be obtained at no certificate fee from some certificate authorities, while commercial certificate products can include additional services.

The cryptographic security of HTTPS does not inherently require a paid certificate. What matters is that the certificate is appropriately issued and trusted by the intended clients.

Do You Need a Different Certificate for Every Domain?

Not necessarily. A certificate can cover multiple domain names through Subject Alternative Name entries, and wildcard certificates can cover a defined group of subdomains.

Whether to use one certificate for several names or separate certificates depends on operational requirements, certificate-management practices, infrastructure, and the desired separation between services.

Can One Certificate Be Used on Multiple Servers?

A certificate can be installed on multiple TLS termination points if the corresponding private key is also available there. This can be useful for load-balanced services, but distributing the same private key to many systems increases the number of places where that sensitive key must be protected.

Organizations may instead use separate certificates and keys for different servers or termination points when that provides better isolation or operational control.

Certificate Management Best Practices

• Automate certificate issuance and renewal where practical.
• Monitor expiration dates continuously.
• Protect private keys with appropriate access controls.
• Keep intermediate certificates configured correctly.
• Use modern TLS versions and cryptographic algorithms.
• Verify hostname coverage before deploying certificates.
• Track certificates across production, staging, and internal environments.
• Document where TLS terminates in the infrastructure.
• Replace compromised certificates and keys promptly.
• Test certificate renewal before the existing certificate expires.

A Practical Certificate Inspection Workflow

When investigating an HTTPS certificate, start with the domain name and inspect the certificate presented by the TLS endpoint. Check the SAN entries, validity dates, issuer, public key, and certificate chain.

If the certificate looks correct, inspect the TLS protocol configuration separately. This helps determine whether the problem is certificate validation, TLS negotiation, or another part of the network architecture.

For a local certificate file, a PEM Certificate Viewer can reveal its fields, while a Certificate Chain Viewer can help analyze the relationship between certificates. A CSR Decoder can be used when investigating the original certificate request and its requested identity information.

Frequently Asked Questions

Helpful Certificate Tools

A Certificate Chain Viewer is useful for inspecting the relationship between leaf, intermediate, and root certificates. A PEM Certificate Viewer can decode certificate metadata such as SAN entries, issuers, validity dates, and public keys. A Certificate Expiration Checker helps monitor certificate lifetimes, while a TLS Version Checker can distinguish certificate problems from TLS protocol configuration issues. A CSR Decoder is useful for inspecting the contents of a Certificate Signing Request before or after certificate issuance.

Conclusion

SSL/TLS certificates provide an important identity layer for HTTPS. They bind domain identities to public keys and use digital signatures and certificate chains to allow clients to establish trust in those bindings.

The certificate is only one part of HTTPS. During the TLS handshake, the client validates the certificate while the client and server negotiate cryptographic parameters and establish shared session keys. Symmetric encryption then protects the application data exchanged over the connection.

Understanding certificates means understanding more than expiration dates. Hostname validation, SAN entries, certificate chains, private-key protection, certificate authorities, CSRs, TLS versions, and renewal all affect whether an HTTPS service works correctly and remains trustworthy.