# Improving revocation : will Let's Encrypt support OCSP Must-staple? **URL:** \ **Category:** Feature Requests\ **Created:** [November 23, 2015, 7:11pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334 "2015-11-23T19:11:59Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![tdelmas](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tdelmas/32/1866_2.png) [@tdelmas](https://community.letsencrypt.org/u/tdelmas)\ **Post date:** [November 23, 2015, 7:11pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/1 "2015-11-23T19:11:59Z")
Following the blog post of Mozilla security blog [Improving Revocation: OCSP Must-Staple and Short-lived Certificates](https://blog.mozilla.org/security/2015/11/23/improving-revocation-ocsp-must-staple-and-short-lived-certificates/) I was wondering if Let’s Encrypt will implement the [RFC 7633](https://tools.ietf.org/html/rfc7633) (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). ---
**Author:** ![My1](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/my1/32/1013_2.png) [@My1](https://community.letsencrypt.org/u/My1)\ **Post date:** [November 23, 2015, 7:38pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/2 "2015-11-23T19:38:43Z")
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. ---
**Author:** ![tlussnig](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tlussnig/32/2053_2.png) [@tlussnig](https://community.letsencrypt.org/u/tlussnig)\ **Post date:** [November 23, 2015, 8:05pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/3 "2015-11-23T20:05:18Z")
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. ---
**Author:** ![My1](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/my1/32/1013_2.png) [@My1](https://community.letsencrypt.org/u/My1)\ **Post date:** [November 23, 2015, 8:13pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/4 "2015-11-23T20:13:05Z")
I just read the mozilla thing and it said: > [@](#): > > When a CA adds this extension to a certificate 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. ---
**Author:** ![ecdsa-chacha20](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ecdsa-chacha20/32/955_2.png) [@ecdsa-chacha20](https://community.letsencrypt.org/u/ecdsa-chacha20)\ **Post date:** [November 23, 2015, 8:16pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/5 "2015-11-23T20:16:12Z")
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. ---
**Author:** ![ecdsa-chacha20](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ecdsa-chacha20/32/955_2.png) [@ecdsa-chacha20](https://community.letsencrypt.org/u/ecdsa-chacha20)\ **Post date:** [November 23, 2015, 8:18pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/6 "2015-11-23T20:18:02Z")
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”. ---
**Author:** ![My1](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/my1/32/1013_2.png) [@My1](https://community.letsencrypt.org/u/My1)\ **Post date:** [November 23, 2015, 8:21pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/7 "2015-11-23T20:21:53Z")
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? ---
**Author:** ![tdelmas](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tdelmas/32/1866_2.png) [@tdelmas](https://community.letsencrypt.org/u/tdelmas)\ **Post date:** [November 23, 2015, 9:22pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/8 "2015-11-23T21:22:45Z")
@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. ---
**Author:** ![My1](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/my1/32/1013_2.png) [@My1](https://community.letsencrypt.org/u/My1)\ **Post date:** [November 23, 2015, 9:30pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/9 "2015-11-23T21:30:57Z")
@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… ---
**Author:** ![pfg](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/pfg/32/1924_2.png) [@pfg](https://community.letsencrypt.org/u/pfg)\ **Post date:** [November 23, 2015, 9:37pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/10 "2015-11-23T21:37:58Z")
> [@My1](#): > > 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. ---
**Author:** ![My1](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/my1/32/1013_2.png) [@My1](https://community.letsencrypt.org/u/My1)\ **Post date:** [November 23, 2015, 9:40pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/11 "2015-11-23T21:40:58Z")
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. ---
**Author:** ![tdelmas](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/tdelmas/32/1866_2.png) [@tdelmas](https://community.letsencrypt.org/u/tdelmas)\ **Post date:** [November 29, 2015, 8:49am UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/12 "2015-11-29T08:49:43Z")
The corresponding issue in github from @jsha : [Accept TLS Feature (aka OCSP Must Staple) in CSRs](https://github.com/letsencrypt/boulder/issues/989) ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [March 6, 2016, 3:49pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/13 "2016-03-06T15:49:16Z")
@jsha I saw [commit da3d31d](https://github.com/letsencrypt/boulder/commit/da3d31d362ade9176f703eeb53ff93aa4943661a) on [LE’s status.io history page](http://letsencrypt.status.io/pages/history/55957a99e800baa4470002da), 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 😃 ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [March 6, 2016, 5:18pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/14 "2016-03-06T17:18:55Z")
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. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [March 6, 2016, 5:31pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/15 "2016-03-06T17:31:17Z")
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! ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [March 6, 2016, 6:03pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/16 "2016-03-06T18:03:33Z")
No worries! I know people are excited for this feature, it’s just a matter of time and priorities. 🙂 ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [March 22, 2016, 9:30pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/17 "2016-03-22T21:30:04Z")
Must Staple is now enabled in staging. If you want to use the official client, you can pull the [`must-staple` branch](https://github.com/letsencrypt/letsencrypt/tree/must-staple) 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. ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [March 22, 2016, 9:41pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/18 "2016-03-22T21:41:28Z")
I’ll try it tomorrow! 😃 Thank you very much! It’s a pity though [Google won’t support it in Chromium/Chrome… Yet…](https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/-pB8IFNu5tw) ☹ ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [March 24, 2016, 2:12pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/19 "2016-03-24T14:12:01Z")
@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.3.6.1.5.5.7.1.24=DER:30:03:02:01:05")) -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”? ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [March 24, 2016, 5:13pm UTC](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334/20 "2016-03-24T17:13:00Z")
Thanks for reporting! I’ve filed a bug, we’ll fix it: [https://github.com/letsencrypt/boulder/issues/1650](https://github.com/letsencrypt/boulder/issues/1650) [Next page](https://community.letsencrypt.org/t/improving-revocation-will-lets-encrypt-support-ocsp-must-staple/4334.md?page=2)