Improving revocation : will Let's Encrypt support OCSP Must-staple?

Following the blog post of Mozilla security blog Improving Revocation: OCSP Must-Staple and Short-lived Certificates I was wondering if Let’s Encrypt will implement the RFC 7633 (OCSP Must-Staple TLS Feature Extension)?

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).

1 Like

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.

I just read the mozilla thing and it said:

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
"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?

@My1 I agree with your two points :

  • I think it will be a bad idea to impose the “must staple” for people requesting certificates
  • A “Must check revocation” could be better, but that option doesn’t exist today

But, as a Let’s Encrypt user, I would like to see them allowing people to request certificate with that extension.

@tlussnig You’re right, I read too quickly. And as it’s a feature that can be in the CSR, it shouldn’t require modification of the ACME protocol.

@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…

Are you referring to the certificate they use on their homepage, or some WoSign DV certificate you encountered?

They use an EV certificate on their homepage, for which positive OCSP responses are mandatory.

I was talking about their main page.

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.

The corresponding issue in github from @jsha : Accept TLS Feature (aka OCSP Must Staple) in CSRs


@jsha I saw commit da3d31d on LE’s history page, but my Must-Staple CSR’s still result in the removal of the TLS Extension Feature in the resulting (staging) certificate.

Is this suppose to happen or should Staging already issue Must-Staple certificates?

I’ve compiled Firefox 45 (beta) on my desktop and I’m eager to test this milestone for certificate revocation checking :smiley:

1 Like

We still need to flip the config switch in staging. It’s in our queue but hasn’t happened yet. I’ll post when it does.

Ah, I thought flipping it in boulder-config.json was enough, but now I see it’s /test/boulder-config.json in the commit… :unamused: Didn’t look good enough, my bad!

No worries! I know people are excited for this feature, it’s just a matter of time and priorities. :slightly_smiling:

1 Like

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.


I’ll try it tomorrow! :smiley:

Thank you very much!

It’s a pity though Google won’t support it in Chromium/Chrome… Yet… :frowning:

@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:

openssl req -new -sha256 -key ${PRIVKEY} -subj "/CN=${1}" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=DNS:${1}\n1.")) -out ${CSR}

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”?


Thanks for reporting! I’ve filed a bug, we’ll fix it:

1 Like