Get free 90-day wildcard SSL certificates from Let's Encrypt automatically. Our 4-step ACME wizard handles account registration, domain verification via DNS, and certificate issuance — no manual configuration needed. Supports wildcard certs (*.example.com) for all your subdomains.
How to Use
1Enter your email and choose Staging (testing) or Production (real) environment.
2Enter your domain name (e.g., example.com or *.example.com).
3Add the DNS TXT record to verify domain ownership.
4Download your free SSL certificate and private key.
Use Cases
•Secure multiple subdomains with a single wildcard certificate
•Automate SSL certificate issuance for development and staging
•Replace expiring certificates without manual intervention
•Secure API endpoints and microservices with free certificates
Technical Details
Certificate Info
Issuer: Let's Encrypt
Validity: 90 days
Type: Wildcard (DV)
ACME Protocol
DNS-01 challenge validation
Staging and Production environments
Automatic account registration
What ACME Automates
ACME is the protocol that makes certificate issuance automatable: a client proves control of a domain to an authority and receives a certificate, repeatably and without manual steps.
1Challenge-based validation is the core, and the challenge type determines everything about how the protocol fits your setup. HTTP-01 needs port 80 reachable; DNS-01 needs the ability to create a TXT record, which is why it is the only option for wildcard certificates and for hosts behind a proxy.
2Renewal is the reason to use it at all. Because issuance is a repeatable protocol rather than a purchase, certificates renew automatically — which matters most now that lifetimes are short. A renewal that works once is the hard part; running it unattended is the point.
3Rate limits are the constraint to design around, and failing repeatedly against one is how certificates get stuck. The relevant limits are per-domain and per-account, which means retries are the wrong response and spacing them out is the right one.
ACME is standardised and implemented by every current client, so the choice is less about the protocol than about which client and challenge type fit your infrastructure. What you are really choosing is how validation reaches your DNS or web server.
Tips & Best Practices
•Always test with Staging first before issuing Production certificates.
•DNS propagation can take up to 48 hours — wait before verifying.
•Certificates expire in 90 days — set up auto-renewal.
Frequently Asked Questions
Yes. Let's Encrypt is one of the largest certificate authorities in the world, and its root certificates are present in the trust stores shipped with every current browser and operating system, which is why its certificates are accepted without any manual step on the visitor's side. Being trusted does not mean the certificate is free of operational work: because they are valid for only 90 days, automation is mandatory rather than optional, and a failed renewal is the most common cause of a Let's Encrypt outage.
A wildcard certificate covers a domain and every subdomain beneath it in a single name, written as an asterisk followed by the domain, such as *.example.com. It is the efficient way to secure many hosts that share a parent domain, because one certificate replaces twenty. The limitation is that it matches exactly one label: *.example.com covers mail.example.com and api.example.com, but not deeper names such as a.b.example.com, and never the bare example.com itself. That last point surprises people, because the wildcard looks as though it should cover the apex too.
Ninety days, deliberately short. The short lifetime limits the damage from a private key that leaks, because there is a small window in which the certificate is exposed and it expires on its own soon afterwards. It also means renewal is not optional: a site on a 90-day certificate without working automation will break every ninety days, so set up an ACME client and verify it before you need it. Renew well before the expiry date rather than on the day, because rate limits apply to repeat failures.
Because it does not depend on your web server being reachable on port 80, and because it is the only challenge that works for wildcard certificates. It also survives being behind a proxy or a CDN, since validation happens in DNS rather than over HTTP. The trade-off is that it needs API access to your DNS provider, which is a credential worth scoping carefully.
By not retrying aggressively. Limits are per-domain and per-account over a window, and repeated failed attempts consume the same budget as successful ones. When renewal fails, the answer is to fix the underlying cause before retrying — usually a DNS permission or a port that stopped being reachable — rather than to retry on a shorter schedule, which makes exhaustion faster.
The certificate expires, and it usually does so quietly — which is why the failure mode is worth planning for rather than assuming against. Monitoring that checks what is actually served catches it, since your own records will show a successful renewal while the server still holds the old file. That is the same silent-deployment failure that affects every other automated certificate workflow, and external verification is the only reliable check.
Yes, provided the CA implements the protocol, and several do. The mechanism is identical — a client validates against a private endpoint rather than a public one — so internal automation uses the same tooling with a different directory URL. That is worth knowing if you want renewal behaviour consistent across public and internal estates without maintaining two separate processes.
You need a client — the protocol defines the interaction and the client implements it. In practice you are choosing how validation reaches your infrastructure, which is the meaningful decision: HTTP validation needs port 80 free, DNS validation needs API credentials, and some clients support plug-ins for particular DNS providers or servers. Check which challenge types your chosen client supports before committing to a validation method.
