3 ms·
> browsers silently cache intermediate TLS certificates that they've seen before, in addition to being willing to download them under the right circumstances A
by xg15 4y ago
> browsers silently cache intermediate TLS certificates that they've seen before, in addition to being willing to download them under the right circumstances
A bit OT but how would you even go about downloading a certificate? From my understanding, certificates are transmitted as part of the TLS handshake, so it's not like there is some url you could send a GET request to. Or is there some facility in TLS where a client can request additional certificates?
- cipherboy 4y agoIf you visit the site in most (desktop) browsers, you can usually click the lock icon, navigate through various intermediate steps (Firefox is Connection Secure -> View Certificate) and find details about the cert or download it (hidden in the middle). $ openssl s_client -showcerts -connect <host>:<port> also does it from the command line.
- xg15 4y agoI didn't know about that command line invocation. Thanks a lot! That's just the UI side though. I'm wondering what is actually happening on the wire when I run that command. Is there some TLS opcode which lets a client request certificate from the server?
- cipherboy 4y agoNah, no op code. You just open a regular connection and then terminate it. This forces the TLS server to auth (as the CLI OpenSSL lacks session resumption tickets).
- xg15 4y agoWell yes, but the whole point of this thread is servers which don't include intermediate certs in the regular handshake. The article says about this: > The website worked in other browsers because browsers silently cache intermediate TLS certificates that they've seen before, in addition to being willing to download them under the right circumstances. I understood that as "some clients can recover from that situation by either caching the certs from a previous handshake or somehow downloading them on their own". And I was curious about the last point.