Skip to main content
banner image
venafi logo

OCSP Must-Staple: Revocation That Works

OCSP Must-Staple: Revocation That Works

OCSP Must-Staple
November 28, 2018 | Featured Blogger: Scott Helme

Revocation checking is broken and has been for some time. Whilst some vendors have sort of worked around this with proprietary solutions, there is little that the smaller sites can do. OCSP Must-Staple to the rescue!

Revocation checking

In the early days of the web we had Certificate Revocation Lists, or CRLs. These were lists of all certificates that a CA had revoked and could be downloaded by a client to check if the certificate they were served had been revoked. These lists didn't scale and eventually downloading these large files became a problem, thus the Online Certificate Status Protocol, or OCSP, was born. Instead of the client downloading a list of all revoked certificates, they would submit a request to the CA to check the status of the specific certificate they had received. Sadly OCSP was riddled with problems like poor CA infrastructure being unavailable and the privacy concern of clients leaking the site they were visiting to the CA. To get around this problem OCSP Stapling was created. Instead of the client making the OCSP request to the CA, the host website would make the request and 'staple' the response to the certificate when they served it. Because the OCSP response is short lived and digitally signed by the CA, the client can trust the stapled OCSP response. The final problem was that the client had no idea that the site in question supports OCSP and whether or not it should expect them to staple an OCSP response. Thus, we finally arrived at OCSP Must-Staple.

OCSP Must-Staple

Setting up OCSP Must-Staple is fairly easy as it's simply a flag that needs to be set by your CA in the certificate they generate for you. This flag instructs the browser that the certificate must be served with a valid OCSP response or the browser should hard fail on the connection. How you obtain your certificates will depend on how you set the OCSP must-staple flag but if you followed my previous guide on Getting started with Let's Encrypt then it's really easy. First of all you need to edit the OpenSSL config file used to generate your CSR.


Next, find the section where you set your req_extensions, for me I call it v3_req.


This section will contain other details including your SAN.


To setup OCSP Must-Staple all you need to do is add the following line.


Don't worry too much about the details here, but if you do want to know then is the object identifier for SMI Security for PKIX Certificate Extension and 24 is the id assigned to RFC 7633. After the = is the ASN.1 DER encoding of the Features structure, or the value 5 to you and I. If you're using OpenSSL 1.1.0 or higher then you can specify this extension in a much prettier way, check the update at the bottom of the article. With that aside, you're ready to regenerate your CSR.


With this you can now call your renewal script or call acme_tiny (or which ever Let's Encrypt client you're using) to get a new certificate that will contain the OCSP must-staple extension.


Checking for OCSP must-staple

The easiest way to check if you're new certificates are properly flagged as OCSP Must-Staple is with the awesome SSL Labs test built by Ivan Ristic. A quick scan will tell you exactly what you need, just look in the Authentication section of the report.


You can also do this from the command line before you try to use the certificates by checking both the CSR and the signed certificate you obtain. To check your certificate use the following command.


In the output you're looking for the x509v3 extensions section and specifically which is what we created earlier.


It's the same approach for the CSR with a change on the command to use req instead of x509 and the appropriate CSR file.


In the output from the CSR you're looking for the exact same thing as above in the certificate.

Revocation checking that's reliable

The big problem that we had with revocation checking was that we couldn't rely on it. CRLs were bad, OCSP endpoints were unreliable and stapling helped but we didn't know if the site supported it. Now we do. In the event of a compromise or any other scenario where you find yourself needing to revoke your certificate you can be confident that when the client receives your certificate in a connection it will be forced to check for a stapled OCSP response. This offers a huge level of protection and reduces the potential time an attacker can abuse a compromised certificate from the maximum life of the certificate, which could be up to 39 months, down to the maximum life of the last valid OCSP response, which could be a few hours.

It's not perfect but OCSP must-staple presents the first opportunity for us to rely on revocation actually working. There are some concerns about depending on your CA to deliver you a valid OCSP response to serve and the implementation of OCSP stapling in web servers could do with a little work too. I'm publishing another blog this week about a mechanism similar to CSP/HPKP reporting called OCSP Expect-Staple where the browser will report back if it doesn't receive a valid OCSP staple. Check back in a few days.

Update 14th Feb 2017

If you're using OpenSSL 1.1.0 or higher then there is a slightly nicer way of specifying the Must-Staple flag as pointed out by Rob in the comments below. Check your version of OpenSSL before using this:


OpenSSL 1.1.0c 10 Nov 2016

If your version is 1.1.0 or higher you can place the following in your openssl.cnf file instead.

[ v3_req ]

basicConstraints = CA:FALSE

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

subjectAltName = @alt_names

tlsfeature = status_request

This post originally appeared on

Related Articles

Like this blog? We think you will love this.
Featured Blog

Exposed TLS Certificates Force PKI Lead to Quit: How Badly Managed PKI Poses Serious Risk [Case Study]

'I'm out of here' — PKI lead  That’s th

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

Subscribe Now

See Popular Tags

You might also like

TLS Machine Identity Management for Dummies

TLS Machine Identity Management for Dummies

Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

About the author

Featured Blogger: Scott Helme
Featured Blogger: Scott Helme

Scott Helme is an international speaker, security researcher and blogger that specializes in online security. He also founded and, free online tools to deploy better security. 

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud

Venafi Cloud manages and protects certificates

* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
* Please fill in this field
* Please fill in this field
* Please fill in this field

End User License Agreement needs to be viewed and accepted

Already have an account? Login Here

get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more