# Free TLS certificates and ACME

A free TLS certificate is a domain-validated certificate issued by a public CA over ACME, a protocol that proves you control a hostname and hands back a certificate with no human in the loop. Let's Encrypt, ZeroSSL and Google Trust Services all issue them at no cost and all speak the same protocol, so the client you run matters more than the CA you point it at. Free covers domain validation only. Nothing free will vet your organisation, issue a client certificate for mTLS, or certify a hostname that does not resolve publicly — those need a commercial CA or one of your own.

Source: https://certguru.io/concepts/free-tls-certificate/
Last updated: 2026-08-19
Commands verified against OpenSSL 3.5.7.

---

## What ACME actually does

Every free publicly trusted certificate comes out of the same protocol. ACME — Automatic
Certificate Management Environment, RFC 8555 — replaces the old cycle of generating a request,
pasting it into a web form, waiting for an email and downloading a zip file. A client running on
your server does all of it:

1. Registers an account key with the CA.
2. Asks for a certificate covering a list of names.
3. Receives a **challenge** for each name — something only whoever controls that name can do.
4. Completes the challenges, sends a CSR, and receives the certificate.

The CSR has not gone away; you just never see it. The client generates the key and the request
locally, exactly as [openssl req](/openssl/generate-csr/) would, and the private key never leaves
the machine. What ACME removes is the person in the middle.

That is also what makes free issuance possible. A CA that never has to pay anyone to read an email
can afford to charge nothing — and in exchange it issues certificates with short lifetimes, which
is the trade the whole model rests on.

## Which CAs issue free certificates

| CA | Run by | Worth knowing |
| --- | --- | --- |
| Let's Encrypt | ISRG, a nonprofit | The default choice, and the reference implementation of the model |
| ZeroSSL | A commercial CA | ACME plus a web UI; the free tier sits inside a paid product |
| Google Trust Services | Google | ACME issuance tied to a Google Cloud account |

All of them are domain validation only, all of them are in the same root stores, and all of them
speak the same protocol — so the choice is close to reversible. Pointing a client at a different
ACME directory URL is a one-line change. Choose on operational grounds: rate limits, who you
already have an account with, whether you want a UI. Certificate quality is not a differentiator,
because there is no difference to find.

> **The protocol is stable; the offers are not**
>
> Free tiers, rate limits and even which CAs run them change on their own schedule, and any list of
>   them ages badly. RFC 8555 has not moved. Learn the protocol, and treat the table above as
>   something to re-check rather than something to rely on.

## The challenge type decides what you can get

Two challenges matter in practice, and the one you are able to complete decides what the CA is
willing to issue.

| | HTTP-01 | DNS-01 |
| --- | --- | --- |
| Proves control by | Serving a token under `/.well-known/acme-challenge/` | Publishing a TXT record at `_acme-challenge` |
| Requires | Port 80 reachable from the internet | API access to your DNS provider |
| Wildcards | No | Yes — the only way to get one |
| Works with no inbound connectivity | No | Yes |

*The same client, one challenge each*

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

certbot certonly --dns-cloudflare -d example.com -d '*.example.com'
```

Neither block is marked for verification. Both need a public hostname and a live CA, and the
[test harness](/methodology/) runs with no network by design, so these are reviewed by hand
instead.

## What free will not give you

- **Organisation or extended validation.** Free issuance proves control of a name and nothing
  else. If you need a certificate that says a company exists, you are buying it.
- **Client certificates.** ACME issues `serverAuth` certificates. Anything for
  [mTLS](/concepts/mtls/) comes from a CA you run — see
  [create a client certificate](/openssl/create-mtls-client-certificate/).
- **Names that do not resolve publicly.** `.local`, `.internal`, bare hostnames and private IP
  ranges cannot pass any challenge, because no public CA is able to validate them. This is the case
  people try hardest to solve with a self-signed certificate, and it is the case
  [a private CA](/openssl/create-root-ca/) exists for.
- **Long lifetimes.** Short validity is deliberate, not a limitation of the free tier. Something in
  your stack that cannot renew unattended is a problem to fix rather than to buy your way around.

## Renewal is the whole point

The certificate is not the deliverable — unattended renewal is. Issuance happens once and renewal
happens for as long as the service exists, so the only question worth asking of a setup is what it
does when nobody is watching it.

*A renewal monitor cares about the exit status, not the output*

```bash
openssl x509 -in certificate.crt -noout -checkend 2592000
```

Expected output:

```
Certificate will not expire
```

That is thirty days in seconds; a non-zero exit means the certificate expires inside the window.
Alert on it even when renewal is fully automated, because the failure that actually hurts is the
renewal that quietly stopped working — and until the day it matters, that looks exactly like one
that is still running.

More at [check certificate expiry](/openssl/check-certificate-expiry/) and
[fixing "certificate has expired"](/errors/certificate-has-expired/).


## Frequently asked questions

### Are free certificates less secure than paid ones?

No. A certificate from Let's Encrypt and one costing several hundred pounds carry the same key, the same signature algorithms and the same status in the same root stores. What money buys is organisation vetting, a warranty and a support contract — not stronger cryptography.

### Can I get a free wildcard certificate?

Yes, but only through the DNS-01 challenge, which means your ACME client needs API credentials for your DNS provider. HTTP-01 cannot issue a wildcard, whoever the CA is.

### Why do free certificates expire so quickly?

Short lifetimes limit the damage a compromised key can do, and they force renewal to be automated rather than remembered. Certificate lifetimes are shrinking across the whole industry, not only at free CAs.

### Do I still need to generate a CSR?

Your ACME client generates one for you, along with the private key, and neither leaves your server. You only handle a CSR by hand when dealing with a CA that has no ACME support.


## References

- [RFC 8555: ACME](https://www.rfc-editor.org/rfc/rfc8555) — the protocol behind automated free issuance
- [Let's Encrypt documentation](https://letsencrypt.org/docs/) — rate limits, challenge types and chain layout

## Related pages

- https://certguru.io/concepts/self-signed-vs-ca-signed/
- https://certguru.io/platforms/certbot/
- https://certguru.io/concepts/wildcard-certificate/
- https://certguru.io/openssl/generate-csr/
- https://certguru.io/openssl/create-root-ca/
- https://certguru.io/errors/certificate-has-expired/
- https://certguru.io/openssl/create-mtls-client-certificate/
- https://certguru.io/concepts/certificate-chain/

--
CertGuru — https://certguru.io