The Certificate Manager in Windows does allow you to change the trust settings for root certs (including the purposes reported by openssl x509 -purpose), although those changes don't appear to be reflected in the cert dumped from the store (so they must be stored externally).
I think the original concern could have been one of two things (or possibly both): 1) assuming the cert itself has purpose information, that needs to be reflected in its use after being added to the cert store (I assume the verification code is already checking this if it's a property of the cert), or 2) that a user's choice to (un-)trust certain certificates is respected, however unusual. I'm not aware of any facility on Linux to modify the trust status of certs, so I think this is an issue unique to Windows. -Matt Stickney On Sun, Jul 9, 2017 at 7:08 AM, Kurt Roeckx <k...@roeckx.be> wrote: > On Sun, Jul 09, 2017 at 09:15:32AM +0200, Richard Levitte wrote: >> In message >> <CAKH_Ld4faVY8v9RY=odfzzukht7apqz5mv_qmsbggydhheb...@mail.gmail.com> on Sat, >> 8 Jul 2017 23:22:28 -0400, Matthew Stickney <mtstick...@gmail.com> said: >> >> mtstickney> Back in 2010, there was some discussion on this list of adding >> code to >> mtstickney> load certificates from the system cert store on Windows by >> default, >> mtstickney> since the default verification paths typically don't point to >> anything >> mtstickney> (this was ticket #2158, which was ultimately rejected). I have >> some >> mtstickney> interest in picking up where this was left off, but I'm a little >> out >> mtstickney> of my depth and have some questions. >> mtstickney> >> mtstickney> Last time around, the sticking point was certificate purposes: we >> mtstickney> don't want to add a certificate that's only trusted for client >> mtstickney> authentication as trusted for server authentication. I still >> need to >> mtstickney> figure out how to extract purposes from the windows certs, but >> I'm >> mtstickney> also having a hard time seeing how you'd set x509 purposes in >> openssl. >> mtstickney> Where should I be looking? >> >> I'm don't know the Windows cert API enough to know if there are >> purpose settings outside of the cert itself, so I won't be able to >> answer that. >> >> However, in the cert itself, there may be an extension called Extended >> Key Usage. Have a look at RFC 5280, 4.2.1.12 [0] for more info on >> them. You set them like any other extension, when creating a cert. > > I think the point is that he wants to have additional contraints > on the root certificate that aren't in the X509 certificate > itself. The root certificate mostly don't have an EKU. > > I would like to say that on Linux most people will also not have > such additinal restrictions even if the root store provides such > restrictions. > > OpenSSL allows you to set some restrictions with "trusted > certificates", which are in a X509_AUX structure. See the x509 man > page. > > > Kurt > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
