Failing to download OCSP stapling file on newly renewed certs

Help
1

Today some of my certs renewed, and for the first time they were using the new certificate chain (DST X3 -> ISRG X1 -> R3 -> cert). So far so good, but for some of my certs I like to use OCSP stapling, and some of the new certs failed to download their OCSP stapling file.

I retried a few minutes later and some of the certs now succeeded in getting their OCSP stapling file, but some still failed. In particular, my cert for dmz.lespinasse.org is still failing to download at the moment.

Just posting to report the issue - I can wait a few days for a fix, but I just wanted to make sure the issue is known in the first place (I have not found recent prior reports here). I only have one cert that seems to be stuck without an OCSP cert at the moment, but a couple other certs hit the same issue initially, so I figure this may possibly be a widespread issue ???

To answer the troubleshooting questions list:

My domain is:

lespinasse.org and subdomains - failure was on dmz.lespinasse.org. I have rsa and ecdsa keys for it, and I was able to get an OCSP staple for the ecdsa one, but not for the RSA one so far.

I ran this command:

dehydrated -c

It produced this output:

[...]
Processing dmz.lespinasse.org

  • Using certificate specific config file!
    • OCSP_DAYS = 3
    • OCSP_FETCH = yes
  • Checking domain name(s) of existing cert... unchanged.
  • Checking expire date of existing cert...
  • Valid till Aug 5 23:02:56 2021 GMT (Longer than 30 days). Skipping renew!
  • Updating OCSP stapling file
    ERROR: Error while fetching OCSP information: Responder Error: unauthorized (6)

My web server is (include version):

(not relevant here - dehydrated just generates certs, I install them manually)

The operating system my web server runs on is (include version):

debian 10

My hosting provider, if applicable, is:

N/A

I can login to a root shell on my machine (yes or no, or I don't know):

Sure can

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):

dehydrated version 0.7.0-2~bpo10+1

2

Retrying half an hour later, I was able to get an OCSP staple for my cert, so no issue for me anymore.

I'm still curious to know what happened and wether this affected more than me though.

3

Hi @walken

I use OCSP must staple with *.server-daten.de. Normally, that works.

If the server is rebooted or if the internal test system is restartet, the IIS hasn't a cached answer.

Other browsers ignore that. FireFox has a typical answer:

MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING

Hitting F5 it always works.

So if a webserver is started, the cache is empty, that creates an one-time-error-message. But I don't see if this

is the same problem.

4

Ah, it sounds like your web server knows how to renew the OCSP staple by itself ?

In my use case, the dehydrated client (tries to) download the OCSP staple file, which my scripts then deploy (together with the cert) to the web server. The web server I use knows how to staple the OCSP staple file to the certificate, but doesn't know how to renew it on its own.

5

I can reproduce the OCSP error when I use an invalid intermediate certificate, such as the retired X3 intermediate. When I use the currently active R3 intermediate, it succeeds.

Perhaps dehydrated is/was using an incorrect and hardcoded intermediate for the OCSP request?

6

AFAIK dehydrated leaves the choice of chain up to the certificate provider (with ways to request an alternate chain, but I don't use those). The chain I got was through DST X3 -> ISRG X1 -> R3 -> cert.

7

That's

correct, all ok.

8

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