If a certificate shows as untrusted and the issuer is "Fake LE Intermediate" or similar, this means a Let's Encrypt staging (testing) certificate is installed rather than a production one — this is entirely expected behavior, not a malfunction, since staging certificates are deliberately signed by a root that's not in any public trust store, specifically so testing doesn't count against production rate limits.
The fix
Reissue using Let's Encrypt's production environment rather than staging — with Certbot, this simply means running the issuance command without the --staging or --dry-run flag that was likely used (intentionally or accidentally) during initial testing.
Why Let's Encrypt's staging environment intentionally issues untrusted certificates
Let's Encrypt's staging environment exists specifically for testing automation and configuration without consuming production rate limits, and deliberately issues certificates from an untrusted staging root precisely to prevent staging certificates from being mistaken for production-ready ones.
How to confirm you're accidentally using the staging endpoint rather than production
Checking your ACME client's configured server URL against Let's Encrypt's documented staging versus production endpoints confirms whether a --staging or --test-cert flag was accidentally left enabled, the most common cause of unexpectedly receiving an untrusted staging certificate.
What the staging certificate's issuer name specifically looks like when inspected
A staging certificate's Issuer field explicitly references Let's Encrypt's staging environment rather than its production issuing certificates — checking this field directly confirms definitively whether you're looking at a staging certificate before investigating any other potential cause.
How to properly switch your ACME client from staging back to production
Removing any explicit --staging or --test-cert flag from your ACME client's command or configuration, then requesting a fresh certificate, switches issuance to Let's Encrypt's production environment — worth double-checking your client's specific documentation for the exact flag name, since it varies slightly between different ACME clients.
A final note on preventing this specific mistake
Adding a clear comment or note in your deployment scripts or configuration wherever a staging flag is used prevents this specific, easily-made mistake, forgetting to remove a staging flag before a genuine production deployment, from recurring on a future deployment.
What the exact command flags look like for major ACME clients to avoid this mistake
Certbot: ensure --staging is not present for a genuine production request. acme.sh: ensure --test is not present. Reviewing your specific automation script or scheduled job for a forgotten flag left over from initial testing resolves this exact, common mistake.
How to build a safeguard into your deployment process to catch this automatically
Adding an automated check in your deployment pipeline that inspects a newly issued certificate's issuer field for the word 'staging' and fails the deployment if found catches this specific mistake automatically before an accidentally-staging certificate ever reaches production.
A quick closing checklist
A quick closing checklist covers checking your certificate's issuer field for staging-specific naming, reviewing your ACME client configuration for a forgotten staging flag, and building an automated safeguard into your deployment process to catch this mistake before it reaches production.
What role a dedicated staging environment plays in preventing this mistake entirely
Maintaining a genuinely separate staging environment with its own distinct domain and configuration, rather than toggling a flag on your production configuration for testing, structurally prevents this mistake by never mixing staging and production certificate requests on the same infrastructure at all.