Failed OCSP Response with CertHash extension

[machiav3lli]

Describe the Bug

OCSP extensions were dropped at some point 6.0-8.0 (which was noted in #523 ) and seem to be not functioning as expected (or misconfigured?) in the latest docker image 9.3.7.

To Reproduce

Steps to reproduce the behavior:

1. Start an ejbca server in a container
2. Check if the ocsp extension is enabled as wished (see screenshot)
3. Initiate a call from a client that would require a response including OCSP
4. Respond doesn't include the OCSP extension → failed validation

Expected Behavior

The response would return the expected OCSP extension (in this situation it's Certificate Hash).

Screenshots and Logs

Product Deployment

• Deployment format: container
• Version: 9.3.7

Desktop

• OS: Linux 7.0.8
• Browser: Firefox, Chromium
• Version 150.0.3, 148.0

[primetomas]

Is your client requesting the extension?
Can you post the ocsp request and response here? I.e. "openssl ocsp -req_text and -resp_text"

[machiav3lli]

Request-Example:

openssl ocsp -noverify -issuer GEM.FD-CA1.pem -cert FD.KIM.TLS-S-RSA.pem -text -url http://localhost:8084/ejbca/publicweb/status/ocsp

And here's part of the output:

OCSP Request Data:
    Version: 1 (0x0)
    Requestor List:
        Certificate ID:
          Hash Algorithm: sha1
          Issuer Name Hash: 1DECC0EB0D7218BA440AB925B136A7AB2E6302F8
          Issuer Key Hash: 1E1F62D340B0BF6EE29223DDF03710D767E12DC5
          Serial Number: 44AEDC0997300563
    Request Extensions:
        OCSP Nonce:
            041081F0BC8CDAE164CB67AEACEF7AAFA22D
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: 594430A754AD275DF77F3E27D35A8E3B54543B95
    Produced At: May 20 14:56:08 2026 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 1DECC0EB0D7218BA440AB925B136A7AB2E6302F8
      Issuer Key Hash: 1E1F62D340B0BF6EE29223DDF03710D767E12DC5
      Serial Number: 44AEDC0997300563
    Cert Status: unknown
    This Update: May 20 14:56:08 2026 GMT


    Response Extensions:
        OCSP Nonce:
            041081F0BC8CDAE164CB67AEACEF7AAFA22D
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        ba:9b:17:1b:de:af:e8:85:b1:22:a9:76:2a:f7:23:a5:9c:9b:
        16:09:d5:aa:5e:65:95:f2:90:4d:7f:78:aa:49:0a:5a:30:42:
        32:63:04:68:c5:c9:c5:04:76:ea:36:8c:f5:87:d1:ce:31:2b:
        a6:0c:4c:b7:92:51:ae:39:1b:e9:87:74:21:7b:37:8b:11:02:
        bb:7c:4d:88:c8:46:38:7c:72:1a:3b:6a:0b:c1:8e:68:c9:8f:
        84:3b:2e:fc:81:27:67:23:8e:67:4c:aa:89:f1:85:2e:68:91:
        7e:94:7e:32:03:bb:98:6a:02:2f:8b:36:e4:c7:91:8b:60:a6:
        b5:7d:3c:6e:8c:3d:9e:d5:7e:02:74:ce:bb:c1:cc:9b:bb:7e:
        a1:a9:61:cc:ff:f9:ac:42:fb:82:2f:e5:a9:95:98:34:1b:b0:
        4b:55:77:b4:1c:01:13:8b:ee:17:73:5a:25:dc:fc:1c:ed:58:
        9e:34:a2:f8:30:65:fd:4a:87:c0:bf:d4:37:58:cb:4d:b2:85:
        b1:82:f2:44:e4:37:6a:c9:f3:d1:70:07:e1:3f:2d:6e:3a:05:
        81:02:10:93:16:14:09:1e:05:0d:27:d6:2d:fc:8f:78:3e:06:
        55:d6:7a:c6:8d:d8:26:a5:5e:55:f1:4a:c5:f6:f0:f0:ae:cf:
        a5:e5:9f:70
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1293312559625195566 (0x11f2c4ebb402d02e)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=DE, O=drumit e.V NOT-VALID, OU=OCSP-Signer-CA der Drumsinfra, CN=GEM.OCSP-CA1 DEV-ONLY
        Validity
            Not Before: Feb 29 07:52:24 2024 GMT
            Not After : Feb 27 07:52:24 2029 GMT
        Subject: C=DE, O=drumit e.V NOT-VALID, OU=OCSP-Signer-CA der Drumsinfra, CN=GEM.OCSP DEV-ONLY
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ee:95:31:03:f7:b1:4d:37:bb:85:04:8e:60:eb:
                    4d:56:0f:0a:ea:bb:49:d6:5f:0d:6f:96:e6:88:29:
                    fe:ce:d7:03:a2:2e:5a:d6:53:fc:f3:87:40:26:8d:
                    c4:b6:3f:38:8b:45:44:95:c8:fd:da:34:a4:29:31:
                    5b:af:8c:fe:9b:e2:e9:e3:ea:36:c7:31:ae:35:04:
                    80:45:6d:09:2b:2c:00:78:8f:37:e8:50:ee:bc:f7:
                    5a:e5:20:42:17:c4:ab:3b:0c:90:96:d4:86:92:4c:
                    87:6d:bd:f9:b4:d1:19:73:0c:b3:e6:5b:02:ad:80:
                    91:0f:48:96:e6:d5:1c:ec:69:55:19:e9:6b:51:55:
                    49:c1:83:69:f7:dd:c2:69:db:12:18:63:2a:10:8f:
                    1c:08:9a:cc:13:0f:79:dc:4f:7e:64:c5:80:99:c5:
                    26:e5:59:62:d4:1d:24:42:c7:76:69:27:96:a0:25:
                    24:22:18:b4:22:25:e7:fe:43:1b:a7:9d:b7:32:b7:
                    c5:89:af:2e:1d:5a:28:01:8d:1c:6d:c0:bb:36:eb:
                    c6:fc:11:99:1b:7f:49:cf:79:2e:e0:93:58:b6:3f:
                    b6:b2:5c:3c:30:54:56:19:85:9f:e7:eb:cf:24:b1:
                    95:e1:7a:8c:59:af:09:d9:c7:cd:9f:c1:73:e9:3f:
                    8e:85
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier:
                05:28:B2:AB:49:E0:C9:18:EE:92:70:2F:FC:3D:C9:E8:4B:78:77:92
            Authority Information Access:
                OCSP - URI:http://localhost:8084/ejbca/publicweb/status/ocsp
            X509v3 Certificate Policies:
                Policy: 1.2.276.0.76.4.163
                  CPS: http://www.drumit.de/go/policies
            OCSP No Check:


            X509v3 Extended Key Usage:
                OCSP Signing
            X509v3 Subject Key Identifier:
                59:44:30:A7:54:AD:27:5D:F7:7F:3E:27:D3:5A:8E:3B:54:54:3B:95
            X509v3 Key Usage: critical
                Non Repudiation
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        bc:0b:78:99:d3:d8:48:d5:0f:51:e8:1b:1e:48:7a:8a:fb:ca:
        85:9d:ce:88:97:77:c2:39:b0:2c:b0:4d:04:82:00:8d:4d:c6:
        4f:e9:0a:e5:4e:aa:c5:8a:dd:ad:be:ef:f1:81:e6:4c:92:44:
        c1:e3:7e:55:d9:72:5d:0d:90:8c:ad:88:6c:d1:94:e6:72:f1:
        1c:d1:8e:f0:96:8c:2d:27:e1:2c:36:ff:e0:ff:e2:dd:b6:2a:
        0a:72:36:c0:14:62:d9:9c:bd:bb:bc:15:4a:f9:a2:a9:ab:d8:
        da:26:a2:e6:52:9a:94:6e:2c:d3:82:1f:88:80:0a:1f:f8:31:
        25:3c:8b:d4:20:84:58:11:6c:e5:66:4d:33:7a:b7:1c:bf:da:
        08:30:00:ef:e4:47:e7:eb:ff:dc:6c:81:e0:c4:cf:86:83:ea:
        4b:e3:7c:95:65:29:09:c4:56:05:a5:3f:e5:3a:67:7f:33:ca:
        ba:c2:cb:d7:ea:2f:cb:5d:a8:46:1d:da:83:d3:5b:2e:da:29:
        98:d1:0a:28:25:f0:8a:1c:f3:8b:fd:f9:8f:3e:14:e7:17:78:
        09:d0:7d:c6:d3:6f:38:5a:e4:8b:c3:0e:2b:78:5a:1a:81:a3:
        48:42:b1:fb:43:80:dd:1a:65:0d:19:dc:a2:8b:fa:a7:a4:67:
        15:1c:09:45
-----BEGIN CERTIFICATE-----
XXXX
-----END CERTIFICATE-----

[primetomas]

The response Cert Status is unknown.
"Each OCSP response given for SigG-conforming signature certificates MUST contain such a positive
statement in form of the CertHash extension."

CertHash is for positive proof of issuance. If the cert is unknown to the responder, there is no known certificate issued and hence a proof of issuance would be faulty (and technically there is no certificate for which the hash can be calculated).

[machiav3lli]

And this is actually part of the issue. Till now (as we were still using v6.0), these specific certificates (which were updated regularly and are downloaded from the EJCBA web UI - which should means they are practically known by the responder) resulted successful calls i.e. a correct OCSP responses including CertHash.

As mentioned above, we tried to migrate around 2024 to v8.0, where we noticed the showstopper/regression (see #523 ), we assumed now as years passed since then that the regression was fixed but it seems there could be a bigger underling issue.

So looking at the symptoms/results, we can assume one of two things (or even maybe both):

• either the regression wasn't functionally fixed rather only visually semi-fixed (notice the differences below)
• or there's a bug resulting "corrupted"/incorrect responses

View under v6.X

View under v9.X

Edit under v9.X

[primetomas]

#523 doesn't look relevant in this case as you are using a dedicated OCSP signer and are not signing the response directly with the CA. That issue was only related to direct OCSP signing by the CA, not a dedicated OCSP responder.

I am assuming this is for a PKI under the German digital signature law, as CertHash is only used in this context, right?

[machiav3lli]

Right.

[primetomas]

Perhaps I could temp you with an Enterprise SLA in that case?

Log files should show in detail what happens when a query comes in and the certificate is looked up.

[machiav3lli]

To be honest, we're using EJBCA as a fake/mock-server in order to test our implementations against requirements that the other parties involved in the project develop on their side. The issue was reported, as the update to v9 resulted our internal tests failing but the project-wide ones went well So I'm not sure to what extent I'd be able to convince involved people that another SLA would solve the regression…

[primetomas]

Sure that makes sense. I checked, and we do have an automatic regression test for CertHash, so the functionality is working in our test case. In your case, the issue doesn't seem to be CertHash, but that the certificate is considered "unknown". If the certificate is in the database, issued by the correct CA, it is this issue you have, that it can not find the certificate.

Looking at a debug log in server.log should give you detailed information what is happening when it looks up the certificate to respond for.

[primetomas]

Converted to discussion as server logs have to be analyzed to see if it is a code issue or not.