All You Need to Know About SSL Certificates

An SSL/TLS certificate is a digitally signed data structure, usually following the X.509 standard. It contains information about the identity it represents, its public key, its issuer, its validity period, and other attributes that help clients decide whether to trust it.

For a website, the certificate typically identifies one or more domain names, such as example.com and www.example.com.

A certificate is not the same thing as a private key, and it does not encrypt every connection by itself. Instead, it helps a client authenticate a server and establish a secure connection using TLS.

What does a certificate contain?

• Subject: The entity or identity represented by the certificate.
• Subject Alternative Name (SAN): The DNS names or IP addresses for which the certificate is valid.
• Public key: The public portion of an asymmetric cryptographic key pair.
• Issuer: The certificate authority or other entity that signed the certificate.
• Validity period: The dates between which the certificate is intended to be valid.
• Serial number: An identifier assigned by the issuer.
• Extensions: Additional information such as permitted key usage, server authentication, and certificate authority constraints.
• Digital signature: A cryptographic signature used to verify the certificate's integrity and its relationship to the issuer's signing key.

1. 01

   Confidentiality

   Protect information in transit

   TLS encrypts network traffic so that an observer generally cannot read the contents of a properly secured connection.

   Certificates help authenticate the endpoint and support the cryptographic handshake used to establish that encrypted session.

   Example

   A customer submits payment information to your website over HTTPS rather than sending it as readable HTTP traffic.

2. 02

   Authentication

   Help verify who you are connecting to

   A client validates the certificate's chain of trust, checks the requested hostname, and evaluates its validity before accepting the connection.

   Example

   A browser checks that the certificate presented by shop.example.com is valid for that hostname and chains to a trusted authority.

3. 03

   Integrity

   Help detect tampering

   TLS uses authenticated encryption to protect data in transit against undetected modification. Certificate signatures also help clients detect unauthorized changes to certificate contents.

   Example

   An attacker who modifies encrypted application traffic should not be able to make those changes pass the connection's integrity checks.

4. 04

   Digital identity

   Support signatures and identity-based security

   Certificates can associate public keys with identities for email signing, code signing, client authentication, and other security systems.

   Example

   An organization signs software releases so that users can verify the signature against the corresponding public key and certificate.

First, understand the two keys

Asymmetric cryptography uses a mathematically related public key and private key.

• Public key: Shared openly and included in the certificate.
• Private key: Protected by its owner and never intentionally distributed with the certificate.

Depending on the algorithm and operation, the keys can support digital signatures, key establishment, or other cryptographic functions.

Modern TLS typically uses the certificate's public key to authenticate the server's signature during the handshake. The session's traffic keys are established separately using the TLS key exchange process.

What happens during a typical HTTPS connection?

1. Connection begins. The client and server negotiate supported TLS parameters.
2. The server presents its certificate. It may also send intermediate certificates needed to build a chain of trust.
3. The client validates the certificate. It checks the chain, hostname, validity period, and applicable security requirements.
4. The server proves possession of its private key. In modern TLS, this typically includes a handshake signature verified using the certificate's public key.
5. Session keys are established. Both sides derive cryptographic keys used to protect the connection.
6. Application data is exchanged. HTTP requests and responses travel inside the protected TLS connection.

Why use symmetric encryption after the handshake?

Public-key operations are useful for authentication and key establishment, but symmetric algorithms are generally more efficient for protecting large amounts of data.

Modern TLS commonly uses authenticated encryption with associated data (AEAD), such as AES-GCM or ChaCha20-Poly1305. These algorithms protect confidentiality and detect unauthorized modification.

By validation level

By the identity or purpose they cover

• Single-name certificate: Covers one DNS name, such as api.example.com.
• Wildcard certificate: Can cover names one label below a wildcard, such as *.example.com. It does not ordinarily cover example.com itself or api.eu.example.com.
• Multi-name certificate: Uses Subject Alternative Names to cover several DNS names or supported IP address identifiers.
• Server authentication certificate: Used by a server to authenticate itself to clients.
• Client authentication certificate: Used by a client to authenticate itself to a server, as in mutual TLS (mTLS).
• Email certificate: Can support S/MIME email signing and encryption when issued with appropriate identity information and permitted key usages.
• Code-signing certificate: Used to sign software or other code artifacts so recipients can verify the signature and signer identity.
• CA certificate: Used by a certificate authority to issue or validate other certificates, subject to its constraints.

Publicly trusted vs. privately trusted

A publicly trusted certificate chains to a root certificate recognized by the relevant browser or operating system. A privately trusted certificate chains to an internal root distributed through an organization's trust-management system.

Private PKI is common for internal APIs, corporate devices, development systems, and services that should not rely on public certificate authorities.

Several cryptographic components work together in a TLS connection. They have different jobs and should not be treated as interchangeable.

What about AES and ChaCha20?

AES and ChaCha20 are symmetric encryption algorithms. They commonly protect the actual data exchanged after the TLS handshake.

AES-GCM and ChaCha20-Poly1305 combine encryption with authentication, helping prevent an attacker from silently modifying encrypted traffic.

What should a business choose?

• Use a currently supported TLS version, preferably TLS 1.3 where the environment permits it.
• Use modern, approved cipher suites and key sizes.
• Prefer algorithms supported by your clients, server software, and certificate authority.
• Keep private keys secure and monitor certificate expiry.
• Do not choose an algorithm solely because it has the longest key or sounds the most advanced.

When a browser connects to a website, it needs a way to determine whether the certificate should be trusted. A trusted CA helps establish that trust by signing the certificate, or by signing an intermediate CA certificate that eventually connects to a trusted root.

Why do I need a CA?

Without an established trust mechanism, a client cannot reliably distinguish a legitimate server's public key from a key supplied by an impostor.

A trusted CA provides a way to verify that a certificate was issued according to the CA's validation process. The browser still needs to check the certificate's hostname, validity, chain, and applicable policy.

Public CAs are commonly used for public websites. Internal CAs are often used when an organization controls the clients and can distribute its own trusted root securely.

What is a root CA?

A root CA certificate is typically self-signed and explicitly trusted through a trust store. Root private keys are especially sensitive and are commonly kept offline or protected by dedicated security controls.

What is an intermediate CA?

An intermediate CA is authorized to issue other certificates under constraints established by its issuer. Intermediates allow certificate issuance to be separated from the root's highly protected private key.

A publicly trusted website certificate is normally issued through a trusted CA chain. A self-signed certificate does not establish that kind of third-party trust by itself.

However, self-signed certificates are not inherently insecure. They can be useful in controlled environments where the certificate is securely distributed and trusted through an independent process.

When does self-signing make sense?

• Local development and testing.
• Temporary test services and isolated lab environments.
• Internal systems where trust is managed explicitly.
• Creating a private root CA for an organization, provided it is properly secured and managed.

When should you avoid it?

Avoid using an untrusted self-signed certificate for a public-facing website when users are expected to connect without manual trust configuration.

Browser warnings can train users to ignore security alerts, and an attacker may exploit that behavior.

openssl req -x509 -newkey rsa:3072 \
  -keyout dev.key \
  -out dev.crt \
  -sha256 \
  -days 30 \
  -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"

.pem, .crt, .cer, and .key are filename extensions. They often suggest a file's contents, but the extension alone does not prove what the file contains or how it is encoded.

-----BEGIN CERTIFICATE-----
MIID...
-----END CERTIFICATE-----

Quick comparison

Convert PEM to DER

openssl x509 -in certificate.pem \
  -outform DER \
  -out certificate.der

Convert DER to PEM

openssl x509 -inform DER \
  -in certificate.der \
  -outform PEM \
  -out certificate.pem

Inspect a certificate without guessing its contents

openssl x509 -in certificate.crt -noout -text

If OpenSSL reports that it cannot parse the input, verify the file format and encoding before attempting a conversion.

Certificates can contain different identity attributes. A certificate issued for a public website usually identifies the domain names it covers. An OV or EV certificate also involves additional organizational validation.

Domain validation

For a typical DV certificate, the CA verifies control of the requested domain using an approved validation method. The certificate does not need to display your company's legal name to provide secure HTTPS.

Organization validation

OV and EV processes require additional checks of the organization. Depending on the product and policy, the CA may request legal names, registration details, contact information, or other evidence.

Why the distinction matters

• Domain identity answers which hostname the certificate is valid for.
• Organizational identity provides additional evidence about the entity requesting the certificate.
• A certificate containing a business name does not guarantee the business is honest or secure.
• Never place unnecessary sensitive personal or business information in public certificate fields.

Secure Sockets Layer (SSL) was the predecessor to Transport Layer Security (TLS). TLS was developed to provide secure communications and evolved through multiple protocol versions.

What changed with TLS 1.3?

• A streamlined handshake reduces connection setup latency in common scenarios.
• Legacy cryptographic options were removed.
• Modern key establishment and authenticated encryption are integral to the protocol.
• Static RSA key exchange and several older cipher-suite options are no longer supported.

Does my certificate determine the TLS version?

No. The certificate and the TLS protocol are separate components. The certificate provides identity information and a public key, while the server and client negotiate a mutually supported TLS version and cipher suite.

Your server software, cryptographic libraries, operating system, and configuration determine which protocol versions are enabled.

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -tls1_3

1. 01

   Websites and web applications

   HTTPS uses TLS to protect browser-to-server communication and authenticate the server.

   Typical components include a server certificate, its private key, and the necessary intermediate certificates.

2. 02

   APIs and microservices

   Service-to-service connections can use TLS to protect requests and responses.

   Mutual TLS adds client certificate authentication, allowing both endpoints to authenticate each other.

3. 03

   Email security

   S/MIME certificates can support digitally signed email and, when configured appropriately, email encryption.

   Email transport protocols such as SMTP, IMAP, and POP3 can also use TLS to protect connections.

4. 04

   Remote access and network devices

   VPN gateways, administrative interfaces, reverse proxies, load balancers, and other network services can use certificates for authentication.

   The specific certificate requirements depend on the product and protocol.

5. 05

   Code and document signing

   Digital certificates can associate public keys with identities used in software signing, document signing, and other signature-verification systems.

   The receiving application must support the relevant signature format and trust policy.

6. 06

   Device identity and enterprise PKI

   Organizations can issue certificates to laptops, servers, mobile devices, and network equipment.

   These certificates can support authentication, access control, and automated device management.

Let's Encrypt makes it possible to obtain publicly trusted certificates without purchasing them from a commercial certificate provider. Its ACME protocol allows compatible software to request, renew, and manage certificates automatically.

How does it work?

1. You configure an ACME client, such as Certbot, for your domain.
2. The client requests a certificate from the ACME service.
3. Let's Encrypt asks the client to demonstrate control of the requested domain.
4. The client completes a challenge, such as HTTP-01 or DNS-01.
5. Once validation succeeds, the certificate is issued.
6. Your web server installs the certificate and uses its corresponding private key for TLS.

HTTP-01 vs. DNS-01

Getting a certificate with Certbot

On a compatible Linux server running Nginx, a common workflow is:

sudo certbot --nginx -d example.com -d www.example.com

This example assumes Certbot is installed, Nginx is configured, and the requested domain names point to the server. Installation instructions vary by operating system and deployment method.

Certbot can obtain the certificate and configure Nginx when the necessary prerequisites are satisfied.

Do not forget renewal

Certificates expire. A production deployment should automatically renew certificates before expiration and reload the relevant service when appropriate.

Confirm that the renewal mechanism works instead of assuming that an installed ACME client will renew successfully forever.

The following examples use conventional command-line syntax. Options and defaults can differ between OpenSSL versions, operating systems, and service configurations.

openssl genpkey \
  -algorithm RSA \
  -pkeyopt rsa_keygen_bits:3072 \
  -out server.key

openssl req -new \
  -key server.key \
  -out server.csr \
  -sha256 \
  -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

openssl req \
  -in server.csr \
  -noout \
  -verify

openssl x509 \
  -in server.crt \
  -noout \
  -text

openssl x509 -in server.crt -pubkey -noout \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

openssl pkey -in server.key -pubout -outform DER \
  | openssl dgst -sha256

openssl verify \
  -CAfile trusted-roots.pem \
  -untrusted intermediate.pem \
  server.crt

openssl x509 \
  -in server.crt \
  -noout \
  -fingerprint \
  -sha256

openssl pkey \
  -in server.key \
  -noout \
  -text

openssl pkey \
  -in server.key \
  -pubout \
  -out server-public.pem

# Subject
openssl x509 -in server.crt -noout -subject

# Issuer
openssl x509 -in server.crt -noout -issuer

# Validity dates
openssl x509 -in server.crt -noout -dates

# Serial number
openssl x509 -in server.crt -noout -serial

# Subject Alternative Name
openssl x509 -in server.crt -noout -ext subjectAltName

# Public-key algorithm and parameters
openssl x509 -in server.crt -noout -pubkey \
  | openssl pkey -pubin -noout -text

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -verify_hostname example.com \
  -verify_return_error \
  -showcerts

openssl pkcs12 -export \
  -out server.p12 \
  -inkey server.key \
  -in server.crt \
  -certfile intermediate.pem

An encrypted private key requires a passphrase to decrypt and use the key. This helps protect the key at rest, provided the passphrase is sufficiently strong and appropriately managed.

A passphrase does not protect a key that has already been decrypted in memory or exposed through an insecure process.

Generate an encrypted RSA private key

openssl genpkey \
  -algorithm RSA \
  -aes-256-cbc \
  -pkeyopt rsa_keygen_bits:3072 \
  -out server-encrypted.key

OpenSSL prompts for a passphrase to encrypt the key. Use a strong, unique passphrase and store it securely.

When is encryption useful?

• Private keys stored in backups or offline archives.
• Keys transferred between administrators or systems through approved secure procedures.
• Keys stored on systems where interactive passphrase entry is practical.

What about automated web servers?

An encrypted server key may require an operator or a configured secret-management mechanism to unlock it when the service starts.

If the server must restart unattended, teams commonly use a dedicated secret manager, hardware security module, key-management service, or tightly controlled service-specific key storage.

Some deployments use an unencrypted private key so that the service can start automatically. If you choose that model, compensate with strict file permissions, restricted host access, secure backups, and appropriate monitoring.

First, confirm that you are authorized to modify the key and that the destination is protected. Removing the passphrase reduces protection if the resulting file is stolen.

Export an unencrypted private key

openssl pkey \
  -in server-encrypted.key \
  -out server-unencrypted.key

OpenSSL prompts for the original passphrase and writes the decrypted private key to the output file.

Protect the output file

chmod 600 server-unencrypted.key

On Unix-like systems, this restricts access to the file's owner. File permissions are only one layer of protection; also consider ownership, backups, system access, and the storage environment.

Re-encrypt a private key

openssl pkey \
  -in server-unencrypted.key \
  -aes-256-cbc \
  -out server-reencrypted.key

This command prompts for a new passphrase and writes an encrypted private key.

The X.509 Key Usage extension defines permitted uses for a certificate's public key. Extended Key Usage identifies broader application purposes, such as server authentication or email protection.

Digital Signature

The digitalSignature usage indicates that the key may be used for digital signatures, subject to the certificate's other restrictions.

TLS 1.2 and TLS 1.3 commonly use certificate private keys to sign handshake data, depending on the selected authentication algorithm.

Digital signatures can also be used for signed email, signed software, and other applications.

Key Encipherment

The keyEncipherment usage historically supported RSA key transport in older TLS configurations. This mechanism is not used in TLS 1.3, and static RSA key exchange is no longer supported by modern TLS.

Key encipherment remains relevant to certain legacy systems and applications, but should not be added automatically to every new certificate.

Key Agreement

The keyAgreement usage is associated with key-agreement operations. Whether it is appropriate depends on the key type and application.

Extended Key Usage

• Server Authentication: Permits use for TLS server authentication when other certificate requirements are satisfied.
• Client Authentication: Permits use for TLS client authentication.
• Email Protection: Supports appropriate email security applications.
• Code Signing: Identifies certificates intended for code-signing applications.

Inspect key usage in a certificate

openssl x509 \
  -in server.crt \
  -noout \
  -ext keyUsage,extendedKeyUsage

The certificate's extensions should match the intended use. The exact requirements depend on the application and the applicable certificate policy.

Transport encryption

Mail servers and clients can use TLS to protect the connection between them. This helps prevent network observers from reading or modifying the traffic in transit.

Transport encryption does not automatically encrypt the message end to end. A message may be stored or forwarded through systems where different security controls apply.

S/MIME digital signatures

Secure/Multipurpose Internet Mail Extensions (S/MIME) can use certificates and public-key cryptography to sign email messages.

A sender creates a digital signature using the appropriate private key. A recipient verifies it using the corresponding public key and evaluates the associated certificate and trust information.

A valid signature can help establish message integrity and associate the signature with a certified identity. It does not prove that the sender's message is truthful or that the sender's private key has never been compromised.

S/MIME email encryption

Email encryption protects message contents from unauthorized readers. In a common public-key workflow, a sender encrypts the message for the recipient using a cryptographic process that only the recipient's corresponding private key can complete.

The sender generally needs an appropriate public encryption key for each recipient. A recipient's certificate must support the intended email-protection use, and both parties' email software must support the selected S/MIME features.

Can OpenSSL sign an email?

OpenSSL can perform cryptographic signing operations, but signing a standards-compliant S/MIME message requires the correct MIME structure, certificate, private key, and compatible message-processing workflow.

For everyday business email, it is usually easier to configure S/MIME in a supported email client than to construct signed messages manually.

openssl x509 -in server.crt -noout -ext subjectAltName

openssl x509 -in server.crt -noout -dates

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts

Build a repeatable verification checklist

• Is the certificate currently valid?
• Does the SAN extension contain the correct hostname?
• Does the certificate match the private key?
• Is the chain complete and trusted?
• Are the intended TLS versions enabled?
• Is the private key stored with appropriate permissions?
• Does automatic renewal work?
• Has the live endpoint been tested after deployment?

1. 01

   Protect private keys

   Restrict file permissions, minimize copies, protect backups, and keep private keys out of public repositories and logs.

2. 02

   Use current TLS configurations

   Disable obsolete SSL and deprecated TLS versions. Prefer TLS 1.3 where supported and configure TLS 1.2 securely when compatibility requires it.

3. 03

   Automate renewal

   Use a supported certificate-management workflow and monitor renewal failures. A certificate that expires can interrupt business operations.

4. 04

   Maintain a certificate inventory

   Record the domains, owners, expiry dates, issuing authorities, and deployment locations of your certificates.

5. 05

   Validate before deployment

   Check the hostname, chain, key match, validity dates, and intended certificate usages before putting a certificate into production.

6. 06

   Plan for key compromise

   Know how to revoke or replace a certificate, rotate a private key, update dependent services, and investigate unauthorized access.