Some sandboxes fail HTTPS to openrouter.ai with certificate expired

[venbrinoDev]

Some sandboxes fail HTTPS to openrouter.ai with certificate has expired, while others on the same host work

We are seeing a sandbox-specific TLS failure when calling openrouter.ai from inside Microsandbox.

Repro

Failing sandbox:

msb exec <failing-sandbox> -- sh -lc 'node -e '\''fetch("https://openrouter.ai/api/v1/models").then(async r=>console.log(r.status)).catch(e=>{console.error(e);process.exit(1)})'\'''

Result:
TypeError: fetch failed
[cause]: Error: certificate has expired
code: 'CERT_HAS_EXPIRED'

Also with curl:

msb exec <failing-sandbox> -- sh -lc 'curl -Iv https://openrouter.ai/api/v1/models 2>&1 | grep -i "expire\|cert\|SSL"'

Result:

• TLS alert, certificate expired
• SSL certificate problem: certificate has expired
  curl: (60) SSL certificate problem: certificate has expired

Control checks
Inside the same failing sandbox, these succeed:

https://example.com
https://api.github.com
https://www.google.com
Example GitHub check:

msb exec <failing-sandbox> -- sh -lc 'curl -Iv https://api.github.com 2>&1 | grep -i "issuer\|SSL certificate verify ok"'

Result includes:
issuer: CN=microsandbox CA; O=microsandbox
SSL certificate verify ok.

[venbrinoDev]

This may be related to #756, since the failure appears to happen only for a host that has a scoped secret and seems to involve the intercepted TLS path for that host.

[toksdotdev]

are you able to repro this consistently (unable to on my end)? can i see the verbose log for the curl request?

also, what version of msb are you on?

[venbrinoDev]

Hi @toksdotdev

Yes, I can reproduce it consistently, but not across all sandboxes.

What I’m seeing is:

• older sandboxes fail consistently for openrouter.ai 24 hours old sandbox
• newer sandboxes on the same host and same image work

msb version

msb 0.4.5

Logs

• Host openrouter.ai:443 was resolved.
• IPv6: 2606:4700::6812:273, 2606:4700::6812:373
• IPv4: 104.18.3.115, 104.18.2.115
• Trying [2606:4700::6812:273]:443...
• ALPN: curl offers h2,http/1.1
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: /etc/ssl/certs
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
• TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
• TLSv1.3 (IN), TLS handshake, Certificate (11):
• TLSv1.3 (OUT), TLS alert, certificate expired (557):
• SSL certificate problem: certificate has expired
• closing connection #0
  curl: (60) SSL certificate problem: certificate has expired
  More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.

we have customer really on the sandbox and it has been down for the longest

[venbrinoDev]

Hi @toksdotdev
I found what looks like the root cause in the codebase.

The intercepted per-domain certs are cached, but the cache does not seem to refresh them after expiry.

Relevant files:

• crates/network/lib/tls/config.rs
  • default validity_hours is 24
• crates/network/lib/tls/certgen.rs
  • leaf certs are generated with not_after = now + validity_hours
• crates/network/lib/tls/state.rs
  • get_or_generate_cert() returns the cached cert if present
  • I do not see an expiry check before reusing it

So the behavior seems to be:

1. first request to openrouter.ai generates a MITM leaf cert
2. cert is cached in TlsState.cert_cache
3. after ~24h it expires
4. older sandboxes keep reusing the expired cached cert
5. newer sandboxes work because they generated a fresh cert later

That matches what I’m seeing in practice:

• newer sandbox shows a Microsandbox-issued openrouter.ai cert with ~24h lifetime and works
• older sandbox fails with certificate expired

So I think the fix is probably to regenerate a cached domain cert when it is expired or close to expiry, instead of always returning the cached one.

[toksdotdev]

nice find. thanks for digging into this.