Fix unpredictable first load initialization issue

For further context:

Hey, I'm running into some SSL issues. I have a novel (very simple) architecture - I'm serving static HTML and using subdomains to pass variable data to a single index.html. Let me know if this is worth filing a GH issue.

This website is just a test of a Claude Code plugin that generates web apps with this architecture based on simple user prompts. I'm hoping you you can be a VM host for plugin users.

Test VM Setup

• VM: cronos.exe.xyz
• Custom domain: cronos.computer
• DNS config:
  • ALIAS @ → exe.xyz
  • CNAME * → cronos.exe.xyz
• No manual certbot setup (relying on exe.dev's automatic SSL)

Multi-Tenancy Architecture I'm using a subdomain-based multi-tenancy model where:

• All subdomains serve the same static index.html file
• The subdomain is read client-side via window.location.hostname
• The subdomain string is used to namespace a local-first database (Fireproof)
• No server-side routing differences between subdomains - they all hit the same resource

This means admin.cronos.computer, tenant1.cronos.computer, and foo.cronos.computer all serve identical content - the subdomain is purely a data parameter for client-side tenant isolation.

Issue A test user visiting https://foo.cronos.computer received:

NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

This occurred hours after DNS was configured, on what was likely the first-ever visit to that specific subdomain.

What I've Observed

• The error is intermittent - currently cannot reproduce
• Novel subdomains (e.g., novelsubdomaintest.cronos.computer) now work immediately
• CT logs (crt.sh) show per-subdomain certs issued by Let's Encrypt E7/E8 on-demand
• No wildcard cert for *.cronos.computer

Questions

1. Is there a known race condition in the on-demand certificate issuance for custom domains?
2. Should custom domains using wildcard CNAME records set up their own wildcard cert via certbot to avoid this?
3. Could exe.dev support automatic wildcard certificates for custom domains? Given the multi-tenancy use case, a single *.cronos.computer cert would eliminate first-visit certificate issuance entirely.
4. Are there any logs on your end that might show what happened during the failed request?

Environment

• VM image: default exeuntu
• Error timestamp: ~1 hour before this report (exact time TBD)
• Subdomain that failed: amy.cronos.computer
• Browser: Mac Chrome & mobile Safari

Thanks for any insights!

Additional Context for Reference

Knowns

• exe.dev uses on-demand per-subdomain certificate issuance (not wildcards)
• Certificates are issued via Let's Encrypt E7/E8 intermediates
• Current system works - novel subdomains get valid certs immediately
• The error suggests SCTs were missing or invalid during the TLS handshake

Why my architecture is weird The subdomain-based multi-tenancy model means:

• Unlimited arbitrary subdomains are valid (any string a user chooses)
• A wildcard certificate (*.cronos.computer) would be ideal since all subdomains serve the same content
• On-demand per-subdomain cert issuance works but introduces potential first-visit latency/failures
• Pre-warming subdomains isn't practical when tenants self-provision their subdomain names

Possible Causes

1. Race condition between cert issuance and SCT embedding
2. CT log propagation delay during cert issuance
3. Temporary infrastructure inconsistency
4. Client-side issue (browser cache, extension, or Chrome bug)

Sources

• CT log lookup for cronos.computer
• exe.dev proxy docs
• Chrome CT error troubleshooting