- Let's Encrypt certificates are free, valid for 90 days, and renew automatically in the background on our web hosting
- If renewal fails, it's almost always Port 80, a wrong DNS record, or a reverse proxy intercepting the request
- For wildcard certificates (*.your-domain.com) you need the DNS-01 challenge instead of HTTP-01
A red padlock icon in the browser has scared off more visitors than any slow page load. It says "Not secure", and anyone who lands on an order page clicks away before typing in their credit card number. Let's Encrypt solved this problem for most of the web by making the certificate free – but "free" doesn't mean "takes care of everything by itself", and that's exactly where the support requests we regularly get come from.
How Let's Encrypt actually works
Let's Encrypt is a certificate authority that uses the ACME protocol to automatically verify that you really do control a domain, and then issues you a Domain Validated (DV) certificate. No commercial register extract, no phone call, no multi-day wait like with classic paid certificates. The check runs via what's called a challenge, and it's precisely the choice of challenge that later decides whether a renewal succeeds or aborts with a cryptic error message.
| Challenge | How it verifies | When it makes sense |
|---|---|---|
| HTTP-01 | Places a file under your domain, Let's Encrypt fetches it over Port 80 | Standard web hosting with a reachable Port 80, one certificate per domain/subdomain |
| DNS-01 | You create a TXT record in your domain's DNS, which Let's Encrypt queries | Wildcard certificates, servers without an open Port 80, internal systems |
| TLS-ALPN-01 | Verification directly over Port 443 via a TLS extension | Rare, mostly when Port 80 must stay permanently blocked |
How the certificate works on our web hosting
If your domain is connected to your web hosting via the customer area, Plesk handles issuance and renewal itself – you don't need to order a certificate manually. This requires that the domain actually points to our servers; otherwise the HTTP-01 check fails, because Let's Encrypt fetches the response not from us but from your old provider. You'll find how to set the DNS records for this correctly in the post Connecting a domain to web hosting.
- Link the domain in the customer area to your web hosting plan and set the DNS record (A record or nameservers)
- In the Plesk panel, under "Websites & Domains" → "SSL/TLS Certificates", open "Let's Encrypt"
- Select the domain variants (with and without www) and have the certificate issued
- Under "Hosting Settings", enable the redirect from HTTP to HTTPS so old traffic doesn't end up on the unencrypted page
On your own root server with web hosting, the same principle applies, except that you're responsible for the ACME client yourself. The most common client is Certbot:
apt install certbot python3-certbot-nginx
certbot --nginx -d deine-domain.de -d www.deine-domain.deCertbot automatically sets up a cronjob or systemd timer that checks twice a day whether a renewal is due. Renewal doesn't happen right before expiry, but considerably earlier – leaving time to notice a problem before the site actually ends up with an expired certificate.
certbot renew --dry-runWhen renewal fails
Almost every failed renewal traces back to one of a handful of causes:
- Port 80 blocked – a firewall rule or a restrictive security plugin doesn't let Let's Encrypt's validation request through at all
- DNS no longer points to the right server – for example after a provider switch where the old A record was forgotten
- Reverse proxy or CDN intercepts the request – the file under
/.well-known/acme-challenge/never reaches the actual server - Wrong permissions in the webroot – the ACME client can't write the validation file, or the web server can't read it
- Too many failed attempts in a short time – Let's Encrypt limits how often you can request new certificates for the same domain within a given period, which is exactly why it's worth using staging mode when testing
certbot --staging) – it doesn't count against the limit for real certificates.A typical error message is "Invalid response from ... : 404" – this almost always means the challenge file isn't arriving where Let's Encrypt expects it. First check whether the domain is actually hosted with us, then whether a proxy or a redirect rule is involved that treats paths under /.well-known/ differently from the rest of the site.
Wildcard certificates
For a certificate that covers all subdomains at once (*.deine-domain.de), HTTP-01 isn't enough – Let's Encrypt strictly requires DNS-01 here, because a wildcard can't be validated via a single reachable URL. So you need access to your domain's DNS management and must be able to set a TXT record there, either manually for every renewal or automated via a DNS plugin for your ACME client.
- Free, no recurring certificate cost
- Fully automatable, no manual renewal needed
- Broad support in Plesk, Nginx, Apache, all common browsers
- Domain validation only, no organization vetting like with EV certificates
- Short 90-day lifetime makes you dependent on working automation
- Wildcards require DNS-01, and thus API access to DNS management
A certificate nobody renews is just an expiration date with extra steps.
Checking whether it worked
After issuance or renewal, a quick check is enough:
echo | openssl s_client -connect deine-domain.de:443 -servername deine-domain.de 2>/dev/null | openssl x509 -noout -datesThe output shows notBefore and notAfter – if notAfter is roughly 90 days in the future, everything's current. It's also worth a look in the browser itself: click the padlock icon, view the certificate details, the issuer should be "Let's Encrypt" or "R-something" (the current intermediate CA). For GDPR-related background on web hosting in Germany, it's also worth reading our post Web hosting in Germany – secure, flexible, and GDPR-compliant, especially if encryption is part of your compliance requirements.
_6a4f6e96d67aa.png)
