On mar, gen 20, 2015 at 12:07:55 +0100, Marc Hörsken wrote:
>
> > 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“?

What I meant was "certificate that isn't directly trusted" ("signer certificate"
being the signer of the OCSP response). That is, a certificate not in the trust
store that needs to be validated (I can see how that wasn't clear...).

Anyway, I've had another look at the OpenSSL code, and it seems I was somewhat
wrong: OpenSSL does try to validate the signer certificate by trying to build a
trust chain, but it does so by using the wrong certificates (what I thought was
that it just expected the signer certificate to be in the trust store).

Essentially, in crypto/ocsp/ocsp_vfy.c in the OCSP_basic_verify() function, the
X509_STORE_CTX_init() function is called like this:

  init_res = X509_STORE_CTX_init(&ctx, st, signer, bs->certs);

where ctx is the X509_STORE_CTX to be initialized, st is the trust store passed
by the user (i.e. libcurl), signer is the signer of the OCSP response (which is
what needs to be validated), and bs is the decoded OCSP basic response.

The problem is the last argument, OpenSSL uses the cert list embedded in the
OCSP response to build the trust chain, but it seems that in some cases this
list is somewhat broken. Other libraries (e.g. GnuTLS), do the verification
differently, without including those bs->certs that OpenSSL uses.

Now, I tried to replace "bs->certs" with "certs" (certs is the stack of
certificates passed by libcurl, which is essentially the cert chain sent by the
server), and indeed the validation works for the sites that were failing.

Not sure if I'm making myself clear, but in any case I'll try to send my patch
upstream and see what happens.

Cheers

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html