The Complete Guide to SSL/TLS Certificates

Every time you visit a website that starts with https://, an SSL/TLS certificate is doing its job behind the scenes. It encrypts data in transit, authenticates the server you are talking to, and gives your browser the confidence to show that little padlock icon.

But certificates expire. They get misconfigured. They break silently at 2 a.m. on a Saturday.

This guide covers everything you need to know about SSL and TLS certificates, from the basics of how encryption works to advanced topics like certificate transparency and mutual TLS. Whether you are a developer setting up your first certificate or an ops engineer managing hundreds of them, this is your reference.

What is SSL/TLS (and why the name confusion)

SSL stands for Secure Sockets Layer. TLS stands for Transport Layer Security. They are both cryptographic protocols designed to secure communication over a network, and TLS is the direct successor to SSL.

Netscape created SSL in the mid-1990s. SSL 2.0 shipped in 1995, SSL 3.0 in 1996. The Internet Engineering Task Force (IETF) then took over and released TLS 1.0 in 1999 as an upgrade to SSL 3.0 [1]. Every version since has been TLS: 1.1 in 2006, 1.2 in 2008, and 1.3 in 2018 [2].

SSL 2.0 and 3.0 are both deprecated and considered insecure. No modern browser supports them. Yet the industry still says "SSL certificate" even though the actual protocol in use is TLS 1.2 or TLS 1.3. The name stuck for historical reasons, much like people still say "dial" a phone number.

Throughout this guide, "SSL/TLS" and "SSL certificate" refer to certificates used with the modern TLS protocol. For a deeper look at the differences, see our SSL vs TLS comparison.

How HTTPS works: the TLS handshake

When your browser connects to https://example.com, a TLS handshake happens before any application data is exchanged. This handshake establishes the encrypted channel. Here is how it works in TLS 1.3 (the current standard) [2].

Step 1: Client Hello

The browser sends a Client Hello message containing the TLS version it supports, a list of supported cipher suites, and a random value called the "client random." In TLS 1.3, the client also sends key share data upfront (using Diffie-Hellman parameters), which is what makes the handshake faster than older versions. The Client Hello also includes the Server Name Indication (SNI) extension, which tells the server which hostname the client wants to connect to. SNI is what allows a single server to host certificates for multiple domains on one IP address.

Step 2: Server Hello

The server picks a cipher suite from the client's list, sends its own random value and key share, and presents its SSL certificate.

Step 3: Certificate verification

The browser checks the certificate. It verifies the domain name matches, the certificate has not expired, the signature is valid, and the issuing certificate authority (CA) is trusted. This involves walking the certificate chain, which we cover in a later section.

Step 4: Key derivation and Finished

Both sides use a key derivation function (HKDF) to produce session keys from the shared key material. These session keys are symmetric, meaning both sides use the same keys for encryption and decryption. This is important because symmetric encryption is much faster than asymmetric encryption. The TLS handshake uses asymmetric cryptography (public/private key pairs) only to establish the shared secret, then switches to symmetric encryption for the actual data transfer.

The server sends a Finished message. The client verifies it and sends its own Finished message. The handshake is complete.

In TLS 1.3, this entire process takes a single round trip (1-RTT), down from two round trips in TLS 1.2. There is even a 0-RTT mode for resumed connections, though it comes with replay risk tradeoffs [2].

Client                              Server
  |                                    |
  |--- Client Hello + Key Share ------>|
  |                                    |
  |<-- Server Hello + Key Share -------|
  |<-- Certificate --------------------|
  |<-- Finished ----------------------|
  |                                    |
  |--- Finished ---------------------->|
  |                                    |
  |<========= Encrypted Data ========>|

After the handshake, every byte of data between the browser and server is encrypted. Someone intercepting the traffic sees only ciphertext.

Certificate types

Not all SSL certificates are the same. They vary by validation level and by the number of domains they cover. Understanding the differences helps you pick the right one.

Validation levels

Domain Validation (DV) certificates are the simplest. The CA only checks that you control the domain, usually by verifying a DNS record, an HTTP file, or responding to an email. DV certificates are issued in minutes and are free from Let's Encrypt. They are perfectly fine for most websites.

Organization Validation (OV) certificates require the CA to verify that your organization legally exists. The CA checks business registration documents and may call the company. OV certificates display the organization name in the certificate details, though browsers do not visually distinguish them from DV certificates in the address bar.

Extended Validation (EV) certificates require the most thorough vetting. The CA verifies legal existence, operational existence, physical address, and the authority of the person requesting the certificate. EV certificates used to show a green bar with the company name in browsers, but Chrome removed that indicator in 2019 and other browsers followed [3]. The practical security benefit over DV is debatable, and the extra cost is hard to justify for most websites. That said, some regulated industries still require EV certificates for compliance reasons.

For a more detailed comparison, check out our types of SSL certificates article.

Domain coverage

Single-domain certificates cover exactly one fully qualified domain name (FQDN), like www.example.com.

Wildcard certificates cover a domain and all its single-level subdomains. A certificate for *.example.com covers www.example.com, api.example.com, and blog.example.com, but not example.com itself (unless the base domain is listed as a Subject Alternative Name) and not nested subdomains like sub.api.example.com. Wildcard certificates are convenient for organizations with many subdomains, but they carry a higher security risk: if the private key is compromised, every subdomain is affected. Learn more in our wildcard SSL certificates guide.

SAN/multi-domain certificates (also called Unified Communications Certificates) use Subject Alternative Names to cover multiple different domains on a single certificate. One certificate could cover example.com, example.org, and anotherdomain.com. This is common in enterprise environments and for services like Microsoft Exchange.

The certificate chain of trust

Your browser does not just trust any certificate a server presents. It needs to verify that the certificate was issued by a trusted authority. This is where the chain of trust comes in.

How the chain works

A typical chain has three levels:

1. Root CA certificate. This is a self-signed certificate that lives in your operating system or browser's trust store. Root CAs are the ultimate trust anchors. There are only a few hundred of them globally.

2. Intermediate CA certificate. Root CAs rarely sign end-entity certificates directly. Instead, they sign intermediate CA certificates, which then sign the actual certificates. This protects the root key: if an intermediate is compromised, the root can revoke it without affecting every other certificate in existence.

3. Leaf (end-entity) certificate. This is the certificate installed on your web server. It contains your domain name, public key, validity period, and the signature of the intermediate CA that issued it.

When your browser receives the leaf certificate, it follows the chain upward. It checks that the leaf was signed by the intermediate, the intermediate was signed by the root, and the root exists in the local trust store. If any link in the chain is broken, missing, or expired, the connection fails.

[Root CA]           (self-signed, in trust store)
    |
    +-- signs -->  [Intermediate CA]
                        |
                        +-- signs -->  [Leaf Certificate]
                                        (your server)

A common misconfiguration is forgetting to include the intermediate certificate when installing your SSL certificate. The leaf certificate alone is not enough. Your server must send the full chain (leaf plus intermediates) so the browser can verify the path to a trusted root.

For a full breakdown, read our SSL certificate chain explained guide.

Certificate authorities

Certificate authorities are the organizations that issue SSL/TLS certificates. They are trusted third parties whose root certificates are embedded in browsers and operating systems.

What CAs do

A certificate authority's core job is identity verification. When you request a certificate, the CA confirms that you control the domain (for DV) or verifies your organization's identity (for OV/EV). Once satisfied, the CA signs your certificate with its private key. That signature is what makes the browser trust you.

CAs also maintain Certificate Revocation Lists (CRLs) and OCSP responders so that compromised certificates can be invalidated before they expire [4].

Major certificate authorities

The CA market has consolidated significantly. As of 2025, the landscape looks like this:

• Let's Encrypt is the largest CA by certificate volume, issuing free DV certificates with automated renewal. It is a nonprofit run by the Internet Security Research Group (ISRG) [5].
• DigiCert is the leading commercial CA, especially for enterprise and EV certificates. It acquired Symantec's CA business in 2017.
• Sectigo (formerly Comodo CA) is another major commercial CA with a broad product line.
• Google Trust Services operates its own root CA and issues certificates for Google properties and, increasingly, for Google Cloud customers.
• Amazon Trust Services provides free certificates for AWS services through AWS Certificate Manager (ACM).

For a detailed comparison, see our SSL certificate providers compared resource.

CAA records

You can control which CAs are allowed to issue certificates for your domain using DNS CAA (Certificate Authority Authorization) records. For example, a CAA record like example.com. IN CAA 0 issue "letsencrypt.org" tells CAs that only Let's Encrypt should issue certificates for that domain. Most CAs check CAA records before issuance, and it is a good security practice to set them. Learn more about DNS record types, including CAA, over at DNS Record Types Explained.

Getting a certificate

Free certificates with Let's Encrypt

Let's Encrypt changed the SSL landscape by making certificates free and automatable. Here is how to get one using Certbot, the recommended client [5]:

# Install Certbot (Ubuntu/Debian)
sudo apt update
sudo apt install certbot python3-certbot-nginx

# Obtain and install a certificate for Nginx
sudo certbot --nginx -d example.com -d www.example.com

# Or for Apache
sudo certbot --apache -d example.com -d www.example.com

Certbot handles the domain validation challenge, obtains the certificate, installs it, and sets up automatic renewal via a systemd timer or cron job.

Let's Encrypt certificates are valid for 90 days, which is intentionally short to encourage automation and limit the damage window if a key is compromised. Certbot will attempt renewal when a certificate is within 30 days of expiry.

One thing to be aware of: Let's Encrypt has rate limits. You can issue up to 50 certificates per registered domain per week, and there is a limit of 5 duplicate certificates per week. These limits rarely matter for typical websites, but they can be an issue if you are managing many subdomains or testing in production. Use the staging environment for testing to avoid hitting limits.

For production considerations, see our Let's Encrypt production guide. For a broader look at no-cost options, check the free SSL certificates guide.

Paid certificates

If you need OV or EV validation, or if your organization requires specific CA features like warranty, dedicated support, or compliance documentation, you will need a paid certificate. Prices range from around $10/year for basic DV certificates to several hundred dollars per year for multi-domain EV certificates.

The process involves generating a Certificate Signing Request (CSR), submitting it to the CA, completing the validation process (which can take minutes for DV or weeks for EV), and installing the issued certificate.

Generating a CSR

A CSR is a block of encoded text that contains your public key and identifying information. You generate it with your private key, which stays on your server:

# Generate a private key and CSR
openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -subj "/C=US/ST=California/L=San Francisco/O=Example Inc/CN=example.com"

# Verify the CSR contents
openssl req -in example.com.csr -noout -text

The CA uses the CSR to create your certificate. You submit the .csr file through the CA's portal or API, never the .key file. Your private key should never leave your server.

Installing certificates

Once you have your certificate files (typically a leaf certificate and an intermediate chain), you need to install them on your web server.

Nginx

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/certs/example.com.fullchain.pem;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;

    # HSTS (optional but recommended)
    add_header Strict-Transport-Security "max-age=63072000" always;
}

The ssl_certificate file should contain the leaf certificate followed by the intermediate(s). This is often called the "fullchain" file. The ssl_certificate_key points to your private key.

Apache

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com

    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile   /etc/ssl/private/example.com.key
    SSLCertificateChainFile /etc/ssl/certs/example.com.chain.pem

    SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
</VirtualHost>

Apache uses a separate SSLCertificateChainFile directive for the intermediate certificates, unlike Nginx which bundles everything into one file.

Verifying your installation

After installing, always verify:

# Check the certificate served by your domain
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -text

# Check the full chain
openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null

For more ways to verify, see our guides on checking SSL certificates, checking with OpenSSL, and checking SSL in a browser.

After your certificate is installed and HTTPS is working, make sure your HTTP-to-HTTPS redirects are set up correctly. The HTTP to HTTPS Redirect Guide on Redirect Trace covers the common patterns.

Certificate lifecycle

An SSL certificate is not a one-time setup. It has a defined lifecycle that you need to manage.

Issuance

The lifecycle starts when a CA issues the certificate. The CA signs your public key and domain information with its private key, creating the certificate. The maximum validity period for publicly trusted certificates is currently 398 days (about 13 months), as set by the CA/Browser Forum [6]. This limit was reduced from three years in 2015 to two years in 2018, then to 398 days in 2020. Apple drove the most recent change by announcing that Safari would reject certificates with longer lifetimes. The trend is toward even shorter validity periods. Let's Encrypt issues certificates valid for just 90 days.

Renewal

Certificates must be renewed before they expire. For Let's Encrypt, Certbot handles this automatically:

# Test renewal without actually renewing
sudo certbot renew --dry-run

# Force renewal
sudo certbot renew

For commercial certificates, renewal typically involves generating a new CSR (or reusing one), revalidating with the CA, and installing the new certificate. Some CAs offer auto-renewal APIs, and cloud providers like AWS and Google Cloud handle renewal automatically for certificates managed through their platforms (AWS Certificate Manager, Google-managed SSL certificates). However, the new certificate still needs to be deployed to every server, load balancer, and CDN endpoint that uses it. This is where things often go wrong.

Our SSL renewal checklist walks through the full process step by step.

Revocation

If your private key is compromised, or if a certificate was issued incorrectly, it needs to be revoked. Revocation tells browsers not to trust the certificate even though it has not expired yet.

There are two main revocation mechanisms:

• CRL (Certificate Revocation List). The CA publishes a list of revoked certificate serial numbers. Browsers can download this list to check. In practice, CRLs are large and slow, and most browsers do not check them in real time.

• OCSP (Online Certificate Status Protocol). The browser queries the CA's OCSP responder to check a specific certificate's status. OCSP is faster than CRLs but introduces a privacy concern: the CA knows which sites you visit. OCSP stapling solves this by having the server fetch and cache the OCSP response, then staple it to the TLS handshake [4].

# Check OCSP status of a certificate
openssl ocsp -issuer chain.pem -cert cert.pem \
  -url http://ocsp.example-ca.com -resp_text

Expiry

When a certificate expires, browsers display a full-page security warning. Users cannot reach your site without manually bypassing the warning (which most will not do). Expired certificates have caused major outages at companies like Equifax, Microsoft Teams, and Spotify [7].

Our article on what happens when SSL expires covers the full impact.

SSL/TLS monitoring

You might think that auto-renewal solves the expiry problem. It does not. Not entirely.

Why auto-renew is not enough

Auto-renewal can fail silently. DNS changes might break domain validation. Firewall rules can block the CA's validation requests. A server migration might leave behind stale certificates. Someone might provision a new load balancer with a certificate that is not covered by your renewal automation.

These failures do not always trigger alerts. The first sign of a problem is often a user reporting that your site is broken. Our article on why auto-renew is not enough digs into the real-world scenarios.

What to monitor

A proper SSL monitoring setup checks:

• Expiry dates. Get alerted 30, 14, and 7 days before expiry. For critical services, add a 1-day alert as a final safety net.
• Chain validity. Verify the full chain from leaf to root. A valid leaf certificate with a missing intermediate is just as broken as an expired one.
• Protocol and cipher strength. Detect weak configurations like TLS 1.0 or RC4 ciphers that may still be enabled.
• Certificate changes. Know when a certificate is replaced, whether intentionally or not. Unexpected changes could indicate a compromise or a misconfigured deployment.
• OCSP stapling. Confirm your server is serving stapled responses.
• SANs and domain coverage. Verify that the certificate covers all the domains it needs to, especially after renewals where SANs might be dropped accidentally.

For a comprehensive overview of monitoring approaches, see SSL monitoring explained. And if you are evaluating tools, our SSL checker tools compared roundup can help.

Common SSL errors and how to fix them

SSL errors can be cryptic. Here are the ones you will encounter most often.

ERR_CERT_DATE_INVALID / SEC_ERROR_EXPIRED_CERTIFICATE

The certificate has expired. Renew it immediately. Check if your auto-renewal process is working. Also check the server clock: if the system time is wrong, a valid certificate can appear expired. This is a surprisingly common issue on virtual machines and embedded devices where NTP (Network Time Protocol) is not configured correctly.

ERR_CERT_AUTHORITY_INVALID

The browser does not trust the CA that signed your certificate. This usually means you are using a self-signed certificate or the intermediate certificate is missing from the chain.

ERR_CERT_COMMON_NAME_INVALID / SSL_ERROR_BAD_CERT_DOMAIN

The domain name in the URL does not match any name in the certificate. Verify that the certificate covers the exact domain (including or excluding www) and check the Subject Alternative Names. A common mistake is getting a certificate for example.com but not including www.example.com as a SAN, or vice versa. Another cause is accessing the server by IP address when the certificate only lists domain names.

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

The server and browser cannot agree on a protocol version or cipher suite. This usually means the server is configured with only outdated ciphers or has TLS 1.0/1.1 only. Update your server configuration to support TLS 1.2 and 1.3.

ERR_SSL_PROTOCOL_ERROR

A generic error that can have many causes: misconfigured server, corrupted certificate file, port conflict, or firewall interference. Check your server logs and validate the certificate files with OpenSSL.

ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

Chrome requires certificates to be logged in Certificate Transparency logs. If the certificate was not submitted to CT logs during issuance, Chrome will reject it. This error is rare with major CAs (they all submit to CT logs now), but can appear with private CAs or very old certificates. The fix is to reissue the certificate through a CA that supports CT.

Mixed content warnings

Your page loads over HTTPS but includes resources (images, scripts, stylesheets) loaded over HTTP. Browsers block active mixed content (scripts) and warn about passive mixed content (images). Fix by updating all resource URLs to use HTTPS or protocol-relative paths. Check third-party embeds too: analytics scripts, fonts, widgets, and CDN-hosted libraries are common culprits.

# Quick check for mixed content on a page
curl -s https://example.com | grep -i "http://"

For a full troubleshooting walkthrough, see how to fix SSL errors.

You can also decode a certificate or validate a certificate to help diagnose chain and formatting issues.

Advanced topics

Certificate Transparency

Certificate Transparency (CT) is a system that logs all publicly issued certificates in append-only, publicly auditable logs [8]. It was created by Google to detect certificates that were issued mistakenly or maliciously.

When a CA issues a certificate, it submits the certificate (or a pre-certificate) to one or more CT logs. The log returns a Signed Certificate Timestamp (SCT), which is proof that the certificate has been logged. Browsers like Chrome require SCTs for certificates to be trusted.

CT logs are searchable. Tools like crt.sh let you look up every certificate ever issued for a domain. This is useful for detecting unauthorized certificates, finding forgotten subdomains, and auditing your certificate inventory. Security teams regularly monitor CT logs for their domains to get early warning of phishing certificates (certificates issued for lookalike domains) or unauthorized issuance.

You can query CT logs yourself:

# Search crt.sh for certificates issued for a domain
curl -s "https://crt.sh/?q=example.com&output=json" | jq '.[0:5] | .[] | {id, name_value, not_after}'

HSTS (HTTP Strict Transport Security)

HSTS tells browsers to always use HTTPS for your domain, even if the user types http:// or follows an HTTP link. You enable it with a response header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

The max-age value is in seconds (31536000 = one year). includeSubDomains applies the policy to all subdomains. preload lets you submit your domain to the HSTS preload list, which is hardcoded into browsers [9].

HSTS is a strong security measure, but deploy it carefully. If your certificate expires or you need to fall back to HTTP for any reason, users will be locked out until the max-age expires. Start with a short max-age and increase it once you are confident in your HTTPS setup.

SSL/TLS inspection

SSL/TLS inspection (also called SSL interception or HTTPS inspection) is when a middlebox, typically a corporate firewall or proxy, terminates the TLS connection, inspects the decrypted traffic, and re-encrypts it with a different certificate before forwarding it to the client. The client trusts this because the organization installs the proxy's CA certificate in the device trust store.

This is common in enterprise environments for security monitoring and data loss prevention. Our article on what is SSL inspection covers the details.

Certificate pinning

Certificate pinning restricts which certificates or public keys a client will accept for a given domain. Instead of trusting any certificate signed by any CA in the trust store, the client only trusts certificates that match a pinned value.

HTTP Public Key Pinning (HPKP) was a browser-based pinning mechanism, but it was deprecated because misconfiguration could permanently lock users out of a site. Today, pinning is mostly used in mobile apps and IoT devices where the developer controls the client. It provides strong protection against CA compromise but creates operational risk if not managed carefully.

Mutual TLS (mTLS)

Standard TLS authenticates the server to the client. Mutual TLS adds the reverse: the client also presents a certificate to the server, proving its identity. Both sides verify each other.

mTLS is common in:

• Microservices communication. Service-to-service calls within a cluster use mTLS to ensure only authorized services can connect.
• API authentication. Instead of API keys, clients authenticate with certificates.
• Zero trust architectures. mTLS is a building block for zero-trust networking, where every connection is authenticated regardless of network location.

Service meshes like Istio and Linkerd automate mTLS between services, handling certificate issuance, rotation, and verification transparently. If you are building microservices, mTLS through a service mesh is one of the most impactful security improvements you can make. It eliminates the possibility of network-level eavesdropping between services and ensures that only authenticated services can communicate with each other.

SSL certificate management at scale

When you manage tens or hundreds of certificates across different servers, cloud providers, CDNs, and load balancers, things get complicated quickly. A certificate management strategy becomes essential.

Key practices include:

• Maintaining an inventory of every certificate, where it is installed, and when it expires.
• Centralizing certificate issuance through a small number of CAs.
• Automating renewal everywhere possible (ACME protocol, cloud provider integrations).
• Monitoring independently of automation.
• Documenting the renewal process for certificates that cannot be automated.

Our SSL certificate management strategy guide covers this in depth.

When managing certificates alongside your broader infrastructure, do not forget that domains expire too. Coordinate your certificate and domain renewals together. The Domain Renewal Checklist on Domain Expiry Watcher is a useful companion resource.

SSL/TLS glossary quick reference

Here are the key terms you will see throughout SSL/TLS documentation:

• CA (Certificate Authority): An organization that issues digital certificates.
• CSR (Certificate Signing Request): A block of encoded data sent to a CA to request a certificate.
• DV / OV / EV: Domain Validation, Organization Validation, Extended Validation. Levels of identity checking.
• FQDN: Fully Qualified Domain Name, like www.example.com.
• OCSP: Online Certificate Status Protocol. A method for checking if a certificate has been revoked.
• SAN: Subject Alternative Name. A certificate extension that allows multiple domain names on one certificate.
• SNI: Server Name Indication. A TLS extension that lets a server host multiple certificates on one IP address.
• PEM: A base64-encoded certificate format, the most common on Linux/Unix systems.
• PKCS#12 / PFX: A binary format that bundles the certificate and private key into one file, common on Windows.

For the complete list, see our SSL certificate glossary.

Take control of your certificates

SSL/TLS certificates are foundational to web security. They encrypt data, authenticate servers, and build trust with users. But they are only effective when properly configured, monitored, and renewed on time.

The biggest risk is not a sophisticated attack. It is a certificate that quietly expires because nobody was watching. Major organizations have learned this the hard way, and the outages from famous SSL expiry disasters could all have been prevented with basic monitoring.

Whether you manage one certificate or a thousand, the fundamentals are the same: know what you have, know when it expires, and verify that everything works.

References

1. T. Dierks, E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2," RFC 5246, IETF, August 2008. https://datatracker.ietf.org/doc/html/rfc5246
2. E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3," RFC 8446, IETF, August 2018. https://datatracker.ietf.org/doc/html/rfc8446
3. T. Langley, "Chrome's Plan to Distrust Symantec Certificates," Google Security Blog, 2017. https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html
4. S. Santesson et al., "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP," RFC 6960, IETF, June 2013. https://datatracker.ietf.org/doc/html/rfc6960
5. Let's Encrypt Documentation, Internet Security Research Group. https://letsencrypt.org/docs/
6. CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates." https://cabforum.org/baseline-requirements/
7. "SSL Certificate Expiry: The Hidden Operational Risk," SSL Certificate Expiry Blog. /resources/famous-ssl-expiry-disasters
8. B. Laurie, A. Langley, E. Kasper, "Certificate Transparency," RFC 6962, IETF, June 2013. https://datatracker.ietf.org/doc/html/rfc6962
9. "HTTP Strict Transport Security," Mozilla Web Security Guidelines. https://wiki.mozilla.org/Security/Guidelines/Web_Security#HTTP_Strict_Transport_Security