> So, I just rebased and updated the OpenSSL patch [0]. Of course the original
> problem that openssl doesn't like non-trusted signer certificates (even if they
> are validated by a certificate in the trust store) persists.
>
> The work-around is to use a special flag OCSP_TRUSTOTHER which basically means
> that we can pass additional certificates to the OCSP verify function which would
> be considered as trusted. This means that no checks at all are performed on
> those certificates. Unfortunately OCSP_TRUSTOTHER doesn't always work for some
> weird OCSP responses (e.g. those from DigiCert/Cloudflare).
>
> The proper solution would be to get openssl fixed of course (other projects such
> as nginx seems to be affected by this as well) but that may take a lot of time.

Could you please elaborate a little bit on the problem and especially what do you mean by „non-trusted signer certificates“?

Which part of RFC 6960 [1] does OpenSSL not implement or violate?
I am especially referring to sections 2.6 and 4.2.2.2. The later states the following:

4.2.2.2. Authorized Responders

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. It is necessary, however, to
   ensure that the entity signing this information is authorized to do
   so. Therefore, a certificate's issuer MUST do one of the following:

   - sign the OCSP responses itself, or

   - explicitly designate this authority to another entity

   OCSP signing delegation SHALL be designated by the inclusion of
   id-kp-OCSPSigning in an extended key usage certificate extension
   included in the OCSP response signer's certificate. This certificate
   MUST be issued directly by the CA that is identified in the request.

   The CA SHOULD use the same issuing key to issue a delegation
   certificate as that used to sign the certificate being checked for
   revocation. Systems relying on OCSP responses MUST recognize a
   delegation certificate as being issued by the CA that issued the
   certificate in question only if the delegation certificate and the
   certificate being checked for revocation were signed by the same key.

   Note: For backwards compatibility with RFC 2560, 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.

   id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

   Systems or applications that rely on OCSP responses MUST be capable
   of detecting and enforcing the use of the id-kp-OCSPSigning value as
   described above. They MAY provide a means of locally configuring one
   or more OCSP signing authorities and specifying the set of CAs for
   which each signing authority is trusted. They MUST reject the
   response if the certificate required to validate the signature on the
   response does not 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-kp-OCSPSigning in an extended key usage
      extension and is issued by the CA that issued the certificate in
      question as stated above.

   Additional acceptance or rejection criteria may apply to either the
   response itself or to the certificate used to validate the signature
   on the response.

—

In short, the criteria 2 and 3 are probably the ones that should be accepted by default, while criteria 1 needs to be configured with a special OCSP responder trust store.

Thanks in advance.

Best regards,
Marc

—
[1] https://tools.ietf.org/html/rfc6960#section-4.2.2.2
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-01-20