pierky / haproxy-ocsp-stapling-updater Goto Github PK

The current version of hapos-upd work fine for my existing Let's Encrypt Certs, but I re-issued a certificate with the OCSP Must Staple extension today and OCSP updates consinstenly fail with Responder Error: unauthorized (6) unless I remove the -no_nonce switch from the script.

I suggest to either completely drop the -no_nonce flag from the script or add an option to enable or disable OCSP request nonces.

I can certianly come up with a PR if I know what direction to go in.

Update: Turns out the error was related to a bad cache in the Let's Encrypt OCSP responder that could be worked around by requesting with a nonce. See diskussion below for details.

Hi,

I'm using the script to try to verify a wildcard certificate, but it gives me a (unhelpful) error:

$ sudo /usr/bin/find /etc/haproxy/ssl -name '*.pem' -exec /usr/local/sbin/hapos-upd --cert {} --debug --VAfile - \;
Temporary directory: /tmp/hapos-upd.zRNokKAnXZ
OCSP server URL found: http://ocsp.comodoca.com
OCSP server hostname: ocsp.comodoca.com
Extracting chain from certificates bundle
EE certificate's fingerprint: SHA1 Fingerprint=13:27:59:E5:1C:1E:8C:C2:60:20:EA:4B:A7:79:D2:9C:81:14:56:14
4 certificates found in the bundle
Bundle certificate n. 1 fingerprint: SHA1 Fingerprint=13:27:59:E5:1C:1E:8C:C2:60:20:EA:4B:A7:79:D2:9C:81:14:56:14 - EE certificate
Bundle certificate n. 2 fingerprint: SHA1 Fingerprint=02:FA:F3:E2:91:43:54:68:60:78:57:69:4D:F5:E4:5B:68:85:18:68 - it's part of the chain
Bundle certificate n. 3 fingerprint: SHA1 Fingerprint=F5:AD:0B:CC:1A:D5:6C:D1:50:72:5B:1C:86:6C:30:AD:92:EF:21:B0 - it's part of the chain
Bundle certificate n. 4 fingerprint: SHA1 Fingerprint=33:9C:DD:57:CF:D5:B1:41:16:9B:61:5F:F3:14:28:78:2D:1D:A6:39 - it's part of the chain
OCSP response verification results: 
Error processing '/etc/haproxy/ssl/193.67.138.64/wildcard.customer.tld_haproxy.pem': OCSP response verification failure.

(Obfuscated customer name, as I don't think it's important. I'm aware the fingerprint would give it away, but at least a simple search would not.)

When I visit the site with SSL Pulse, it tells me the OCSP response from upstream is fine. So I'm assuming the script is expecting something I'm not providing. Could you let me know where I would need to look for solving this? Thanks in advance!

I'm only vaguely familiar with the OCSP stapling process, but its not clear to me -- since this sets a run time value... if we run the updater each time we restart haproxy or each time we update the cert?

thanks in advance -- and very much appreciated you writing this!

While trying to use this script with Lesencrypt I didn't successfully verify the certificate.

After adding -verify_other $TMP/chain.php to the ocsp command, I get a valid ocsp stable.

I'm running this with the openssl provided by CentOS 7 and certificates provided by certbot (https://certbot.eff.org/) which is used to get https://letsencrypt.org/ certificates.

My haproxy certificate bundle file works okay with HAproxy. My chain only has the intermediate certificate in it, not the root CA. However, I'm pretty sure that's how it is supposed to be. When hapos-upd tries to verify my certificate chain with the line:

It fails because it can't find a root trust anchor. The Let's Encrypt intermediate certificate is cross-signed by a different CA. That CA is in my globally trusted CA file. So, if I use -untrusted instead of -CAfile for the chain:
$OPENSSL_BIN verify $PARTIAL_CHAIN -untrusted $TMP/chain.pem $TMP/ee.pem &>>$TMP/log

That causes openssl to check the system CA file to find the root trust anchor that signs the
intermediate certificate in chain.pem. Verification then succeeds for my end entity certificate.

certbot has become pretty popular, so I'm guessing many other people trying to use Let's Encrypt certificates will run into the same issue I did. However, I'm not sure what the best way to go about providing a fix for this would be or else I would provide a pull request. I'm thinking maybe adding a switch to tell hapos-upd to use the untrusted switch instead of the CAfile switch for the chain file might be the right approach.

Any thoughts?

See #6.

In an environment where nbproc > 1, when updating by 'socat' it updates a random proc and will not update all the haproxy processes that are currently running.
To resolve that and provide better visibility to haproxy, it is recommended to setup multi sockets and attach each socket to a uniq process.

When updating haproxy with a new OCSP response, it is required to update all sockets.
Can this be fixed to support multi admin sockets?