SSL Ghosts: When Certificates Are There But Everything Still Burns

Hunting Ghosts in the SSL Certificate Chain

The borisovai-admin project was silently screaming. HTTPS connections were failing, browsers were throwing certificate errors, and the culprit seemed obvious: SSL certificates. But the real investigation turned out to be far more interesting than a simple “cert expired” scenario.

The task was straightforward on the surface—verify that Traefik had actually obtained and was serving the four Let’s Encrypt certificates for the admin and auth subdomains across both .tech and .ru TLDs. What made this a detective story was the timing: DNS records for the .ru domains had just propagated to the server, and the team needed to confirm that Traefik’s ACME client had successfully validated the challenges and fetched the certificates.

First, I checked the acme.json file where Traefik stores its certificate cache. Opening it revealed all four certificates were there—present and accounted for. The suspicious part? The Traefik logs were full of validation errors. For a moment, it looked like the certificates existed but weren’t being served correctly.

Here’s where the investigation got interesting. Diving deeper into the certificate details, I found that all four certs were actually valid and being served properly:

• admin.borisovai.tech and admin.borisovai.ru—both issued by Let’s Encrypt R12
• auth.borisovai.tech by R13
• auth.borisovai.ru by R12

The expiration dates were solid—everything valid through May. The error logs suddenly made sense: those validation failures in Traefik weren’t current failures, they were historical artifacts from before DNS propagation completed. Traefik had attempted ACME challenges multiple times while DNS was still resolving inconsistently, failed, retried, and then succeeded once DNS finally stabilized.

The real lesson here is that ACME systems are resilient by design. Let’s Encrypt’s challenge system doesn’t just give up after one failed validation—it queues retries, and once DNS finally points to the right place, everything resolves automatically. The certificates were obtained successfully; the logs were just recording the journey to get there.

For anyone debugging similar issues in a browser, the solution is refreshing the local DNS cache rather than diving into logs. Running ipconfig /flushdns on Windows or opening an incognito window often reveals that the infrastructure was actually fine all along—just the client’s stale cache creating phantom problems.

The next phase involves reviewing the Authelia installation script to ensure access control policies are properly configured for these freshly validated endpoints. The certificates were just act one of the security theater.

How do you know God is a shitty programmer? He wrote the OS for an entire universe but didn’t leave a single useful comment.