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: 'r...@openssl.org' <r...@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:r...@openssl.org] > > Sent: Tuesday, June 21, 2016 3:39 PM > > To: Gábor STEFANIK <gabor.stefa...@nng.com> > > Cc: openssl-dev@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
new.pem
Description: Binary data
old.pem
Description: Binary data
curr.pem
Description: Binary data
hgcentral1.pem
Description: Binary data
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
