TLS Certificates for Cloud Servers with Let’s Encrypt

What the Padlock Actually Claims

A publicly trusted certificate makes one narrow statement: the party presenting it demonstrated control of this domain name to a certificate authority, and the connection to it is encrypted and tamper evident.

It says nothing about whether the site is honest, well written or safe. That distinction matters because people still describe certificates as proof of trustworthiness, and they are not. They are proof of name control plus a working encrypted channel.

The useful consequence is that issuing one can be fully automated. If the only claim is domain control, a machine can prove it, which is exactly what the ACME protocol standardised and what made certificates free and routine rather than an annual purchasing exercise.

ACME in One Paragraph

ACME, specified as RFC 8555, describes a conversation between your server and a certificate authority. The client registers an account key, asks for a certificate covering certain names, receives a challenge for each name, satisfies the challenges, and collects the signed certificate.

Let's Encrypt is the best known authority speaking it, and others including ZeroSSL and Google Trust Services implement the same protocol, so clients are interchangeable. Certificates from Let's Encrypt have a ninety day lifetime by design, on the reasoning that a short validity period limits the damage from a compromised key and forces automation to be real rather than aspirational.

That short lifetime is the single most important thing to understand. Manual issuance is not a viable strategy, because you will be doing it four times a year on every host until you forget once.

Three Ways to Prove Control

HTTP-01 is the default and needs the least setup. It does require port 80 to remain open to the authority even if you redirect everything to the encrypted port, which surprises people who close it for tidiness.

DNS-01 is the only option for a wildcard certificate, and it is the right choice for internal servers with no public address. It needs an API credential for your DNS provider so the client can create and remove the record automatically, and that credential should be scoped to the one zone. The record handling itself is ordinary DNS work, covered in DNS setup for cloud servers.

Getting the First One on a Server

Clients differ mainly in how much they touch your configuration. Certbot is the reference implementation and can edit a web server configuration for you. acme.sh is a shell script with broad DNS provider support and no dependencies worth worrying about. lego is a single Go binary. Caddy and Traefik skip the separate client entirely by requesting certificates themselves.

With a web server already serving the domain over plain HTTP, a webroot issuance avoids stopping anything.

certbot certonly --webroot -w /var/www/html -d example.com -d www.example.com

The result is a certificate, a private key and a chain file, conventionally under /etc/letsencrypt/live/. Point the web server at the full chain rather than the leaf alone, because clients that lack the intermediate will otherwise report an untrusted connection while your own browser looks fine.

Include every name the site answers to. A certificate for the bare domain does not cover the www prefix, and the mismatch produces a browser warning that looks far more alarming than the mistake deserves. The server side wiring is covered in Nginx as a reverse proxy on a cloud server.

Renewal Is the Entire Job

Issuance is a one off. Renewal is forever, and an expired certificate on a production domain is an outage that every visitor sees.

Packaged clients install a scheduled job automatically, usually a systemd timer that runs twice a day and does nothing unless a certificate is near its expiry. Confirm it exists rather than assuming, then test the path end to end.

certbot renew --dry-run

The step people miss is the reload. A renewed certificate on disk changes nothing until the server reloads and reads it, so configure a deploy hook that reloads the service after a successful renewal. Renewals that succeed while the process keeps serving the old file are a genuinely confusing failure mode.

Monitor expiry independently of the renewal mechanism. An external check that connects and reads the remaining validity will catch a broken timer, a revoked account or a DNS credential that expired, none of which the renewal job will tell you about if it never runs.

On the Instance, or in Front of It

Terminating on the instance means the certificate lives where the application does. It is simple, portable between providers, and it is the only option when there is a single server.

Terminating at a managed load balancer or CDN moves the problem to the platform. AWS Certificate Manager issues and renews public certificates for use with its load balancers and content delivery, Google Cloud offers managed certificates for its load balancers, Azure provides managed certificates for App Service, and several developer clouds will provision a certificate for a load balancer on request.

The managed route removes renewal from your list entirely, which is a genuine operational win. The trade offs are that the certificate usually cannot be exported, and that the connection from the balancer to your instance is a separate decision. Leaving that hop unencrypted is acceptable inside a private network you control and unacceptable across the public internet, a distinction explored in encryption at rest and in transit.

Platforms with an integrated certificate workflow save real time here. The DigitalOcean account listings describe an account where load balancer certificates are part of the platform, and the Google Cloud versus DigitalOcean comparison looks at how differently the two expose managed certificates.

The Settings That Matter More Than the Certificate

A valid certificate with a careless server configuration is still a weak deployment. Four settings do most of the work.

Offer modern protocol versions only. Current guidance is to serve TLS 1.2 and 1.3 and to leave the older versions disabled, since they remain enabled by default in some older packages.

Redirect plain HTTP to the encrypted site, then add a strict transport security header so returning browsers will not attempt the insecure version at all. Introduce the header with a short lifetime first, because a long one is difficult to undo if something is misconfigured.

Prefer an elliptic curve key for new certificates. Handshakes are cheaper and the keys are smaller, and compatibility concerns are largely historical now.

Finally, keep the private key readable only by the account that needs it, and never copy it into a repository or an image. The rest of the first day hardening is collected in securing a new cloud server, and Let's Encrypt maintains its own practical notes in the Let's Encrypt documentation.

Common Questions