←back to thread

1318 points xvector | 7 comments | | HN request time: 0.433s | source | bottom
Show context
needle0 ◴[] No.19823806[source]
I’ll still keep using Firefox since I recognize the importance of browser diversity and the hazards of a Chrome monoculture (that and vertical tabs), but, yikes.

Still, this type of oversight seems all too common even in large companies. I remember several cases from Fortune 500 companies in the past few years alone. What would be a good way to automate checking for them? Has anyone developed a tool designed specifically to avoid certificate expiry disasters?

replies(18): >>19823825 #>>19823829 #>>19823831 #>>19823840 #>>19823848 #>>19823861 #>>19823913 #>>19823994 #>>19824009 #>>19824223 #>>19824243 #>>19824298 #>>19824668 #>>19824724 #>>19824795 #>>19824840 #>>19824927 #>>19825103 #
kam ◴[] No.19823861[source]
ACME / Let's Encrypt go in the direction of making expiry happen so often that renewal gets automated, rather than a being a rare manual process that can be forgotten about.

Not sure that's viable for a signing certificate like this, but that's the way to solve it for the web PKI.

replies(3): >>19824049 #>>19824088 #>>19824159 #
dev_dull ◴[] No.19824088[source]
It’s funny to me that people talk about this limitation as if it were some kind of virtue.
replies(2): >>19824114 #>>19824142 #
tty2300 ◴[] No.19824114[source]
Its also more secure. Long lived certs risk the possibility that someone who used to own the domain got a certificate on it and it still works after the domain is resold. Once you automate it there is no downside to short lived certs.
replies(1): >>19824233 #
1. Godel_unicode ◴[] No.19824233[source]
If only there were a way to revoke certificates. Like, some kind of list.
replies(5): >>19824271 #>>19824320 #>>19824476 #>>19824509 #>>19824811 #
2. yjftsjthsd-h ◴[] No.19824271[source]
If only such a list were actually effective rather than the majority of clients not bothering to check it.
3. lvh ◴[] No.19824320[source]
CRLs do not work in practice, and major clients routinely ignore them.
4. dwaite ◴[] No.19824476[source]
Revocation lists get huge, ultimately becoming another reason to limit cert lifetime (you don't have to tell people you revoked a certificate which is expired naturally).

Very few things check revocation, unfortunately - it puts an extra hop on the fast path of connecting to a server. OCSP stapling is pretty much the only thing a browser would care about - having the server fetch a signed OCSP response that is good for a limited period of time (say, hours), and send that along with the certificate during negotiation.

Or, you could just have the server fetch a certificate thats good for a limited period of time.

5. MrStonedOne ◴[] No.19824509[source]
Revocation requires the private key
replies(1): >>19824796 #
6. pinjiz ◴[] No.19824796[source]
This is not true. In Let's Encrypt/ACME for example, you can simply obtain authorizations for all the domains a certificate is valid for and request revocation [1]. The only thing you still need to revoke the certificate, is the certificate itself. The certificate can be obtained from CT logs.

[1] https://tools.ietf.org/html/rfc8555#section-7.6

7. pinjiz ◴[] No.19824811[source]
OCSP stapling together with OCSP Must Staple is the way to go here. All major browsers support these.

Firefox still does normal OCSP requests, Chromes does not. So if you are a Chrome user, to my understanding, there is now way to know if the server certificate was revoked or not, other than OCSP stapling together with OCSP Must Staple. Additionally, both Chrome and Firefox ship a list of revoked certificates, but it may not be updated quickly enough and as far as i can tell it mostly contains roots and intermediates.