[openssl-dev] [openssl.org #4580] "openssl verify -CAfile cacerts.pem cert.pem" fails if cacerts.pem is ordered in certain ways

[Gábor STEFANIK via RT]

I've attached the certificates that we originally encountered the bug with.

"old.pem" is our old root CA certificate that expired in 2012.
"curr.pem" is our current root CA, with the same public key as "old.pem". It is valid till 2017.
"new.pem" is the new root CA recently released by our IT department. It has a new public key.
"hgcentral1.pem" is the site certificate signed directly using "curr.pem".

Verifying hgcentral.pem using curr.pem works, all others fail as expected.
However, when I concatenate old.pem, new.pem and curr.pem in various orders, I get inconsistent behavior:
old+curr PASS
curr+old FAIL
curr+new PASS
new+curr PASS
old+curr+new FAIL
old+new+curr FAIL
curr+old+new PASS
curr+new+old PASS
new+old+curr PASS
new+curr+old FAIL

There doesn't seem to be much of a pattern: curr+old fails, but curr+old+new works, even though new has a different public key and thus has no role in the verification. Also, old+curr+new and old+new+curr fail, despite "curr" following "old", which works when "new" isn't included.

I also have a variant where a trust store of 20 certificates, none of them expired, but some with identical keys, containing the correct CA, is rejected when loaded through Python in DER format using the "cadata" parameter, but not when loaded in PEM format using "cafile". I'm still trying to reproduce this using standalone openssl, without python.


>


--------------------------------------------------------------------------
This message, including its attachments, is confidential. For more information please read NNG's email policy here:
http://www.nng.com/emailpolicy/
By responding to this email you accept the email policy.


-----Original Message-----
> From: Gábor STEFANIK
> Sent: Tuesday, June 21, 2016 4:11 PM
> To: 'rt at openssl.org' <rt at openssl.org>
> Subject: RE: [openssl-dev] [openssl.org #4580] "openssl verify -CAfile
> cacerts.pem cert.pem" fails if cacerts.pem is ordered in certain ways
>
> Looks like I was wrong, the 2 internal certificates that reproduce the issue do
> in fact share the key (only a 3rd, even newer certificate has a different key).
> So, key reuse is an essential part of this problem - however, I can now
> reproduce it with a trust store containing no expired certificates.
>
> Testcase coming soon, I got the OK from our IT department.
>
> > -----Original Message-----
> > From: Salz, Rich via RT [mailto:rt at openssl.org]
> > Sent: Tuesday, June 21, 2016 3:39 PM
> > To: Gábor STEFANIK <Gabor.STEFANIK at nng.com>
> > Cc: openssl-dev at openssl.org
> > Subject: RE: [openssl-dev] [openssl.org #4580] "openssl verify -CAfile
> > cacerts.pem cert.pem" fails if cacerts.pem is ordered in certain ways
> >
> > Yes, it should not crash.  But without more information it is
> > hard/impossible to debug.
> >
> >
> > --
> > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4580
> > Please log in as guest with password guest if prompted


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4580
Please log in as guest with password guest if prompted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: new.pem
Type: application/octet-stream
Size: 1646 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160622/fa266ddf/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: old.pem
Type: application/octet-stream
Size: 1604 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160622/fa266ddf/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: curr.pem
Type: application/octet-stream
Size: 1640 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160622/fa266ddf/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hgcentral1.pem
Type: application/octet-stream
Size: 2024 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160622/fa266ddf/attachment-0003.obj>