CoyoteCert

nginx found it first. nginx always finds it first, and not in a helpful way.

Your location / block swallows the request before it reaches .well-known/acme-challenge/. Add a dedicated block above everything else:

location ^~ /.well-known/acme-challenge/ {
    root /var/www/html;
    default_type text/plain;
}

The ^~ prefix stops nginx from even considering regex locations once this prefix matches. Apache users: check that AllowOverride None is not blocking the directory, and that no .htaccess rule is redirecting HTTP to HTTPS before the token can be served.

Usually. The CA follows the 80-to-443 redirect from Always Use HTTPS, so your origin has to serve the token over HTTPS too. If a WAF rule, a challenge page or a cache rule answers instead, the CA gets that instead of the token.

Easiest fix: switch to DNS-01. Cloudflare is a built-in DNS provider, so it is a one-line handler swap and the orange cloud stays orange.

Committed to HTTP-01? Grey-cloud the record (DNS only) during issuance, then flip it back. Cloudflare's proxy can be asked to step aside briefly. It doesn't like it, but it cooperates.

Missing storage, or the storage path changes between runs. Without a storage backend, needsRenewal() always returns true because there is nowhere to check what you already have. Like a dog who has never seen a ball before. Every single time.

->storage(new FilesystemStorage('/etc/coyotecert'))

Same path, every run. If you are using DatabaseStorage, confirm the connection points at the same database as last time and not your staging environment.

When the CA says so. If the CA supports ARI (RFC 9773), its renewal window decides, including the early window it opens when it is about to revoke certificates. Without ARI, renewal starts once a third of the lifetime is left: 30 days for a 90-day cert, about 2 days for a 6-day one.

Prefer a fixed threshold? Pass it, and it applies on top of the ARI window:

->issueOrRenew(daysBeforeExpiry: 14)

Either way, a daily cron job is enough. Calls that aren't due do nothing.

Yes, but DNS-01 only. RFC 8555 forbids wildcard validation over HTTP-01 or TLS-ALPN-01. That is not a CoyoteCert limitation. It is a rule carved into the RFC the same way the ACME Corporation name was stamped into every box of defective rocket skates.

->identifiers(['*.example.com', 'example.com'])
->challenge(new CloudflareDns01Handler(...))

*.example.com covers subdomains but not the apex itself, so include both if you need the root. And *.*.example.com is not a thing. The exception message will remind you of this fact.

Use LetsEncryptStaging. The certificates are not browser-trusted but the full ACME handshake is byte-for-byte identical to production. Hammer it as many times as you need.

$coyote = CoyoteCert::with(new LetsEncryptStaging())
    // ... rest of your config

When everything looks good, swap to LetsEncrypt and issue once for real. Do not skip staging and go straight to production. Someone does this every time, and they always end up filing a rate limit issue on GitHub.

Yes. Use DatabaseStorage with a shared MySQL, PostgreSQL or SQLite database, or FilesystemStorage on a shared volume. One account key per CA, shared by however many servers you run.

->storage(new DatabaseStorage($sharedPdo))

Writes are atomic, so nobody ever reads half a key. There is no lock across servers, though: run renewal from one server, or wrap it in a lock (flock, your scheduler's "one server only" option). Otherwise two servers due at the same moment both order a certificate, and the last one to save wins.

Mostly fixes, some of which change behaviour: ARI now works against real CAs, renewal timing follows the CA or the certificate's lifetime instead of a flat 30 days, Hetzner moved to the Hetzner Cloud API (new token needed), and Buypass is gone because Buypass shut down its ACME service.

The upgrade guide lists every change and what to do about it. Most apps using the builder only need its first section.