Tool to validate chain from the future?

I have a strong suspicion that my app (via the library it uses) has a bug regarding intermediates with same name in chains which potentially will result in a big problem come the Sept 30th expiry of the current R3 > DST chain.

Does anyone know of a simple tool or technique that can verify a presented tls connection and declare it valid/expired based on a given date?

Currently I'm setting the time on an Ubuntu VM to different dates then requesting stuff in Firefox etc to see what errors happen but I'm not sure this is entirely a robust test.

Ideally I'm looking for something scriptable that doesn't rely on the current machine date/time to say 'if this connect was opened on this date, it would be trusted/not trusted because x'. I'm aware of openssl s_client -showcerts -connect community.letsencrypt.org:443 but I don't see a date option.

2 Likes

Would the faketime program help?

faketime '2021-09-09 00:00:00' openssl s_client -connect community.letsencrypt.org:443

openssl verify has an -attime argument as well ... but I have never figured out quite the right invocation to verify in the same manner as a full TLS client.

5 Likes

Thanks! I'll try it out, if not I could maybe use docker to fire up openssl in a instance with different dates set.

2 Likes

I think I'll have to work on my openssl syntax but the following works well enough for a yes/no test:

faketime '2021-10-01' curl https://letsdebug.net

1 Like

Hmm, so thankfully my app seems to be OK, but worryingly once the cert is in the OS certificate store Windows may be mangling the chain from R3 onwards by mistaking it for the R3 that's going to expire (and serving that one to clients in the chain).

No idea why currently. Could still be specific to my app so will investigate others. Happy to be proven wrong :slight_smile: I'll investigate more tomorrow..

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.