In 2014, fewer than 30% of web pages loaded over HTTPS. By the end of 2024, that figure had climbed above 80%, and 92.1% of top-level Firefox connections were already secure in January 2025, according to Mozilla's HTTPS adoption analysis. Installing an SSL certificate has moved from an optional security upgrade to basic production maintenance. If your certificate is missing, expired, served from the wrong layer, or missing its intermediate chain, browsers and APIs can reject traffic before your application gets a chance to respond.

A reliable implementation follows the certificate through its entire life. You choose the right certificate, generate a CSR and private key, install the leaf and intermediate certificates in the correct order, configure the server or edge layer, verify what external clients receive, enable HSTS only when HTTPS is stable, and automate renewal with clear ownership. The difficult incidents rarely happen during the happy-path install. They happen when a CDN has one certificate, a load balancer has another, the origin has a third, and nobody knows which team owns the next renewal.

Why Installing SSL Certificates Is Now Table Stakes

HTTPS is now the expected transport for ordinary websites, APIs, login flows, payment pages, and service-to-service requests. Mozilla's analysis shows the web moving from mostly unencrypted traffic in 2014 to more than 80% of pages loaded over HTTPS by the end of 2024. That change matters operationally. Certificate installation is no longer something you add after the application works. It's part of making the application reachable and trusted in the first place.

Google's HTTPS transparency data records the same broad shift across platforms. On 14 March 2015, only 41% of Windows connections were encrypted, while by 28 June 2026 the reported figures had reached 95% on Windows, 99% on Android, 99% on ChromeOS, 86% on Linux, and 97% on Mac, as summarized with the underlying platform data in this HTTPS adoption report. The Internet Society's Pulse project separately reports that 95% of the top 1,000 websites globally support HTTPS. Users, browsers, SDKs, and upstream services increasingly assume that secure transport is already configured.

An infographic showing that over 95% of web traffic is now encrypted with HTTPS, replacing insecure HTTP connections.

The certificate is only one part of the deployment

A certificate proves that a trusted authority issued credentials for the names it contains. It doesn't automatically configure your server, attach the private key, install intermediates, update every edge endpoint, or redirect old HTTP URLs. Those tasks belong to your deployment process.

A production workflow should answer these questions before cutover:

  • Which names are covered? Every production hostname must appear in the certificate's Subject Alternative Name list.
  • Where does TLS terminate? The private key may belong on a CDN, reverse proxy, load balancer, ingress controller, or origin server.
  • Which chain will clients receive? The leaf certificate must be followed by the correct intermediate certificates.
  • Who replaces it? An alert without a named owner is not a renewal strategy.
  • How will you test it externally? A local trust store can hide a chain problem that a browser sees immediately.

For a WordPress deployment, the SSL certificate troubleshooting guide for WordPress is useful when redirect loops, proxy settings, or CMS-generated resource URLs complicate an otherwise correct server installation. The same principle applies to larger stacks: solve the TLS topology, not just the file copy.

Choosing Between Let's Encrypt and Commercial Certificates

The right certificate depends less on the word “SSL” and more on your validation, governance, and deployment requirements. Let's Encrypt is usually the practical choice for public web applications and APIs that can support automated domain validation. A commercial certificate can make sense when an organization needs a specific validation process, procurement relationship, support channel, warranty terms, or a certificate product designed for internal policy requirements.

Attribute Let's Encrypt Commercial Certificate
Cost Free issuance Paid product or subscription
Validation level Domain validation Domain validation, organization validation, or extended validation depending on product
Lifespan Short-lived, automation-oriented certificates Product-dependent lifespan and renewal terms
Automation support Strong support through ACME clients Varies by CA and product, often supports automation
Best fit Web apps, APIs, containers, ephemeral infrastructure, and teams with mature automation Organizations with formal validation, support, warranty, procurement, or governance requirements

When Let's Encrypt is the better operational choice

Let's Encrypt works well when your system can prove control of the hostname automatically and deploy the renewed certificate without a human copying files. ACME clients can request, validate, install, and reload certificates as part of a repeatable process. That reduces the risk created by manual renewal calendars and makes short certificate lifecycles manageable.

It's a particularly good fit for:

  • Public applications: Sites and APIs with predictable validation paths.
  • Dynamic infrastructure: Containers, autoscaled instances, and environments where manual installation would drift.
  • Large hostname inventories: Systems that can renew many names through one controlled workflow.
  • Developer-owned services: Teams that need a straightforward, standards-based path without procurement overhead.

The trade-off is that automation must be real. If port 80 or port 443 is blocked during issuance, if a CDN intercepts validation unexpectedly, or if the renewed file never reaches the TLS termination layer, a free certificate still produces an outage.

When a commercial certificate earns its place

Commercial certificates are more defensible when the organization has requirements beyond basic domain control. Organization validation and extended validation can fit a formal identity and governance process, although the certificate still needs correct installation and monitoring. A commercial CA may also provide support or contractual terms your security and procurement teams require.

Don't choose a commercial certificate because you expect the padlock alone to improve a weak deployment. Browsers still care about hostname coverage, validity, chain construction, key matching, and protocol configuration. The operational quality of the installation matters more than the purchase route.

Acquire and test the certificate before production cutover. SSL Labs deployment guidance recommends obtaining certificates at least one week before cutover to reduce problems associated with incorrect client clocks and OCSP propagation delays, with a one to three month warm-up window preferred when possible, as documented in its SSL and TLS deployment guidance. Early possession gives you time to validate every layer without turning the renewal date into a change freeze.

Generating a CSR and Protecting Your Private Key

The CSR is not the certificate. It's a request containing the public key and identifying information that a Certificate Authority uses when issuing the certificate. The private key is generated alongside it and must remain secret. Anyone who obtains the private key can potentially impersonate the covered service, so key handling deserves the same care as production credentials.

Start on the machine that will terminate TLS, or on a trusted system that can securely transfer the resulting certificate and key. Generate the key with sufficient entropy, restrict access immediately, and avoid creating it on an unmanaged laptop or shared shell account.

A four-step infographic explaining the process of generating an SSL certificate signing request and obtaining a certificate.

Generate the key and CSR

For a typical Linux host, create an OpenSSL configuration file that explicitly lists the SANs:

cat > csr.conf <<'EOF'
[req]
prompt = no
distinguished_name = subject
req_extensions = req_ext

[subject]
C = US
ST = State
L = City
O = Example Organization
CN = www.example.com

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = www.example.com
DNS.2 = example.com
DNS.3 = api.example.com
EOF

Generate a fresh private key and CSR:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout example.com.key \
  -out example.com.csr \
  -config csr.conf

The CN identifies the primary name, but clients rely on the Subject Alternative Name extension for hostname matching. Put every production name there. If the application serves api.example.com and www.example.com, listing only the apex domain won't fix the mismatch.

Practical rule: Treat the SAN list as an inventory of production entry points, not as a cosmetic field in a form.

Understand what you created

The .key file contains the private key. The .csr contains the public key and requested identity fields, but not the private key itself. Send the CSR to the CA through its approved enrollment flow. Never send the private key to the CA, a ticket, a chat room, or a third-party installer.

Check the CSR before submission:

openssl req -in example.com.csr -noout -text

Confirm the requested SANs, subject, public-key details, and signature information. After issuance, verify that the returned certificate contains the names you expected:

openssl x509 -in example.com.crt -noout -text

Protect the key from creation onward:

  • Restrict permissions: Keep the file readable only by the account or service that needs it.
  • Limit copies: Store it on as few trusted machines as the topology permits.
  • Use a new key for renewal: Key reuse makes rotation less meaningful and expands the impact of a compromise.
  • Back up deliberately: Encrypt approved backups and document who can restore them.
  • Identify the TLS terminator: If a load balancer handles HTTPS, the origin may not need the private key at all.

A permission error during deployment can be confusing when the key is correct but the service account can't read it. Keep the key private while fixing ownership and permissions. For adjacent SSH and deployment permission failures, this publickey permission troubleshooting guide offers useful context, but don't treat an SSH workaround as permission to loosen private-key access.

Installing Certificates on Nginx, Apache, Node and Caddy

Installation changes with the server, but the core rule doesn't: serve the leaf certificate first, then the intermediate certificates, and point the service at the matching private key. A certificate file without its chain may work for one client and fail for another. A chain in the wrong order can produce browser trust errors even though the leaf certificate itself is valid.

Nginx

Create a full-chain file with the leaf first:

cat example.com.crt intermediate.crt > example.com.fullchain.crt

Then configure the HTTPS server:

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

    ssl_certificate     /etc/nginx/tls/example.com.fullchain.crt;
    ssl_certificate_key /etc/nginx/tls/example.com.key;

    root /var/www/example;
}

Nginx expects ssl_certificate to contain the server certificate followed by the intermediates. It doesn't need the root certificate in the served chain. Test before reloading:

sudo nginx -t
sudo systemctl reload nginx

A reload is safer than an unnecessary restart because it lets existing workers finish while the new configuration takes effect.

A computer monitor displaying Nginx server configuration code for SSL certificate installation in a modern home office.

Apache

Apache deployments commonly separate the leaf certificate, key, and chain:

SSLEngine on
SSLCertificateFile /etc/apache2/tls/example.com.crt
SSLCertificateKeyFile /etc/apache2/tls/example.com.key
SSLCertificateChainFile /etc/apache2/tls/intermediate.crt

On versions and configurations that support a full-chain certificate directly, using the appropriate full-chain file can simplify deployment. The important detail is ordering. Put the leaf before its intermediate certificates, and don't assume Apache will repair a malformed bundle for older clients.

Validate the configuration, then reload:

sudo apachectl configtest
sudo systemctl reload apache2

Node.js

Node won't fetch missing intermediates for the client. Supply the private key and the chain explicitly:

const fs = require('node:fs');
const https = require('node:https');

const options = {
  key: fs.readFileSync('/etc/tls/example.com.key'),
  cert: fs.readFileSync('/etc/tls/example.com.crt'),
  ca: fs.readFileSync('/etc/tls/intermediate.crt')
};

https.createServer(options, app).listen(443);

For multiple intermediates, provide them in the correct order in the ca value or use a chain file as appropriate for your Node version and deployment pattern. Keep the key outside the application repository and make the service account's file access explicit. If you're deploying a Node application rather than managing a web server directly, this Node.js hosting guide provides related operational context.

Caddy and cloud termination

Caddy is designed to manage certificates automatically for common public HTTPS deployments. That's a strong default when DNS, reachability, storage, and reload behavior fit its model. Manual certificates still make sense for private PKI, unusual validation flows, imported certificates, or environments where a separate platform owns issuance.

Cloud load balancers and CDNs change the installation point. Upload or attach the certificate where the client-facing TLS session terminates, then install a separate certificate at the origin only if the edge-to-origin connection is also encrypted. Keep firewall ports 80 and 443 open when issuance and validation flows require them. Testing the origin alone proves nothing about the certificate a browser receives from the CDN.

Verifying the Full Chain and Enabling HSTS

A successful service reload is not proof of a successful installation. The decisive test is external: connect to the public hostname through the same CDN, load balancer, proxy, or ingress path used by real clients and inspect the certificate chain returned there.

A checklist infographic illustrating four essential steps for verifying SSL certificate installation and HSTS security configurations.

Inspect what the public endpoint serves

Use OpenSSL against the public hostname:

openssl s_client -connect example.com:443 \
  -servername example.com \
  -showcerts </dev/null

The -servername option matters because modern servers commonly select certificates through SNI. Read the output for the leaf certificate, issuer, SANs, dates, and verification result. For a chain review, save the presented certificates and inspect their subjects and issuers in sequence.

An external scanner such as SSL Labs' SSL Server Test can expose chain problems, protocol issues, hostname mismatches, and differences between public endpoints. Don't rely only on the origin host's local trust store. The origin may trust its own files while the CDN serves an old certificate, a different chain, or a certificate for another hostname.

Diagnose the common failures

Incomplete chain: The server sends the leaf but omits an intermediate. Some clients can build the path from cached or locally available intermediates, while others cannot. Install the intermediate after the leaf, then retest from outside the network.

Self-signed or mismatched certificate: The endpoint may be serving a development certificate, the wrong virtual host, or an untrusted issuer. Confirm the issuer and SANs in the externally returned certificate. A local browser exception isn't a fix.

Private-key mismatch: Compare the public key derived from the certificate and private key:

openssl x509 -noout -modulus -in example.com.crt | openssl sha256
openssl rsa  -noout -modulus -in example.com.key | openssl sha256

The resulting digests should match for an RSA key pair. If they don't, stop the deployment and locate the correct key.

Configuration drift: Query the CDN hostname, load balancer listener, origin hostname, and any alternate production names separately. Each layer can have its own certificate binding and reload behavior. A correct origin configuration can't repair an outdated edge binding.

Add HSTS only after HTTPS is dependable

HSTS tells browsers to use HTTPS for future requests to the host. Begin with a controlled policy:

Strict-Transport-Security: max-age=86400

Use a longer policy only after every page, asset, API route, redirect, and subdomain that the policy covers works over HTTPS. includeSubDomains expands the blast radius, and preload submission is a long-term commitment. Don't enable preload while certificate coverage, redirects, or subdomain ownership is still changing.

Mixed content is a separate application problem. Search templates, scripts, stylesheets, images, API URLs, and third-party integrations for HTTP references, then test the rendered page in a browser. HSTS can expose these weaknesses quickly because the browser refuses insecure access instead of accepting a downgrade.

Automating Renewals and Avoiding Ownership Drift

Manual renewal fails because people treat a certificate as a file instead of a production dependency. Automate issuance, deployment, service reloads, and post-renewal checks with an ACME client, a platform-managed certificate service, or your cloud provider's certificate workflow. A timer that only downloads a new file isn't enough if the CDN, load balancer, or application process continues serving the old one.

NIST recommends installing and testing certificates at least 30 days before expiration. For certificates with validity shorter than 60 days, it recommends renewing before 80% of the lifetime has elapsed, based on the Oracle certificate-chain guidance summarizing the workflow. Treat those windows as minimum operational guardrails, not permission to wait until the final day.

Assign ownership before the next renewal

Shared infrastructure creates a predictable failure pattern. Platform engineers install the certificate, application teams own the hostname, infrastructure teams manage the load balancer, and nobody owns the alert. A 2025 Sectigo report found that 96% of organizations are concerned about the business impact of shorter SSL/TLS certificate lifespans, as cited in this discussion of recurring SSL problems in mature environments.

Record four roles for every certificate:

  • Installer: Applies the certificate and reloads the terminating service.
  • Monitor owner: Receives expiry, validation, and deployment alerts.
  • Replacement owner: Approves and executes rotation across every layer.
  • Escalation route: Sends failures to a monitored team channel or incident system.

Keep a central inventory of names, certificate identifiers, termination points, renewal method, and owners. Test the renewal path in a non-production environment, then verify the public endpoint after deployment. This is the same discipline described in broader deployment automation practices, applied specifically to TLS lifecycle work.

Before calling the job complete, confirm:

  • Key security: New private key, restricted access, controlled backup.
  • Name coverage: SANs match every production hostname.
  • Chain order: Leaf first, intermediates afterward.
  • Topology: CDN, load balancer, proxy, and origin bindings are understood.
  • External verification: Public endpoints return the intended certificate.
  • HSTS safety: Policy is enabled only after HTTPS and mixed content are stable.
  • Renewal ownership: Automation, alerts, and escalation routes are tested.

Edge-first platforms such as Appjet handle certificate management for custom domains as part of the deployment path, reducing the number of TLS layers a development team has to operate manually. If you want to ship full-stack applications without turning every custom domain into a separate certificate project, visit Appjet.ai and evaluate its managed edge deployment workflow.