tls: every boot needs Let's Encrypt to answer, even with a valid certificate on disk · Issue #231 · permadeath.com/didbot

What happens. Every start restores the saved ACME account before it reads the certificate on disk. In instant-acme 0.8.5, restoring an account fetches the Let's Encrypt directory over the network. If that fetch fails, bootstrap fails and the server exits, even when a certificate with weeks of validity is stored on the data volume. Any restart during a Let's Encrypt outage, a DNS failure or an egress problem keeps the server offline until the directory answers again.

How to reproduce.

crates/didbot-tls/src/manager.rs:251-257 calls load_or_register_account(...).await? before stored_certificate at manager.rs:335.
manager.rs:126-128 restores the account with Account::builder_with_http(http).from_credentials(...). In instant-acme 0.8.5, AccountInner::from_credentials (account.rs:361) calls Client::new(directory_url, http).await?, which GETs the directory.
One zone's error fails the whole fleet (crates/didbot-tls/src/fleet.rs:231-236). crates/didbot-serve/src/bin/didbot-pds/run.rs:1488-1497 turns that into an exit.
A local test registered an account against FakeAcmeServer, then called load_or_register_account again on the same store with an HTTP client that always fails. It returned Acme(Other("directory unreachable")).

Why it matters. Booting with a valid certificate needs nothing from the CA. As it is, an outside outage turns a routine deploy, crash restart or host reboot into a full outage of every account on the instance. With the module's start limit of 5 starts in 120 s, the unit then stays failed after the CA recovers.