SupportConsole
llms.txtSign in

Find out why a certificate failed and issue it again

llms.txt

When SrvYard cannot get a Let's Encrypt certificate, the SSL tab says Failed and the site may have nothing to serve over HTTPS. The cause is nearly always outside SrvYard: the domain does not point at the server yet, port 80 is closed, or Let's Encrypt has asked you to wait.

This article walks through the checks in the order that finds the cause fastest, shows what each failure message means, and ends with how to ask for the certificate again and how to keep the site reachable while you fix it. For how certificates are normally issued and renewed, read Get a free Let's Encrypt certificate first.

Before you begin

  • Which site and which name failed? The failure belongs to one site on one server. Open that site, then SSL.
  • Access to your DNS. You will need to read, and maybe change, the records of the domain at your registrar or DNS host.
  • The right permission. Requesting or retrying a certificate needs the sites:manage-ssl permission; if the buttons are missing, ask an owner. See Roles and permissions.
Note

A failed request never replaces a working certificate. If the site already had one in use, it keeps serving it until it expires. The problem is worst when the site is set to Force HTTPS and has no certificate at all: visitors then get an error instead of the page.

1. Read the failure

Open the site and choose SSL.

The SSL tab of a site whose certificate failed
A failed request leaves the site without a certificate; Retry now repeats it once the cause is fixed.
  1. No certificate in use. The site is set to redirect to HTTPS, but nothing is served over it. Until you fix the certificate, visitors can see an error. If the site is down, turn off Force HTTPS in the site's Settings to bring it back over HTTP while you work.
  2. Failed after 3 attempts. Under Other certificates, the status is Failed. A request is tried up to three times, 30 minutes apart, and the status shows when the next attempt will happen. Hover the status to read the error recorded for the last attempt. When the last attempt fails, the certificate stays Failed and the organisation's owners and admins are told.
  3. Retry now. Runs the request again with the same settings. Use it after the cause is fixed; it does not help to press it before.

Some failures are known to be permanent and stop at once, without waiting for three attempts: a name Let's Encrypt refuses by policy, a wildcard name requested with HTTP validation, or an invalid request. Others are known to be temporary and are retried. SrvYard adds a short reason in front of the error to tell you which kind it is:

Reason shown What it means Go to
DNS has not propagated yet The name did not resolve to your server when Let's Encrypt looked (messages such as NXDOMAIN, no valid A records, SERVFAIL). Step 2
Port 80 of the server is not reachable Timeouts, Connection refused or reset while Let's Encrypt fetched the challenge file. Step 3
Let's Encrypt rate limit reached Too many certificates or failed attempts for the domain. Step 4
Let's Encrypt had a temporary problem A 5xx from the authority. Wait and press Retry now.
Wildcard names cannot be validated this way: use DNS validation You asked for *.name with HTTP validation. Step 5
Let's Encrypt refuses to issue a certificate for this name A policy or CAA record forbids it, or the name is not valid. Step 4

2. Check that the domain points at the server

Before it asks Let's Encrypt, SrvYard looks up the DNS of every name and tells you which ones are wrong. The messages are specific:

  • has no DNS record. The name does not resolve at all.
  • points at 198.51.100.7 instead of 203.0.113.11. The A record leads to another address. The first is what DNS returned, the second is your server.
  • also has an IPv6 (AAAA) record, which Let's Encrypt tries first, but the server is reached over IPv4: remove the AAAA record. A leftover AAAA record sends Let's Encrypt somewhere else. This is the most common surprise.

The site's Domains tab shows what DNS looks like now and which records to create.

The Domains tab with the DNS column and the DNS records card
The Domains tab compares your DNS with the server and lists the records to create.
  1. DNS. One status per domain. Points here means the records match the server; otherwise the column says what is wrong.
  2. The status. Fix any domain that is not green before you request a certificate.
  3. DNS records. The records to create at your DNS host: the type, the name and the value (the server's address). Copy the value from here rather than typing it.

DNS changes take time to spread, from a minute to a few hours depending on the time-to-live of the old record. If you changed a record a moment ago, wait, then press Retry now. Check from your own computer with dig +short crm.acme-studio.example A and dig +short crm.acme-studio.example AAAA; the first should print your server's address and the second nothing, unless the server has that IPv6 address.

Tip

If the domain sits behind a proxy or CDN, the request Let's Encrypt makes goes through it. A rule there that redirects or blocks /.well-known/acme-challenge/ breaks HTTP validation. Point the record straight at the server while you issue the certificate, or use DNS validation (step 5).

3. Check that port 80 is open

Let's Encrypt proves you control the name by fetching a small file from your site over plain HTTP on port 80. Renewals do the same, so port 80 must stay open permanently, even when the site forces HTTPS.

Two firewalls are involved. The server's own firewall is in Firewall:

The Firewall page with the HTTP and HTTPS rules
Ports 80 and 443 must be allowed, here and at your provider.
  1. HTTP, port 80. Allowed and active.
  2. HTTPS, port 443. Allowed and active.

If those rules are there but the request still fails, the block is outside the server: the cloud provider's firewall or security group, a network ACL, or a rule on a load balancer in front of the machine. Open ports 80 and 443 there too. See Open and close ports with the firewall.

Also check that the site itself does not redirect all HTTP traffic to another host before the certificate exists. A redirect from http://crm.acme-studio.example to a different domain can send Let's Encrypt to a place without the challenge file.

4. Rate limits and refused names

Let's Encrypt limits how many certificates it issues for one registered domain per week, and how many failed validations it accepts per hour. When you reach a limit, the failure is classed as Let's Encrypt rate limit reached and retried later. Retrying quickly makes it worse, because each failed attempt counts. Wait, fix the real cause, and try once. Shared zones such as srvy.sh hit the limits sooner than your own domain; use your own domain if you meet the limit often.

If Let's Encrypt refuses the name, no retry will help. Check that:

  • the name is a real, public domain name, not an internal one;
  • a CAA record on the domain, if you have one, allows letsencrypt.org to issue;
  • you did not tick a name that is not on this site.

5. Use DNS validation when HTTP cannot work

Choose DNS validation for a wildcard, for a site that is not reachable from the internet yet, or when port 80 cannot be opened. SrvYard then adds a temporary TXT record in Cloudflare instead of fetching a file. It needs a connected Cloudflare account that holds the zone.

The DNS providers table of the integrations page
DNS validation needs a connected Cloudflare account that holds the zone.
  1. Connect Cloudflare. Adds an account with an API token. Do this under Integrations in the organisation settings.
  2. Connected. The status of each connection. If it is not connected, or the token lost its permission, DNS validation fails with a message about the zone or the token. The domain must be a zone in that account: SrvYard looks it up for every name and refuses when it is missing.

If you later remove the connection, certificates it issued stay valid, but they cannot renew. Request a new one after you reconnect.

6. Request the certificate again

When the cause is fixed, return to the SSL tab and either press Retry now on the failed certificate or request a fresh one with Get a free certificate.

The Get a free certificate panel
Request the certificate again with every name ticked once DNS and port 80 are right.
  1. HTTP validation. The default: Let's Encrypt fetches a file on port 80. The names must point at the server.
  2. DNS validation. For wildcards and unreachable sites; it shows a DNS integration field.
  3. Hostnames. Tick every name that should be covered, normally the domain and its www. form. A name that is not ticked is not on the certificate and will show a browser warning.
  4. Get certificate. Starts the request. The output appears line by line and normally finishes in under a minute. On success the certificate is activated and Nginx reloaded.

Troubleshooting

  • It worked for the domain but not for www. The www name has no record, or has an AAAA record elsewhere. The DNS check names the host.
  • The certificate was issued but the browser still warns. The certificate does not cover the name in the address bar, or a cached older one is served. Check Covers on the card and request a certificate with every name ticked.
  • The free srvy.sh name fails. SrvYard waits for it to resolve before requesting; the zone's shared rate limit can still apply. Try again later or use your own domain.
  • Retry now is missing or does nothing. A request may already be running, or your role lacks sites:manage-ssl. Wait for the running request to finish.
  • I fixed everything and the next attempt says the same thing. Resolver caches. Wait for the old record's time-to-live to expire, then retry.
  • A renewal failed on a site that used to work. Port 80 was probably closed or redirected since. Check step 3, then press Renew now on the certificate card.
Last updated 2026-10-249 min readNeed help? Contact support
PreviousFix a 502 Bad Gateway on your siteNextFix the wrong site, an empty page or a placeholder after a DNS change