Let's Encrypt Staging Test
Runs a real ACME order against Let's Encrypt's staging environment. The certificate you get back is signed by an untrusted root — it proves the CSR and your domain control work, without spending a production issuance.
What this tool does
Takes a Certificate Signing Request and runs a genuine ACME order against the Let's Encrypt staging environment — the same protocol, the same validation, the same refusals as production, but signed by an untrusted root and with far looser rate limits.
That distinction is the whole point. Production Let's Encrypt allows a limited number of failed validations and duplicate certificates per week. Discovering that your CSR has a malformed SAN, or that your DNS provider silently strips TXT records, is much cheaper here than after you have burned a week's allowance.
How to use it
Paste the CSR and pick how you want to prove you control the domain. The tool checks the request against the CA's own rules first — that part never leaves this server — and only opens an order if it would survive. You then publish what it asks for, press the button, and Let's Encrypt goes and looks.
- DNS-01 — add a TXT record at
_acme-challenge.yourdomain. Works for any domain, needs no web server, and is the only option for a wildcard. Allow a minute or two for the record to propagate before validating. - HTTP-01 — serve one file over plain HTTP on port 80. Faster to confirm, but the domain must already resolve to a server you control, and it cannot validate a wildcard.
Reading the result
A returned certificate means three things held at once: the CSR is well-formed and issuable, the CA agreed you control every name in it, and the resulting chain builds. It is not usable in production — browsers reject the staging root on purpose. Treat it as a receipt, not a certificate.
Common problems
- Validation failed, DNS record not found. Nearly always propagation. Confirm it independently with
dig TXT _acme-challenge.yourdomainbefore retrying — some providers take several minutes, and a low TTL on the zone does not help if the record is new. - Validation failed over HTTP. Let's Encrypt fetches over plain HTTP on port 80 and follows redirects to HTTPS, but it must reach you from the public internet. A firewall, a Cloudflare proxy rule, or a server that only listens on 443 will all fail here.
- CAA forbids issuance. If your CAA records name a different CA, Let's Encrypt is required to refuse — staging included. Check what yours say.
- The order expired. Orders are held for an hour and then dropped. Start again; nothing is lost but the click.
What is sent where
The CSR is posted to this server, which forwards it to Let's Encrypt's staging API to create the order. A CSR contains a public key and the names you are asking to certify — never a private key — so there is nothing secret in it. Nothing is stored beyond the hour an order lives in memory.
Read more, from Let's Encrypt
The authoritative answers live in their own documentation — worth reading before you take anything here as the last word.
- The staging environment — what the staging root is, and why nothing it signs will ever be trusted.
- Challenge types — how HTTP-01, DNS-01 and TLS-ALPN-01 differ, and when each is the right one.
- Rate limits — the production limits this tool exists to keep you from spending.
- Frequently asked questions, and the community forum where their staff answer directly.
- RFC 8555 — the ACME protocol itself, if you want to know exactly what this page is doing on your behalf.