OCSP responses inconsistent between different OCSP Servers

Help
1

at this moment not just the certificate issuance service are distrupted, but also the OCSP server responses are inconsistent. for the same certificate some returns OK, others return Unaothorized(6)

Of course this creates problems for domains with certificate issued with Must-staple.

2

Same problem here, started at about 4.30am UTC

OCSP response not successful (6: unauthorized) while requesting certificate status, responder: ocsp.int-x3.letsencrypt.org

3

Server software for OCSP should (but alas many Unix servers do not) behave roughly as follows:

  • Try to get an OCSP GOOD response, and serve that up to clients, renewing it periodically so that on the one hand they don’t make too many unnecessary requests for a fresh response but on the other hand they don’t allow the response to expire, e.g. asking roughly half way between now and the expiry time for a new response makes sense.
  • Cache the response even over a restart, you don’t need five fresh OCSP responses just because the user restarted the HTTP daemon five times.
  • Don’t treat OCSP BAD responses as useful. If there isn’t a GOOD response, log what was in the response and send nothing at all to clients until you retry, say, after 5 minutes and get a GOOD.

We need more pushback from server operators to tell Apache in particular that “You can sort of get it working how it should if you fiddle about with the configuration” isn’t good enough. OCSP stapling should need at most one configuration setting to switch it on and should then work properly out of the box.

1 Like
4

The issue, now is that the OCSP server’s IP keeps changing for: ocsp.int-x3.letsencrypt.org, and neither server behind of the actual IP’s can answer correctly to the OCSP request for all of my certificates !!!. If I force (via hosts) an IP which I seen at the morning that can answer correctly to the OCSP request for a part of the certificates, other OCSP servers behind ocsp.int-x3.letsencrypt.org maybe has the good answer for other certificates, but apparently neither of them has the good answer for all of my certificates.
This is clearly a server side issue and I don’t think it is an issue with the OCSP Signing client, which is configured to cache only the good answer via external memcahce, so the good answer survives the daemon restart.
“send nothing at all to clients until you retry” here is the issue with the Must-staple

5

Same here starting about 7:44 GMT+1 . As a workaround I use this script to get a good response in to a file and use it whit ssl_stapling_file directive in nginx. The script is only part of the script posted by @Troon here

Script

#!/bin/sh
SITE=$1
LEDIR=/etc/letsencrypt/live
DIR=$LEDIR/$SITE
HOST=ocsp.int-x3.letsencrypt.org
MTO=my-email@example.com

openssl ocsp -no_nonce \
             -respout      $DIR/ocsp.resp.new \
             -issuer       $DIR/chain.pem \
             -verify_other $DIR/chain.pem \
             -cert         $DIR/cert.pem \
             -url http://$HOST/ \
             -header "HOST" "$HOST" > $DIR/ocsp-reply.txt 2>&1

if grep -q ": good" $DIR/ocsp-reply.txt; then
    if cmp -s $DIR/ocsp.resp.new $DIR/ocsp.resp; then
        rm $DIR/ocsp.resp.new
    fi
fi
6

Am I missing something in this script, or does it not update ocsp.resp with new GOOD answers ?

7

Yes, is only part of the full script. If you see the full script you can see that if response changes, the file for stapled response is changed too.
I used this part to play with it, and found that if the --issuer cert file is fullchain.pem, I get the non authorized response.

The full explanation to use these script permanently, with cron job and nginx restart is in the @Troon post I have linked before,

8

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