Embedding OCSP certificate status in PDF signature: not working when the OCSP responderCert != issuerCert

Question

In order to sign a PDF i use signDetached.

... 
OcspClient ocspClient = new OcspClientBouncyCastle();
MakeSignature.signDetached(appearance, digest, pks, chain, crlList, ocspClient, tsaClient, estimatedSize, subfilter);

The PDF is signed without errors, nevertheless the embedded OCSP response is missing:

• The OCSP server works properly, but
• The CA i'm using signs OCSP responses with a trusted responderCert (different from the issuerCert).

How could i force signDetached to embed the OCSP status without verifing the OCSP response (or pass to signDetached the responderCert to trust) ?

---

Moreover

when I try to verify the OCSP status via com.itextpdf.text.pdf.security.OCSPVerifier verify i get the error:

Java::JavaSecurity::SignatureException: certificate does not verify with supplied key 

---

In this case we use the Swiss Government CA:

Swiss Government Root CA I
`- Swiss Government Enhanced CA 01 < issuer certificate 
   `- Mor... < signature certificate

The OCSP responses are signed by :

Swiss Government Root CA II
`- Swiss Government SSL CA 01 
   `- Swiss Government OCSP < OCSP responderCert

Root and intermediate certificates are available here:

• https://www.bit.admin.ch/adminpki/00247/00790/index.html?lang=de (SG Root CA I)
• https://www.bit.admin.ch/adminpki/00247/05329/index.html?lang=de (SG Root CA II)

Answer 1

... nevertheless the embedded OCSP response is missing ...

Inspecting the sample PDF one can clearly see that the OCSP response is embedded:

 6469  3174:             SEQUENCE {
 6473     9:               OBJECT IDENTIFIER '1 2 840 113583 1 1 8'
 6484  3159:               SET {
 6488  3155:                 SEQUENCE {
 6492   791:                   [0] {
 6496   787:                     SEQUENCE {
 6500   783:                       SEQUENCE {
 .... CRL for CA certificate ....
           :                         }
           :                       }
           :                     }
 7287  2356:                   [1] {
 7291  2352:                     SEQUENCE {
 7295  2348:                       SEQUENCE {
 7299     1:                         ENUMERATED 0
 7302  2341:                         [0] {
 7306  2337:                           SEQUENCE {
 7310     9:                             OBJECT IDENTIFIER
           :                               ocspBasic (1 3 6 1 5 5 7 48 1 1)
 7321  2322:                             OCTET STRING, encapsulates {
 7325  2318:                               SEQUENCE {
 7329   270:                                 SEQUENCE {
 7333    97:                                   [1] {
 7335    95:                                     SEQUENCE {
 7337    11:                                       SET {
 7339     9:                                         SEQUENCE {
 7341     3:                                           OBJECT IDENTIFIER
           :                                             countryName (2 5 4 6)
 7346     2:                                           PrintableString 'CH'
           :                                           }
           :                                         }
 7350    29:                                       SET {
 7352    27:                                         SEQUENCE {
 7354     3:                                           OBJECT IDENTIFIER
           :                                             organizationName (2 5 4 10)
 7359    20:                                           UTF8String 'Swiss Government PKI'
           :                                           }
           :                                         }
 7381    17:                                       SET {
 7383    15:                                         SEQUENCE {
 7385     3:                                           OBJECT IDENTIFIER
           :                                             organizationalUnitName (2 5 4 11)
 7390     8:                                           UTF8String 'Services'
           :                                           }
           :                                         }
 7400    30:                                       SET {
 7402    28:                                         SEQUENCE {
 7404     3:                                           OBJECT IDENTIFIER
           :                                             commonName (2 5 4 3)
 7409    21:                                           UTF8String 'Swiss Government OCSP'
           :                                           }
           :                                         }
           :                                       }
           :                                     }
 .... remainder of OCSP response for signer certificate
           :                         }
           :                       }
           :                     }

Thus to answer the question:

How could i force signDetached to embed the OCSP status without verifing the OCSP response (or pass to signDetached the responderCert to trust)?

There is no need to force, iText does embed the retrieved OCSP response without further checks (a quick code review supports this).

But it still is no surprise you are getting into trouble with that Swiss Government CA and their certificate structure.

According to RFC 2560 (which is explicitly referenced from the PDF specification ISO 32000-1 and, therefore, has to be used here in spite of it been obsoleted by RFC 6960):

Systems or applications that rely on OCSP responses ... MUST reject the response if the certificate required to validate the signature on the response fails to meet at least one of the following criteria:

1. Matches a local configuration of OCSP signing authority for the certificate in question; or

2. Is the certificate of the CA that issued the certificate in question; or

3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage extension and is issued by the CA that issued the certificate in question."

For Swiss Government CA signatures this means:

1. In generic environments you usually have no specific local configurations for Swiss government signatures.
2. The OCSP responder certificate is not the certificate that issued the signer certificate.
3. While the EKU value is present there is no generic way to verify that OCSP certificate and signer certificate were issued by the same CA as their certificate chains are unrelated.

So generally those OCSP responses MUST be rejected.

And if you also look at the newer RFC 6960 you'll see:

Note: For backwards compatibility with RFC 2560 [RFC2560], it is not prohibited to issue a certificate for an Authorized Responder using a different issuing key than the key used to issue the certificate being checked for revocation. However, such a practice is strongly discouraged, since clients are not required to recognize a responder with such a certificate as an Authorized Responder.

So nowadays the certificate structure used by the Swiss Government CA even is explicitly strongly discouraged (which essentially means that the IETF would have forbidden it if they had been able/allowed to).