- Shipped
- August 23, 2026 at 5:06 AM UTC
- Author
- Kamo
- Commit
- 1b53882
findAwaitingVerification filters confirmed domains out by design, so once ssl_confirmed was set nothing ever looked at that domain again. That was fine while the flag meant what it claimed. It was not fine while the flag could be set off a single host out of eleven: an org left with hosts that had no certificate stayed broken indefinitely behind a green 'SSL certificate installed', and nothing anywhere reported it. capcha.tech-life.com and sign.tech-life.com sat exactly like that from 2026-08-19 until today, serving Traefik's self-signed default. Certificates lapse on their own too — a secret orphaned by a repointed spec.secretName is renewed by nothing. A second sweep now re-checks confirmed domains on a long period over a small batch, re-seeds hosts that are actually bare, and withdraws the confirmation so /setup/dns stops offering Enter Workspace. It returns to true on its own once the certificates land, so the downgrade is self-healing rather than a lockout. The hazard is over-correction, so a negative has to be earned twice over. probeCertificate() is now three-valued — TRUE served a trusted certificate, FALSE the handshake was actively refused, null the probe never reached a verdict — and only FALSE counts; a connect timeout says nothing about a certificate, and treating it as absence would withdraw healthy tenants' confirmation during any transient network fault. On top of that a failing host is ignored unless its CNAME still resolves: a host the customer never pointed at us can never obtain a certificate (auto-cert skips it, since HTTP-01 would fail), so counting it would park the org in AWAITING_SSL forever over a record only the customer can add. media.b11capital.com is that case today.