Hi, On 02-03-17 22:26, Gert Doering wrote: > On Thu, Mar 02, 2017 at 09:36:32PM +0100, Steffan Karger wrote: >> So, what I propose instead is: >> * remove all the nsCertType code (except the option in add_option()) >> * update the help strings and man page to indicate that --ns-cert-type >> is no longer supported and --remote-cert-tls should be used instead >> * in add_option(), if the option is enabled in a config file, act as if >> --remote-cert-tls was specified correspondingly, and print a clear >> warning that --ns-cert-type is no longer supported and stricter checks >> are enabled instead. > > Mmmmh. Is there a way to get the old behaviour with OpenSSL 1.1? > > We decided that we do want 1.1 compatibility in release/2.4, but what > you propose might break people's working config when upgrading from 2.4.1 > to 2.4.2 - bad enough if we make mistakes, but if there is an alternative > to consciously changing cert validation behaviour in the middle of a > release train, we should look again...
So I looked again, and there really seems to be no way to get the old behaviour with OpenSSL 1.1. However, the exact behaviour of X509_check_purpose() is not as strict as I initially thought. The current patch basically adds the following checks: * if the cert has key usage set, it must be correct * if the cert has extended key usage set, it must be correct * if the cert has the CA flag set, it must be done correctly These are fairly low-risk. I'd expect quite some issues if we would reject certs *without* (extended) key usage set, but if (e)ku is set, this will most likely be done correctly. Or in other words, we might reject weird certificates, but not proper certificates. All in all, I think the original patch (after fixing const correctness) is fine. As a last resort, we could consider keeping the old code inside #if OSSL_VER < 1.1.0 in release/2.4, but that might just create more confusion... -Steffan ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
