|
|
|
|
|
|
by gruez
3167 days ago
|
|
|
>certificates costs money you still pay for x years certificate, but you only get a valid certificate for the next y days. if the CA can sign OSCP responses for millions of visitors, surely they can resign a certificate every y days. >the world was mostly manual in the past (and in a lot of places still is) that makes sense when talking about OSCP, but to get OSCP stapling working, you need to configure your web server to do so. instead of standardizing OSCP stapling, why couldn't they have standardized a protocol for a server to get updated certificates from the CA? |
|
|
That's essentially OCSP :-)
In general there's not really a concept of an "updated certificate". A certificate is good if the signature matches, the subject on the cert matches the server, and the current time is within the certificate's validity period; otherwise, the cert is bad. If someone steals a certificate, the website fixes this by telling the C.A. to revoke the certificate and by serving a different valid cert – my old employer kept a second valid certificate lying around in order to minimize downtime in the event of having to kill the main cert. OCSP is a way to effect the killing of the bad certificate. But in the absence of OCSP or some other revocation mechanism both certs are still good.
> if the CA can sign OSCP responses for millions of visitors, surely they can resign a certificate every y days.
I haven't worked on this stuff in a few years, but historically OCSP resolvers were notoriously unreliable and often down. That's a huge issue for a security-critical path, because you're forced to "fail open" (which defeats the whole point of having OCSP in the first place) or render a wretched experience for your user. One big reason OCSP stapling exists is to work around C.A. OCSP resolvers' unreliability.