TLS Certificate Lifecycle for Hosted Websites

A TLS certificate on a hosted website moves through a repeatable lifecycle: it is issued after you prove control of your domain, can be renewed before expiry when automation is configured, revoked when necessary, and used for certificate-based TLS authentication. This guide walks through each stage in plain language.

How issuance validation proves domain control#

Before a certificate authority (CA) issues a certificate, you must demonstrate control over the domain it covers. With Let's Encrypt, an ACME (Automated Certificate Management Environment) client completes a validation challenge first, as the challenge types documentation explains.

Three challenge types are documented:

• HTTP-01. The CA supplies a token, and a file holding that token plus an account thumbprint is placed under .well-known/acme-challenge/ on your server. Validation happens over port 80 only. It works with standard web servers and can validate IP addresses, but not wildcards.
• DNS-01. The client creates a TXT record under the _acme-challenge name in your DNS. This is required for wildcard certificates and works without a public web server, but it needs DNS API credentials or manual updates, plus cleanup of old TXT records.
• TLS-ALPN-01. Validation happens at the TLS layer on port 443 through a special protocol negotiation indicator. It suits reverse proxies but cannot validate wildcards.

For issuance, the Let's Encrypt integration guide requires outbound TCP port 443 for ACME API calls, inbound TCP port 80 for HTTP-01 validation, and inbound TCP and UDP port 53 on your authoritative DNS servers.

How automated renewal works#

Under the Let's Encrypt Subscriber Agreement, the subscriber is whoever holds the certificate's private key. In the hosting-provider scenario described by the guide, the provider holds the key and acts as the subscriber, allowing issuance without each site owner signing an individual agreement, as the integration guide explains.

The same integration guide recommends checking ACME Renewal Information (ARI) and following its recommended renewal window. Configure renewal automation according to that guide. Renewals are spread randomly across time to avoid concentrating load at the CA.

The integration guide says renewal failures should not be treated as fatal. The documented approach is exponential backoff, retrying after progressively longer waits up to once per day per certificate, while alerting administrators if errors persist. The guide also advises frontends and containerized instances to store certificates and keys in durable storage and reuse them across redeployments, so repeated deployments do not exhaust CA rate limits.

What revocation means#

Revocation marks a certificate as no longer safe to use. The Let's Encrypt revocation documentation lists situations that require it, such as a compromised or leaked private key or loss of domain control. Requests carry RFC 5280 reason codes, including keyCompromise (mandatory after unauthorized key access), superseded (a replacement certificate exists), and cessationOfOperation (the domain or site is discontinued).

The revocation documentation describes three ways to authorize revocation: with the issuing ACME account's credentials, with a different ACME account that proves current control of the certificate's identifiers through a standard challenge, or by signing the request with the certificate's private key.

What happens during the TLS handshake#

For a complete certificate-authenticated TLS 1.3 handshake, RFC 8446 describes how the exchange lets a client and server negotiate the protocol version, select cryptographic algorithms, authenticate the server, and derive shared keys before protected application data flows. The following example has three phases; PSK and resumption modes need not send certificate messages:

1. Key exchange. The client sends a ClientHello with cipher suites and a key share; the server replies with a ServerHello and its own key share, or a HelloRetryRequest if parameters need adjusting.
2. Server parameters. The server sends EncryptedExtensions and may request client authentication with a CertificateRequest.
3. Authentication. The server sends its X.509v3 certificate chain, a CertificateVerify signature covering the handshake transcript, and a Finished message; both sides then exchange encrypted application data.

RFC 8446 requires server certificates to be X.509v3 unless explicitly negotiated otherwise. The key must allow signing, with digitalSignature set if the Key Usage extension is present. It also notes that certificate choice is guided by the client's server_name and certificate_authorities extensions.

Questions worth asking your host#

Hosting setups differ, so confirm these points with your provider:

• Does the control panel support DNS-01 validation for wildcard certificates, or HTTP-01 only?
• Is inbound port 80 left open for HTTP-01 challenges?
• Does your DNS provider offer an authenticated API for TXT record creation and cleanup?
• Does the platform follow ARI renewal guidance and monitor its configured renewal automation?
• Are certificates and private keys stored durably across redeployments?
• Does the host offer a revocation workflow, or would you need ACME credentials or the private key to revoke?