Re: Can't disable "Trusted" for Certificates Issued by MS Certificate Server
From: Sergio Dutra [MS] (sergiod_at_online.microsoft.com)
Date: 10/30/03
- Next message: Anthony Hunter: "AcceptSecurityContext problem on WinXP"
- Previous message: msnews.microsoft.com: "Re: Help with new dwInfoStatus values"
- In reply to: Ohaya: "Re: Can't disable "Trusted" for Certificates Issued by MS Certificate Server"
- Next in thread: Ohaya: "Re: Can't disable "Trusted" for Certificates Issued by MS Certificate Server"
- Reply: Ohaya: "Re: Can't disable "Trusted" for Certificates Issued by MS Certificate Server"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 30 Oct 2003 11:21:48 -0800
Could you specify how you generated the Root CA and SSL server certificates
(enough details so I can reproduce it)?
The list you specify for the root CA, is that from the Details pane or the
General pane of the certificate UI?
Also, are you attempting to perform client authentication from the same
machine as the root CA? If so, the root CA may have a copy in another store
(usually, "MY" store), and that copy may not have a property restricting the
usages, so that IE would pick the SSL certificate issued by that root.
-- This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm "Ohaya" <ohaya@NO_SPAM.cox.net> wrote in message news:3FA142DC.4DFC1230@NO_SPAM.cox.net... > Sergio, > > Sorry, I messed up typing out the list of Extended Key Usage (the cert > is on a different machine than I use to post, so I had to manually key > everything into the post). The list should have been: > > File Recover > Digital Rights > Smart Card Logon > License Server Verification > Key Pack Licenses > Embedded Windows System... > OEM Windows... > Windows System Component Verification > Windows Hardware Driver Verification > Encrypting File System > IP Security User > IP Security tunnel termination > IP Security end system > Microsoft Time Stamping > Microsoft Trust List Signing > Time Stamping > Secure email > Code Signing > Client Authentication > Server Authentication > > > And, yes, I can confirm that that list was from the root certificate > used for MS Certificate Server. > > So, I think that, based on what you described below, I should be able to > control whether this CA gets sent out by IIS in the SSL > CertificateRequest message by enabling/disabling the "Client > Authentication" purpose in the root CA cert, but as I indicated, this > does not seem to be working. > > IIS is including this CA name in the CertificateRequest regardless of > the setting of the "Client Authentication" purpose in the Certificate > Server/root CA certificate, and as I've indicated in a previous post, > I've confirmed this using OpenSSL's s_client. > > One thing that I noticed when testing with OpenSSL s_client is that if > the "Client Authentication" purpose is disabled, the MS Certificate > Server CA name is always the first in the list of CAs that IIS sends in > the CertificateRequest message. > > I'm thinking that this "bug" is related to some kind of indexing problem > in either IIS or maybe in CryptoAPI when it enumerates the CAs from the > Trusted Root store. In other words, maybe since my MS Certificate > Server's root CA cert is #0, there's a bug in either IIS or CryptoAPI > where it's skipping the checking of the "Client Authentication" purpose. > > As I've also posted, I've sent an email to MS, and posted on the website > as a possible bug, but I haven't heard anything back (I didn't expect > that anyway :)), so I hope that since you're with MS, you might bring > this up to the appropriate people. > > If someone was malicious, and depending on how you look at it, this > could be regarded as a semi-serious security vulnerability, akin to a > "hijacking a CA" exploit. > > > > > > "Sergio Dutra [MS]" wrote: > > > > The way certificate properties work is by restricting the usages allowed by > > the certificate. Hence, for a certificate that has no EKU extension (meaning > > it's good for anything) or for a certificate that has multiple usages > > (including Client Auth) specified in the EKU extension, enabling the Client > > Auth property restricts the certificate to being good only for client > > authentication. > > > > If the certificate does have the EKU extension but it does not have the > > Client Auth usage, enabling the Client Auth property makes the certificate > > valid for nothing, since the intersection of the EKU extension usages and > > the property usages is nil. > > > > Typically, the EKU property is set on the root certificate and not on end > > certificates. I assume that the MS Certificate Server cert you listed the > > usages for is the root certificate, and not the end certificate issued by it > > that is actually used by SSL. > > > > In your case, the MS Certificate Server CA cert does seem to have the EKU > > extension and it has several usages in it, but I do not see the Client Auth > > usage in the list below. If this is the case, then you should not be able to > > enable the Client Auth property since the certificate does not contain that > > usage already. > > -- > > This posting is provided "AS IS" with no warranties, and confers no rights. > > Use of included script samples are subject to the terms specified at > > http://www.microsoft.com/info/cpyright.htm > > "Ohaya" <ohaya@cox.net> wrote in message news:3F9EAE9A.4C769D45@cox.net... > > > Sergio, > > > > > > There are no intermediate CAs or intermediate CA certs for the MS > > > Certificate Server CA chain. MS Certificate Server was installed with > > > all the normal defaults. > > > > > > When I look at the MS Certificate Server CA cert under Details->Enhanced > > > Key Usage extension, it lists: > > > > > > File Recover > > > Digital Rights > > > Smart Card Logon > > > License Server Verification > > > Key Pack Licenses > > > Embedded Windows System... > > > OEM Windows... > > > Windows System Component Verification > > > Windows Hardware Driver Verification > > > Encrypting File System > > > IP Security User > > > IP Security tunnel termination > > > IP Security end system > > > Microsoft Time Stamping > > > Microsoft Trust List Signing > > > Time Stamping > > > Secure email > > > Code Signing > > > Server Authentication > > > > > > Under Edit Properties: > > > > > > No matter whether I choose "Enable All", "Disable All", or "Enable Only" > > > and uncheck all boxes, IIS sends out the MS Cert Server in the > > > acceptable CA list. > > > > > > Some of my subsequent posts showed up in the NGs, some didn't, but FYI, > > > I have used OpenSSL to confirm the above, and I have an image of a clean > > > Win2K/IIS/Cert Server install, and this problem is repeatable. > > > > > > > > > > > > "Sergio Dutra [MS]" wrote: > > > > > > > > What usages does the root certificate of your MS Certificate Server have > > > > (from the Enhanced Key Usage extension)? Are there any intermediate > > certs > > > > and, if so, what are their usages? > > > > > > > > -- > > > > This posting is provided "AS IS" with no warranties, and confers no > > rights. > > > > Use of included script samples are subject to the terms specified at > > > > http://www.microsoft.com/info/cpyright.htm > > > > "Ohaya" <ohaya@NO_SPAM.cox.net> wrote in message > > > > news:3F9D3A7F.7294A454@NO_SPAM.cox.net... > > > > > Hi, > > > > > > > > > > I think that I have encountered a somewhat serious "bug" somewhere. I > > > > > can't tell if it's a CryptoAPI bug, an IIS bug, or whatever, so I'm > > > > > cross-posting this to several newsgroups. This seems like (to me) a > > > > > rather serious problem, and I'll try to describe what's happening as > > > > > best I can, and also provide a somewhat kludgy workaround. > > > > > > > > > > > > > > > Background: > > > > > =========== > > > > > Server: Win2K Advanced Server SP4, updated on Friday (10/24/03) > > > > > Server is the DC (i.e., ActiveDirectory is installed) > > > > > MS Certificate Server is installed > > > > > IIS5 > > > > > > > > > > Client: Win2K Pro SP4, updated same date as server > > > > > IE 6.0.2800.1106 > > > > > > > > > > > > > > > I have been preparing to configure the above server for SSL with > > server > > > > > and client authentication for awhile. > > > > > > > > > > Before I did that, in order to do some pre-testing, I issued a server > > > > > cert for IIS with MS Certificate Server, and several client certs. > > > > > > > > > > I got all of this (SSL with client and server authentication) working, > > > > > including IE would display the client certs that were issued by MS > > > > > Certificate Server whenever I tried to connect from IE to IIS. > > > > > > > > > > > > > > > Then, using the IIS server certificate wizard, I deleted the original > > MS > > > > > Certificate Server-issued server cert, then created a new server > > > > > certificate request, which I then sent to my commerical CA one night. > > > > > The next morning, I received the new server cert from my commercial > > CA, > > > > > along with a set of test client certificates. > > > > > > > > > > I then installed the root cert from my commercial CA on the server, > > and > > > > > then using IIS, used the IIS server certificate wizard to install the > > > > > new server cert that I had just received from my commercial CA. > > > > > > > > > > I also installed one of the test client certificates from my > > commercial > > > > > CA, and installed it on my client machine, and began testing. > > > > > > > > > > > > > > > Problem: > > > > > ======== > > > > > From some previous testing with an earlier similar (SSL client and > > > > > server authentication) setup, I found that I could control which > > client > > > > > certificates that IE would display, when connecting to the server, by > > > > > enabling or disabling the "Client Authentication" Purpose in the root > > CA > > > > > certificate Purposes for specific root CAs. > > > > > > > > > > In other words, if I disabled/unchecked the "Client Authentication" > > > > > purpose for the root CA cert for "Whatever CA", then client > > certificates > > > > > issued by "Whatever CA" would display in the IE popup when I tried to > > > > > connect to the server. If I enabled/checked the "Client > > Authentication" > > > > > purpose for the root CA cert for "Whatever CA", then client > > certificates > > > > > issued by "Whatever CA" would NOT display in the IE popup when I tried > > > > > to connect to the server. > > > > > > > > > > > > > > > However, it appears that with the setup that I ended up with above > > > > > (install MS Cert Server server cert, uninstall server cert, install > > new > > > > > commercial CA server cert), which I described above under > > "Background", > > > > > this (enabling/disabling "Client Authentication" purpose for the root > > CA > > > > > cert) does not appear to work for the client certs created with MS > > > > > Certificate Server. > > > > > > > > > > Specifically, the client certificates that I created using MS > > > > > Certificate Server still get displayed by IE when connecting to the > > > > > server, regardless of how the "Client Authentication" purpose is set > > in > > > > > the root CA certificate on the server-side, and there does not appear > > to > > > > > be any reasonable way to prevent these client certificates from being > > > > > displayed by IE during a connection attempt. > > > > > > > > > > > > > > > I'm guessing (I would HOPE) that deleting the root certificate for my > > MS > > > > > Certifate Server on the SERVER might work, but then that would kill my > > > > > MS Certificate Server installation, so that doesn't seem like a > > > > > reasonable solution, and really, I'm kind of puzzled about why the > > > > > "Client Authentication" purpose is "obeyed" for all client > > certificates > > > > > except for the ones created by MS Certificate Server. > > > > > > > > > > > > > > > Bottom line: It appears that if you install MS Certificate Server, > > > > > issue a server cert and some client certs, then install a server cert > > > > > from another CA, that there is no way way get IE browsers that had > > > > > client certs from MS Certificate Server not to display those > > previously > > > > > issued client certs. > > > > > > > > > > > > > > > > > > > > Possible workaround: > > > > > ==================== > > > > > I haven't found a way, from the server-end, to cause IE not to display > > > > > those MS Certificate Server-issued client certs, but thankfully, with > > > > > IIS at least, the CTL functionality still works properly. > > > > > > > > > > In other words, if I set up a CTL with only the root cert from my > > > > > commercial CA, IE will STILL DISPLAY both the client certs from my > > > > > commercial CA and the client certs that were issued by MS Certificate > > > > > Server, but at least the authentication/connection will fail if > > someone > > > > > tries to connect using one of the client certs issued by MS > > Certificate > > > > > Server.
- Next message: Anthony Hunter: "AcceptSecurityContext problem on WinXP"
- Previous message: msnews.microsoft.com: "Re: Help with new dwInfoStatus values"
- In reply to: Ohaya: "Re: Can't disable "Trusted" for Certificates Issued by MS Certificate Server"
- Next in thread: Ohaya: "Re: Can't disable "Trusted" for Certificates Issued by MS Certificate Server"
- Reply: Ohaya: "Re: Can't disable "Trusted" for Certificates Issued by MS Certificate Server"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|