On Thu, Jul 25, 2013, Marios Makassikis wrote:
> On 26 June 2013 18:44, Viktor Dukhovni <openssl-us...@dukhovni.org> wrote:
> > On Wed, Jun 26, 2013 at 05:29:52PM +0200, Marios Makassikis wrote:
> >
> >> >> By enabling debug information in the program, I was able to obtain
> >> >> these error messages:
> >> >>
> >> >> pppd[2236]: EAP-TLS SSL error stack:
> >> >> pppd[2236]: error:0D0C5006:asn1 encoding
> >> >> routines:ASN1_item_verify:EVP lib
> >> >>
> >> >> and
> >> >>
> >> >> err: 7 (certificate signature failure)
> >
> > The error "certificate signature failure" happens only when the
> > public key of an issuer certificate in the chain does not generate
> > a matching signature for its child certificate. Either the trust
> > store (CAfile, CApath, ...) certificates are not identical in the
> > two test cases, or one of the two parties sends a different chain,
> > or the handshake is somehow corrupted.
> >
> > crypto/x509/x509_vfy.c:
> > internal_verify():
> > ...
> > else if (X509_verify(xs,pkey) <= 0)
> > {
> > ctx->error=X509_V_ERR_CERT_SIGNATURE_FAILURE;
> >
> > Look closely with wireshark at the chains captured on the machine
> > where the error is detected. Are the peer certificate chains the
> > same in every detail between the two library versions?
> >
> > Are both cases using compression? Any other differences?
> >
>
> I meant to reply to this earlier but I got busy with other stuff. Anyhow, I
> took some time and redid some tests:
>
> - ppp with EAP-TLS patch compiled with libssl 0.9.8o-4squeeze14 works ok
> (I had some surprises with CRL handling, but that's besides the point
> right now)
>
> - ppp with EAP-TLS patch compiled with libssl 1.0.1e-2 exhibits the same
> behaviour I originally described, i.e.: server fails to validate
> signature and sends an alert message to the client.
>
> I tried two scenarios:
> a) one root CA, generates two intermediate CAs. The first intermediate CA
> is used to generate a certificate for the server, and the second CA
> generates certificates for clients.
> b) one root CA, used to generate two certificates (1 for the server and 1
> for the client).
>
>
> In both cases, only the server validates the client cert. Additionally, I made
> sure to use large key sizes (2048 bits) and SHA1 as the algorithm to use for
> message digests as MD5 is broken.
>
> I noticed that the error occurs if one of the two peers is using the binary
> linked with libssl 1.0.1.
>
Well that error is caused by a certificate chain verification failure. In
particular the signature verification of a certificate using the key in it's
issuer.
Possibly cause of that is a failure of the cryptographic algorithm (OpenSSL
bug or compiler bug) or for some reason OpenSSL isn't using the correct
certificate to verify the signature.
>
>
> Server capture with libssl0.9.8: http://pastebin.com/ndeakdnK
> Server capture with libssl1.0.1: http://pastebin.com/dVNy1fQv
> Client capture with libssl0.9.8: http://pastebin.com/z9fbA7DN
> Client capture with libssl1.0.1: http://pastebin.com/dVNy1fQv
>
>
> I can share the certs & ca files also if needed.
>
OpenSSL (among other things) does this when verifying the certificate chain:
openssl verify -CAfile root.pem -untrusted allcerts.pem ee.pem
where "allcerts.pem" is the complete peer chain and "ee.pem" is the peer
certificate. I'd be interested to see what that commands produces for
different version. If you use a directory and use -CApath instead.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
