> On Jan 22, 2018, at 10:15 PM, Jeffrey Walton <noloader@xxxxxxxxx> wrote: > >> I am sorry to hear that you're saddened by my lack of fealty to >> RFC5280, but I find real-world considerations more compelling. >> The OP in this thread has perfectly reasonable work-arounds, >> the main obstacle seems to be a language barrier more than >> anything else. > > Yeah, the real world decision just decision just derailed the use of > crypto, not improve upon it. > > I've seen this so many times in the past. It is the result of allowing > engineers drive requirements. For the record: The only change in OpenSSL 1.1.0 is that the EKU-based policy that oddly applied only to untrusted certificates in 1.0.2 and earlier now applies consistently whether the certificate comes from the trust store or the remote peer. I can demonstrate the issue with the OP's chain when only the root CA is in the trust store: $ openssl verify -CAfile ca2.pem -untrusted ca1.pem -purpose sslclient SEP64A0E714844E-L1.pem SEP64A0E714844E-L1.pem: C = DE, ST = Sachsen, L = Leipzig, O = DBFZ Deutsches Biomasseforschungszentrum gGmbH, OU = IT, CN = CAPF-91d43ef6 error 26 at 1 depth lookup:unsupported certificate purpose The "ca1.pem" file is the OP's intermediate CA, and the "ca2.pem" file is the OP's root CA. Repeating the same test with the purpose changed to "sslserver" works as expected: $ openssl verify -CAfile ca2.pem -untrusted ca1.pem -purpose sslserver SEP64A0E714844E-L1.pem SEP64A0E714844E-L1.pem: OK The only change in 1.1.0 is fixing a bug that resulted in inconsistent handling of intermediate CAs depending on whether they were processed from the list provided by the peer or from the trust store. Restricting CA purpose based on EKU dates back to before 1.0.0. You may not care, but others may find this information useful. Really over and out this time... -- -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
