Solved OCSP Stapling for TLS/SSL
whiskerpickles last edited by
It's not mission critical but it would be nice to see support for this NIST/HIPAA recommended protocol.
d19dotca last edited by d19dotca
@whiskerpickles Good idea. Looks like it's possible already too for Cloudron to support (i.e. supported by Let's Encrypt): https://letsencrypt.org/docs/integration-guide/#implement-ocsp-stapling
By turning on OCSP Stapling, you can improve the performance of your website, provide better privacy protections for your users, and help Let’s Encrypt efficiently serve as many people as possible.
Reading up on this... One thing led to another and I ended up implementing it Should be in next release. Currently, it's enabled for all new certs. I will let it sit for a while to check if causes any issues with various browsers.
Firefox now shows that the cert has OCSP must-staple:
The connection also has the staple information:
Also, verified with openssl s_client -connect hostname:443 -status:
====================================== 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 = R3 Produced At: Apr 16 19:26:00 2021 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: 48DAC9A0FB2BD32D4FF0DE68D2F567B735F9B3C4 Issuer Key Hash: 142EB317B75856CBAE500940E61FAF9D8B14C2C6 Serial Number: 035EAD5077C8953B8AC544660B927A2A37B5 Cert Status: good This Update: Apr 16 19:00:00 2021 GMT Next Update: Apr 23 19:00:00 2021 GMT Signature Algorithm: sha256WithRSAEncryption 5f:2f:9d:67:41:26:c8:9c:53:fd:01:ab:ce:47:83:87:fe:06: 97:7c:4e:16:90:4d:1d:32:6b:8d:9d:19:c8:40:7f:27:5a:d6: 82:8d:a2:af:f2:19:60:7c:d0:d8:90:39:bc:60:cd:9b:b2:64: fb:e2:1c:b1:e5:1c:22:91:a4:75:23:09:cd:85:b4:b4:52:d2: 46:cf:55:d8:f2:a8:57:d3:27:61:a2:99:61:76:d1:a3:05:ae: 4a:d5:3d:c8:97:fe:14:e2:b7:cd:1c:98:2c:c1:dd:1b:78:02: 87:8f:de:da:8d:d5:6b:33:d4:d3:75:a5:ba:6f:1d:54:ee:42: 81:b7:ed:e4:d8:bf:23:c6:b7:30:06:ea:11:c2:88:66:f4:28: a7:43:f2:b8:9c:9f:9e:13:82:07:fb:b4:8e:7f:e7:19:84:8d: 13:2f:f9:9f:9b:f8:1a:7f:04:f2:5c:17:1c:fa:c4:96:28:33: 43:de:ee:c6:68:de:60:49:ea:b2:ad:57:30:fe:df:87:4c:83: c2:a2:07:e4:8b:b9:16:9f:79:61:4e:8f:5c:91:a7:6e:2f:17: ec:93:29:f5:57:96:e3:be:e5:90:80:db:64:dd:2a:22:7a:b0: 9d:3e:95:87:51:96:de:4f:6e:ac:63:ed:55:a4:f2:e0:45:ca: 90:51:50:d1 ======================================
The change is pretty small, if anyone is interested - https://git.cloudron.io/cloudron/box/-/commit/4d919127a73717d43f14e0d90ba2dc46785c16c8 .
Grr, I knew it was too good to be such a simple change. I found that the first visit on firefox (unlike chrome which ignores must-staple) always fails. Investigating, it turns out, nginx does not fetch OCSP responses on reload or restart - https://trac.nginx.org/nginx/ticket/812 . So, one has to prime the OCSP cache using curl requests. Alternately, one can use
openssl ocsp -noverify -no_nonceand then
ssl_stapling_file. Both approaches won't work if the OCSP servers are down and then we have to have some retry logic. Also, the cache is per nginx worker, so I have no clue how many times one has to call curl. The
ssl_stapling_fileapproach requires some refresh logic as well
So, I have changed the code to not enable must-staple in the certificate request. It minimizes the security benefits but we have to wait on nginx to make this properly work.
whiskerpickles last edited by
That's great work @girish - it's not often you step out for the day and return to see your post "solved". I was going to include that it should be a simple nginx config thing but I know better. And it's unfortunate the request caching is a nightmare to enforce "must-staple".
Regardless, the win here is that you have it enabled. That should now be reflected in test reults from Mozilla Observatory (extended to Qualys SSL Labs & ImmuniWeb). Thanks for putting in the grunts on this one.