OCSP Responder Error: unauthorized

I have my certificate in place, it seems to be working and I'm very happy about that.

To that end:
openssl x509 -noout -text -in mycert.pem
produces the following out:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:9c:c6:e3:35:fe:8d:49:15:a2:43:33:40:18:a3:23:fd:7c
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
Validity
Not Before: Sep 1 15:33:31 2020 GMT
Not After : Nov 30 15:33:31 2020 GMT
Subject: CN = my.host.name
.
.
.
Authority Information Access:
OCSP - URI:http://ocsp.int-x3.letsencrypt.org
CA Issuers - URI:http://cert.int-x3.letsencrypt.org/

So far so good....
Now you will note that I'm about one month into the 3 month window... so, this is not a "new" cert.

For no other reson than I'm learning how to check certificate validity (ie: I'm not concerned that my certificate has been revoked)

$ openssl ocsp -issuer chain.pem -cert my.host.name.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: 4E7F741369B25D38BBB6A938CABE9C73A1B2B02A
Serial Number: 039CC6E335FED415A243334018A323FD7C
Request Extensions:
OCSP Nonce:
04103238D6BBDA1C0E8234E895DB8E84033D
Responder Error: unauthorized (6)

I have used the process of building the chain to verify a certificate that uses CRL is valid, so I believe that my chain process works correctly.

Is it me?
Is it http://ocsp.int-x3.letsencrypt.org?

Any thoughts would be welcomed.

Works okay for me for that certificate:

$ openssl ocsp -no_nonce -issuer lets-encrypt-x3-cross-signed.pem -cert e300c7778ce759133b787688cade833571870a6f77e0ad7345ff1566ed6ffa64.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: 039CC6E335FE8D4915A243334018A323FD7C
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: Oct  1 16:35:00 2020 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
      Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
      Serial Number: 039CC6E335FE8D4915A243334018A323FD7C
    Cert Status: good
    This Update: Oct  1 16:00:00 2020 GMT
    Next Update: Oct  8 16:00:00 2020 GMT

    Signature Algorithm: sha256WithRSAEncryption
        50:c7:fc:08:e8:b1:ee:fc:f1:af:a0:6c:eb:0d:09:62:94:c3:
        6f:84:f4:fc:d1:a8:1a:73:63:04:c6:48:b9:23:04:21:27:c4:
        06:82:a6:ca:6c:26:af:b9:2d:22:88:d4:e4:9b:03:88:33:fe:
        ec:24:5a:fc:b9:5a:b6:41:e9:99:eb:f9:dc:ae:d2:00:ad:6c:
        ff:79:f2:2a:5e:9b:5b:9f:07:dc:88:e2:37:64:e9:01:af:6f:
        3a:ad:0d:d5:06:86:c1:33:dd:f1:06:4a:67:7f:91:69:ce:80:
        5d:b6:1d:42:bd:f2:1e:6f:68:eb:7f:9d:64:1d:6c:ec:3c:16:
        b1:9c:3c:cd:6e:f2:1c:f5:18:f5:07:be:8b:2e:77:41:b8:2d:
        78:aa:17:c5:2c:6a:a7:02:86:7a:7e:e5:d7:e1:62:5d:5e:b4:
        a0:98:4d:d6:a6:b2:e9:cc:3f:8b:bc:31:62:e3:f7:41:fd:a1:
        8f:35:21:b7:ca:2e:68:3d:82:25:e5:74:22:39:fd:a3:13:46:
        ea:c3:3d:3f:1d:4b:c4:3b:3a:de:00:91:a8:bb:c1:c7:b2:99:
        16:42:cb:32:b3:fc:ae:18:10:00:17:e3:b2:59:2f:6f:78:f8:
        74:92:2a:be:e5:25:45:30:38:a1:08:78:68:45:5d:1c:d6:6c:
        16:33:c2:91
Response verify OK
e300c7778ce759133b787688cade833571870a6f77e0ad7345ff1566ed6ffa64.pem: good
        This Update: Oct  1 16:00:00 2020 GMT
        Next Update: Oct  8 16:00:00 2020 GMT

Oh, I just noticed that this differs between our requests.

Could you post your chain.pem?

1 Like

This is confusing...
The website shows the correct chain:

Oh, that issuer key hash correlates to the SKI of the leaf certificate

You need to make sure chain.pem contains only the intermediate. If it contains both the leaf and the intermediate, OpenSSL won't understand and will do the wrong thing. Just an annoying thing about the openssl CLI.

3 Likes

An absurd workaround for this case:

You could tell OpenSSL that the certificate file is

<(awk 'x; /END / {x=1}' chain.pem)

instead of

chain.pem

Instead, just follow @_az's advice. :slight_smile:

3 Likes

Ok, it looks like my chain has my leaf node in it too... I'll fix that and try again.
Thanks for the feed back.

1 Like

Did you mention which ACME client you used?

I was unaware that there is more than one option.
How do I distinguish my client from the others...

Is certbot the answer to your question?

If you use certbot, then, yes, that answers that question.
But, yes, there are many ACME clients (and versions); That cover most operating systems.
Can you post the chain.pem file as certbot created it?