OCSP responder reports revoked state for revoked-isrgrootx1.letsencrypt.org but stapled response is good?

Issuance Tech
1

Hello,

when looking at the OCSP Stapled Response from the cert revoked test page https://revoked-isrgrootx1.letsencrypt.org the leaf cert status shows up as good, while when fetching the status directly rom the OCSP responder the status is reported as revoked.

Command for showing the stapled response:

openssl s_client -connect revoked-isrgrootx1.letsencrypt.org:443 -tls1 -tlsextdebug -status
CONNECTED(00000003)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "EC point formats" (id=11), len=4
0000 - 03 00 01 02 ....
TLS server extension "session ticket" (id=35), len=0
TLS server extension "status request" (id=5), len=0
TLS server extension "heartbeat" (id=15), len=1
0000 - 01 .
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = origin.letsencrypt.org
verify return:1
OCSP response:
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
Produced At: Apr 11 16:01:00 2019 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
Serial Number: 035AEC287BC6611BF98AFEBB4BC7ED60186B
Cert Status: good
This Update: Apr 11 16:00:00 2019 GMT
Next Update: Apr 18 16:00:00 2019 GMT

Command for fetching the cert's state directly from the responder:

openssl ocsp -header "HOST" "ocsp.int-x3.letsencrypt.org" -verify_other chain.pem -issuer chain.pem -cert certificate.pem -text -url http://ocsp.int-x3.letsencrypt.org
OCSP Request Data:
Version: 1 (0x0)
Requestor List:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
Serial Number: 03EB7D138B645D1C08B3A55F45A8AA3A8539
Request Extensions:
OCSP Nonce:
0410F3C79E45207C76DE5B07EAC49E33E008
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
Produced At: Apr 11 16:07:00 2019 GMT
Responses:
Certificate ID:
Hash Algorithm: sha1
Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
Serial Number: 03EB7D138B645D1C08B3A55F45A8AA3A8539
Cert Status: revoked
Revocation Time: Mar 27 16:00:41 2019 GMT
This Update: Apr 11 16:00:00 2019 GMT
Next Update: Apr 18 16:00:00 2019 GMT

Now, as we know the test page shows up without any error in Chrome. However, folks there claim that they respect a stapled OCSP response (last comment by rsleevi on 361230 - chromium - An open-source project to help move the web forward. - Monorail), which made me wonder why it's then working fine in Chrome until I looked at the response myself. Am I missing something?

2

The first command is missing the servername parameter. As seen in the response the loaded cert was for origin.letsencrypt.org.

openssl s_client -connect revoked-isrgrootx1.letsencrypt.org:443 -tls1 -tlsextdebug -status -servername revoked-isrgrootx1.letsencrypt.org

The response doesn't include a stapled OCSP response. Shouldn't it though? It's apparently the only way to motivate Chrome to not load the page.

2 Likes
3

Hi @bbindreiter, welcome to the community forum :wave:

Yup! Good catch :slight_smile:

The purpose of the page isn't necessarily to demonstrate what a Chrome revocation interstitial looks like but I will inquire about whether our SRE team can enable OCSP stapling for this host as well.

4

I'm told we tried this before and out of the box nginx won't staple a revoked response. It's something that would require more work than can be prioritized right now.

5

–LE have Must-staple option for certs. Doesn’t having no stapled OCSP while cert requires it trigger error on chrome?–

edit : no. chrome doesen’t support Must-staple

6

This isn't something included by default. Clients have to request it by including an extension in the CSR submitted to the newCert endpoint (v1) or when finalizing orders (v2).

7

Fair enough, the cert doesn’t have the must-staple extension set, therefore a missing stapled response is fine.

It’s however easy to serve stapled response from nginx. I followed this guide a while ago and it worked out fine: https://www.digitalocean.com/community/tutorials/how-to-configure-ocsp-stapling-on-apache-and-nginx

Thank you very much for the clarification though @cpu

1 Like
8

Happy to help!

Yes, it's easy to enable the configuration in nginx. The problem in practice is with how nginx reacts at runtime with an OCSP response that is revoked. That's the catch in this case, not enabling the configuration.

9

You’re right, according to what Ryan Sleevi wrote in the Chromium ticket they don’t respect it, however if a stapled response comes along they’ll check it and act accordingly. My understanding is that the LE revocation page should then fail to load once a stapled response will be sent.

10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.