Certificate expiry can interrupt checkout, while an incompatible replacement chain can leave some clients unable to connect. SSL certificates form part of HTTPS authentication; reliable operation also depends on TLS software, the actual termination point and a working renewal/deployment process. This guide explains how to maintain those components and distinguish certificate errors from configuration or client compatibility problems.
The maintenance scope includes names, validity, private keys, issuing chains, trust stores, protocol choices, revocation and automation. A newly issued file is not proof that the intended server serves it. Check issuance and deployment separately, test representative clients and retain evidence of the outcome. The sections below cover prerequisites and acceptance criteria rather than a server-specific installation recipe; apply them through the documented workflow of the chosen software and provider.
What TLS and Certificates Protect
A correctly authenticated TLS connection protects data in transit against disclosure and modification by network attackers. The certificate helps the client authenticate the expected service name through an acceptable trust path. A domain-validated certificate does not prove that a website’s content, business claims or application code is trustworthy. Client checks include names, validity and trust policy, so a browser icon alone is not a complete maintenance or security assessment.
“SSL” remains a common certificate label, but current HTTPS uses TLS. Use supported TLS 1.2 and TLS 1.3 configurations and retire older protocols. Certificate renewal, key replacement and TLS library updates are separate operations: obtaining a new certificate does not patch a vulnerable library or correct an unsafe protocol policy. Keep the service’s software version, configuration baseline and certificate inventory together so a change can be evaluated in context.
The server presents a leaf certificate and the needed intermediate chain; the client must build an acceptable path to a trust anchor it recognizes. Its local trust store and policy can differ from another device’s. Protocol, cipher and signature support must also overlap. Identify the exact hostname, SNI, TLS endpoint and client before changing settings. A successful connection from one workstation cannot establish that every CDN edge, origin or internal service presents the intended certificate.
Certificate Errors and TLS Software Vulnerabilities
Separate four common problem classes: certificate lifecycle errors such as expiry or missing names; incomplete or incompatible trust chains; protocol/cipher configuration; and implementation flaws in the TLS library or server. CA incidents and trust-store changes can affect otherwise unchanged services. Missing OCSP stapling is relevant only where the CA and connection policy require or support it; it is not a universal indicator of a broken TLS setup. Classify the error before selecting a remedy.
Consider a hypothetical chain rotation: Chrome and Firefox on current systems connect successfully, but older Android devices reject the new root. Where the CA offers a compatible cross-signed chain, serving it may restore access. Modern-client success alone does not establish compatibility with older trust stores.
For inherited systems, identify supported software versions and compare the active configuration with current vendor guidance. Historical attack names are not a substitute for checking the precise affected version and configuration. Remove obsolete protocol exceptions through a tested migration, with an owner and retirement date for any necessary temporary allowance. Do not disable certificate verification or re-enable unsafe cryptography merely to make a compatibility error disappear.
Updating Libraries, Servers and TLS Endpoints
Track security updates for the actual TLS implementation used by each service. A host update does not update libraries and CA trust stores bundled inside application containers or other isolated runtimes. Rebuild and redeploy affected images, then verify the running version and endpoint behavior. Follow the package’s restart or reload requirements so updated files are actually used. Certificate renewal and trust-chain replacement should be recorded separately from these software changes.
Map where visitor TLS terminates. A CDN or reverse proxy that terminates TLS controls the public certificate and protocol policy; updating an origin file does not automatically update that edge. An encrypted edge-to-origin connection has its own certificate verification settings. With TLS passthrough, the backend remains the endpoint presenting the certificate. HTTP/2 ALPN and HTTP/3 QUIC requirements also belong to the component actually handling those protocols, not necessarily the application server.
For load-balanced services, test each relevant frontend and backend path rather than only the default address. Record which component selects the certificate, where SNI is routed and what a health check verifies. A successful HTTP status does not by itself prove hostname or trust-chain verification occurred. TLS-aware health checks can supplement application checks, but their scope and trust settings must match the connection being protected. Passthrough is an architecture choice, not an automatic security or availability improvement.
Protocol, Cipher and Key Compatibility
Use a supported TLS 1.2/1.3 baseline. For TLS 1.2, suitable ECDHE suites can provide forward secrecy; TLS 1.3 separates cipher suites from key agreement and has different guarantees for PSK-only or early-data use. RSA and ECDSA certificates may be served together where the server supports them and the client population benefits. Selection depends on client capabilities, chains and server policy: modern clients do not universally select ECDSA, and an RSA certificate cannot repair every legacy protocol or trust-store limitation.
Select key algorithms and sizes supported by the CA, server, client population and security policy. Let’s Encrypt accepts RSA keys of 2048, 3072 or 4096 bits and ECDSA P-256/P-384; other CAs can have different policies. Distinguish certificate keys from ACME account keys. Keep private keys in access-controlled storage and protected backups, not source repositories. If a key is exposed, create a replacement with a new key and coordinate revocation; encrypting the exposed file afterward does not undo the compromise.
The Mozilla TLS configuration generator can provide a starting point for a chosen server version and compatibility target. Check its prerequisites and test before deployment. An external SSL Labs assessment helps inspect the public endpoint, but a grade does not establish application health or compatibility with every client. Compare scanner results with actual affected devices and record the hostname, network path and configuration tested.
Revocation, OCSP and HSTS
Revocation handling varies across CAs, servers and clients. Where OCSP remains available and stapling is supported, a server can provide a signed status response during the handshake, avoiding a separate client request. It is not a universal enforcement mechanism. Let’s Encrypt retired OCSP in August 2025; current Let’s Encrypt certificates should not be expected to produce a staple. Use the CA’s current status/revocation guidance instead of treating absent stapling as an error for every certificate.
Must-Staple uses the TLS Feature extension to require supported status behavior in clients that enforce it. Missing or expired required responses can break those connections. Deploy it only with a CA and server path that still support the feature; it is not an option to assume for current Let’s Encrypt certificates. With CDN, WAF and origin layers, assess each separate TLS connection: the browser checks its endpoint, while each terminating proxy handles its upstream verification according to its own configuration.
HSTS addresses HTTP downgrade separately from certificate revocation. After a supporting browser learns the policy over HTTPS, it upgrades covered HTTP requests while the policy remains active. Verify HTTPS and redirects first, start with a short max-age such as 300 and observe staged increases. Audit public and internal subdomains before includeSubDomains. Preloading is a separate long-term decision, not a default maintenance step; it can cover first visits in participating browsers, but removal takes time to propagate.
ACME Renewal and Deployment Prerequisites
ACME renewal requires a validation path that continues working after initial issuance. HTTP-01 needs externally reachable port 80 and correct responses across all possible frontends. DNS-01 requires limited credentials and client support to publish the necessary TXT values, wait for propagation and clean up only completed challenges; Let’s Encrypt wildcards require it. Re-test after DNS permission, firewall, CDN or WAF changes. Keep staging accounts and untrusted test output separate from production certificates and deployment destinations.
Follow ARI renewal information where the installed client supports it; otherwise schedule against the actual certificate lifetime with room for failed attempts. Do not assume every certificate lasts 90 days or that a fixed 30-day alert is suitable. Keep account, certificate and operation state durably so a restart does not request unnecessary replacements. Honor Retry-After and applicable rate-limit scope. After issuance, verify key match, SANs, validity and CA-provided chain, then test configuration, load the result and verify new connections at the intended endpoint.
A renewal hook must have an explicit success condition, sufficient but limited permissions, and observable failure handling. Updating a local certificate file does not automatically update a CDN, managed load balancer or every proxy. Use each destination’s supported deployment mechanism and confirm what it presents. A failed reload should remain a deployment failure even if the ACME order succeeded. Keep test results and sanitized error details; never include private keys or API credentials in logs.
Diagnosing Client-Specific Failures
Reproduce the affected client’s operating system, TLS library, trust store and application behavior as closely as practical. Record the exact error and check the presented chain, expected hostname, certificate validity and client clock. Then examine protocol, cipher, signature, ALPN and SNI compatibility as relevant. An enterprise TLS inspection proxy may present a different certificate from the public server, so inspect what that client actually receives. Updating the origin certificate cannot resolve every local trust or policy issue.
Trace the user connection through the actual termination point. A public-edge success and an origin failure can be different incidents; an internal health probe may bypass both SNI routing and the user’s trust policy. Test the intended edge-to-origin validation separately where TLS is used. For passthrough, confirm the backend certificate and routing seen by the visitor. Preserve the host and network path in test evidence so later operators can reproduce the result rather than repeating a check against a different endpoint.
Mixed content is a separate application-delivery issue: an HTTPS page can still reference HTTP scripts, styles or images. Browser behavior depends on the resource and policy; a valid certificate alone does not correct those references. Inspect browser diagnostics and crawl the deployed pages, then fix insecure URLs or resource delivery at the source. Repeat the check after relevant application changes because later deployments can reintroduce HTTP references. Do not classify every mixed-content warning as a failed certificate renewal.
SMTP, APIs and Internal Certificates
SMTP has its own transport policy and reporting mechanisms. MTA-STS publishes a policy used by supporting sending MTAs; TLS-RPT reports delivery/TLS policy outcomes and does not itself enforce encryption. Authenticated SMTP DANE requires DNSSEC-validated TLSA records and participating MTA support, not just permission to add DNS records. Treat DNSSEC validation and TLSA/key rollover as prerequisites before deployment. These mechanisms concern mail transport and do not replace HTTPS certificate verification for a website.
Include API, internal PKI and mTLS certificates in the inventory. A public HTTPS certificate can remain healthy while an internal client or service certificate expires and breaks an application path. Record each certificate’s issuer, owner, trust policy, renewal mechanism and consuming process. Probe the intended authenticated connection and application result, not merely a TCP port or generic 200 response. Internal certificates may not appear in public Certificate Transparency logs, so external CT monitoring cannot replace this inventory.
Certificate Transparency and CAA
Certificate Transparency logs support detection of unexpected public certificate issuance; crt.sh is one way to search logged records. Compare discoveries with authorized issuers and certificate owners, then investigate unexplained results. Logs do not prevent misissuance by themselves, prove that the certificate is currently deployed, or cover every private PKI certificate. Keep endpoint monitoring and internal inventories alongside CT observation rather than treating a search result as a complete certificate health check.
CAA DNS records express issuance authorization that compliant CAs check before issuing a certificate. They do not revoke already issued certificates and are not a replacement for a client’s certificate validation. A certificate can have been issued under a different earlier CAA policy, so investigate its issuance time before treating a mismatch with today’s records as proof of misconduct. CAA does not guarantee notification of every rejected request; maintain CT observation and CA/account records separately.
Ownership and Change Management
Assign owners for certificate policy, renewal credentials, deployment and incident response. Keep a short runbook with protected storage locations, expected endpoints, validation steps and alarm contacts. Scheduled configuration reviews do not replace continuous expiry monitoring or timely response to vendor security advisories. Record necessary compatibility exceptions with a review date. During staff handover, verify that another operator can use the runbook to identify a failed stage without access to unrelated tenants’ private keys.
After an incident, distinguish restored service from a confirmed root-cause fix. Record whether the failure came from validation access, quota exhaustion, missing deployment, trust changes or client incompatibility. Define one acceptance check for each corrective action and assign an owner. If the cause remains unknown, retain that uncertainty rather than declaring it resolved. Use the resulting evidence to improve the next maintenance operation instead of adding another generic reminder to “check the logs.”
Deployment Acceptance Criteria
Acceptance should cover both the issued artifact and the running service. Verify the certificate/key pair, required names, lifetime and chain; confirm the server configuration test and deployment mechanism; probe fresh connections with the intended SNI and trust policy; then check application health for representative clients. Test both RSA and ECDSA paths if both are configured. Existing connections may continue using previous session state, so a page that stayed open during reload is insufficient evidence of the new certificate.
Before a rollout, retain a recovery configuration that is still valid and uncompromised, and define when to stop expanding the change. Measure handshake errors alongside latency so an average performance improvement does not hide failures in a client group. A compromised private key is an exception to ordinary rollback: generate a fresh key, prepare the necessary replacement coverage and coordinate prompt revocation of affected certificates. Renewal does not automatically revoke the old certificate, and an exposed key must not be restored.
Certificate Maintenance Checklist
Start with the inventory: required names, owners, TLS terminators, clients and certificate lifetimes. Confirm a supported protocol baseline and the current issuer chain. Rehearse the renewal and deployment path with isolated staging output, then apply to a limited production group. Check validation, issuance, storage, loading and fresh endpoint connections as distinct results. Expand only when the agreed client and application checks pass.
Keep ongoing maintenance aligned with ARI or actual validity, preserve retry margin and handle changes to DNS permissions, proxies and client trust stores. HSTS, optional stapling for supporting CAs, dual certificates and mail transport policies are separate decisions with their own prerequisites. Add them where they solve a defined need, and record the checks that show they work. A certificate file’s modification time or an external scanner grade alone does not establish completion.
The required outcome is that every intended host presents a valid certificate to the clients it must support, renewals remain operable and failures reach a responsible owner with enough evidence to act. Close a maintenance record with those results and any unresolved limits, not simply with “certificate updated.”
Related Implementation Guides
Use these focused guides for implementation details after the maintenance scope and prerequisites are clear:
RSA and ECDSA certificates on Nginx and Apache: prepare separate certificate paths and verify client selection.
Let’s Encrypt rate limits, SANs, wildcards and renewal: plan issuance quotas, ARI and DNS challenge timing.
HAProxy load balancing and TLS passthrough: identify routing and termination responsibilities.
SMTP security with MTA-STS, TLS-RPT and DANE/TLSA: review mail-specific policy, reporting and DNSSEC prerequisites.
