I think it’s not reasonable expect that Let’s Encrypt implement it for all certificates (because it will imply that all server using Let’s encrypt support it), but If they plan it, I hope it’s before the end of the beta period.
A less radical option could be an optional argument during the certificate generation for the client to specify that he want that particular extension (but it could imply and update of the ACME protocol). to accept it when the user request it via the CSR. I think that option will help the check of the revocation status for legitimate certificate (in case the private key gets stolen) but will be less helpful for certificates generated without the consent of the owner of the domain (even if CT could help detect it).
I dont really hope so. being enforced to set each staple domain on its own is annoying, as long as the servers cannot get the stapling work with a switch and without the pain of DLing CA Bundles and having to set a lot of stuff per domain , please dont enforce it.
I mean the server could get the OCSP url out of the cert and/or immediate, so why would I need to speify the CA bundle and stuff, especially for certs that are already in the system trust store.
Hi both of you did not look correctly “OCSP Must-Staple TLS Feature Extension” this in and TLS/SSL protocol feature.
This describe an feature that can be requested by the CSR request and should not be enforced by the CA.
so I thought that CAs can easily enforce it and I certainly dont want this, also "should not" means they can it's just not recommended, assuming the "should not" is the same as used in RFCs...
but if it's request-only I am fine.
I think if it's OPTIONAL it's okay but I think everyone MUST be able to make their own choices so LE certs SHOULD NOT be longer than 90 days, but if they know what they are doing they MUST be able to get longer certs, that's my opinion.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
also instead of must staple I'd rather have a parameter to enforce the check no matter whether it's stapled or not.
I think, servers have to learn more for must-staple than just deducing the cert path. E.g., a must-staple server shouldn’t start serving until he has a valid OCSP response. And remember, it’s not just the web servers, there are IMAP, SMTP, XMPP and all kinds of other animals in the TLS zoo which have to learn new tricks.
Anyway, I like the idea of short-lived certificates, but the shorter they get the less important OCSP (stapling) becomes. As I already said, OCSP serves as a kind of short-lived certificate for the actual certificate. In the end, they converge to a (very) short-lived certificate which the server has to renew once every n hours or days, and that’s it, without OCSP stapling at all. ACME is the starting point for automating that process.
And as soon as admins get used to short-lived certs and see their benefits, they might want to pay for the additional load they put on the signing CAs. OCSP stapling is currently seen as a for-free service with limited quality and a trade-off between short and long lifetime. Short lifetimes result in higher load on the OCSP server from the admin’s servers renewing their stapling, while longer lifetimes increase the reaction time for sorting out bad certificates.
DV signing CAs typically don’t care for anything in the CSR except the modulus. So especially for DV certificates it’s gonna be a CA’s decision to do or don’t apply the “OCSP Must-Staple Feature Extension”.
well they should care for some extensions, especially the must staple.
yeah a must-staple server shouldnt do his stuff without an OCSP obvious, but a normal server with just stapling enabled should in my opinion just need a one liner like “stapling on” or whatever and just get the stapling. I mean the server already has the intermediate, so why push again a chain to it?
@tdelmas also the must-whatever-it-will be MUST always be configurable by the user and SHALL NOT be set by any CA unless explicitly requested by the user.
but by the way for some reason WoSign seems to hard-fail because the revocation data couldnt be loaded in time, any idea? I mean as far as it was written CRL/OCSP always just soft-fail…
so essentially normal DV/OV certs -> soft-fail and EV -> hard fail.
does just OCSP work or is CRL also allowed for that?
then I wonder why they have an OCSP/CRL server that’s always failing? pretty bad stuff especially if it’s mandatory, which even does make sense for EVs.
Ah, I thought flipping it in boulder-config.json was enough, but now I see it’s /test/boulder-config.json in the commit… Didn’t look good enough, my bad!
Must Staple is now enabled in staging. If you want to use the official client, you can pull the must-staple branch locally and pass the --must-staple flag, or you can generate your own CSR and use the --csr flag with one of the released client versions.
We’ll probably enable it in production sometime Thursday.
@jsha For some reason, when I put an invalid feature in the TLS Feature Extension attribute in the CSR, Boulder answers with Error: urn:acme:error:serverInternal :: The server experienced an internal error :: Error creating new cert.
I confirmed a Must-Staple TLS Feature Extension CSR can be signed on staging with the following CSR generating command:
But when you change DER:30:03:02:01:05 (status_request extension, i.e., OCSP stapling) to DER:30:03:02:01:04 (truncated_hmac extension, not valid in Boulder ofcourse), Boulde generates the above error.
The only thing in the code as far as I can see, which should “catch” this, is:
Which only adds some stats on line 343, but doesn’t result in a clear error message.
Shouldn’t the error be something more along “You’ve requested an invalid TLS Feature Extension”?
Didn’t look good enough, my bad!
