| Groups | Blog | Home |
iis security : BUG?: Can't disable "Trusted" for Certificates Issued by MS Certificate Server
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
Hi,
Does anyone know how I can report this as a potential bug to Microsoft? FYI, I happen to have imaged my Windows 2K Server partition immediately after installing Windows, AD, IIS, and Certificate Manager, and before doing anything else. I've confirmed that with a fresh restore from the abovementioned image, the problem that I described in my original post already exists. Please advise.... [quoted text, click to view] "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.
Hi,
Using OpenSSL, I can see the actual list of trusted CAs that IIS is sending out, and this is showing that regardless of the setting of the purpose of the root certificate for MS Certificate Server, IIS is ALWAYS including the root certificate for MS Certificate Server in the list. I think that this definitely is a bug. At this point, based on what I've found, it would not be in IE, but has to be in either IIS or CryptoAPI. Why is no one responding to this??? [quoted text, click to view] Ohaya wrote:
> > Hi, > > Does anyone know how I can report this as a potential bug to Microsoft? > > FYI, I happen to have imaged my Windows 2K Server partition immediately > after installing Windows, AD, IIS, and Certificate Manager, and before doing > anything else. > > I've confirmed that with a fresh restore from the abovementioned image, the > problem that I described in my original post already exists. > > Please advise.... > > "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
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 [quoted text, click to view] "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.
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. [quoted text, click to view] "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
Sorry, I forgot to mention that the MS Certificate Server was installed
as a Standalone (root) Certificate Authority Server (i.e., not subordinate)... [quoted text, click to view] Ohaya wrote:
> > 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
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 [quoted text, click to view] "Ohaya" <ohaya@cox.net> wrote in message news:3F9EAE9A.4C769D45@cox.net... to> 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
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 [quoted text, click to view] "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, > > > > >
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. [quoted text, click to view] "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. > > > >
Sergio,
Thanks for the followup. Believe me, I am MORE than happy to provide whatever information that I can on this. I'll try to respond to all of your questions (interspersed below), and hope that I don't miss anything... [quoted text, click to view] "Sergio Dutra [MS]" wrote: > > Could you specify how you generated the Root CA and SSL server certificates > (enough details so I can reproduce it)? The certificate for the root CA (the one that is being used by the MS Certificate Server) was created when I installed MS Certificate Server. When I installed the system (Win2K Advanced Server), I think that the steps that I went through were: 1) Install Windows 2K Advanced Server SP3 (MS Cert Server not selected during installation) and IIS from CD. 2) Using the popup program that starts up automatically after Windows installation, configured machine as the first DC (i.e., installed AD). Did not install DNS Server as part of this. 3) Installed MS Certificate Server. At this point, the root CA certificate now existed in the system. I then used Windows Update to bring IE to 6.0 and Windows to SP4. I then imaged my hard drive. I did this so that I could restore the system back to this point for subsequent system, i.e., so I could use this configuration as my test baseline. I then used IIS Server Certificate wizard to create a cert request for the server. The next day, when I got the server cert back from the 3rd-party CA, I imported the root CA cert and the sub-CA cert from my 3rd-party CA/sub-CA into the Local Machine Trusted and Intermediate stores, respectively. I then used IIS Server Certificate wizard to process the server certificate that I had received from my 3rd-party CA. Note that at this point, I had: - the root CA cert for MS Certificate Server installed on the machine - the certs for the root CA and sub-CA for my 3rd-party CA installed - the server cert issued by my 3rd-party CA imported into Windows, and installed in IIS I did not have a server cert issued by my MS Certificate Server (I had not issued any yet). As I alluded to in my previous post, I kind of am guessing that this is the "root' of this "bug" (sorry for the pun :)!). [Please DON'T FLAME me for the following! This is all just GUESSING on my part, trying to imagine what kind of mistake I might have made if I was coding this stuff myself that would result in the behavior that I am actually witnessing.]: I think what's going on is a kind of "boundary" problem, i.e., something like this: The code in either IIS or CryptoAPI (I can't determine which) *assume* that there is more than one certificate created by Certificate Server already in the system. So, during the SSL handshake, when it (either IIS or CryptoAPI) starts enumerating through these certs to build the SSL CertificateRequest message, it starts checking from the 2nd cert, rather than the 1st (the MS Certificate Server CA cert), and as a result, it skips checking the "Client Authentication" purpose in the first (the MS Certificate Server root cert) cert. [quoted text, click to view] > The list you specify for the root CA, is that from the Details pane or the > General pane of the certificate UI? The list was from the Details tab, displayed in the lower pane of the certificate UI when I clicked on Enhanced Key Usage in the upper pane. [quoted text, click to view] > Also, are you attempting to perform client authentication from the same > machine as the root CA? I think that you're asking if the client machine that I'm testing with is the same as the machine that is running the MS Certificate Server? If that is an accurate interpretation of your question, then the answer is "no". As I explained in detail in the 1st post in this thread I am using two machines in these tests: 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 If so, the root CA may have a copy in another store [quoted text, click to view] > (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. Again, that (client machine = server machine) is not the configuration that I have. The client machine (running Win2K Pro) is a physically separate machine from the server (running Win2K Advanced Server). [quoted text, click to view] > > -- > 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 [quoted text, click to view] > "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. > >
Bernard,
NONE so far :(.... [quoted text, click to view] Bernard wrote:
> > and what's the outcome ?? > > -- > Regards, > Bernard Cheah > http://support.microsoft.com/ > Please respond to newsgroups only ... > > "Ohaya" <ohaya@NO_SPAM.cox.net> wrote in message > news:3FA1922B.C74AD692@NO_SPAM.cox.net... > > Sergio, > > > > Thanks for the followup. Believe me, I am MORE than happy to provide > > whatever information that I can on this. I'll try to respond to all of > > your questions (interspersed below), and hope that I don't miss > > anything... > > > > > > > > "Sergio Dutra [MS]" wrote: > > > > > > Could you specify how you generated the Root CA and SSL server > certificates > > > (enough details so I can reproduce it)? > > > > The certificate for the root CA (the one that is being used by the MS > > Certificate Server) was created when I installed MS Certificate Server. > > > > When I installed the system (Win2K Advanced Server), I think that the > > steps that I went through were: > > > > 1) Install Windows 2K Advanced Server SP3 (MS Cert Server not selected > > during installation) and IIS from CD. > > > > 2) Using the popup program that starts up automatically after Windows > > installation, configured machine as the first DC (i.e., installed AD). > > Did not install DNS Server as part of this. > > > > 3) Installed MS Certificate Server. > > > > At this point, the root CA certificate now existed in the system. > > > > I then used Windows Update to bring IE to 6.0 and Windows to SP4. > > > > I then imaged my hard drive. I did this so that I could restore the > > system back to this point for subsequent system, i.e., so I could use > > this configuration as my test baseline. > > > > I then used IIS Server Certificate wizard to create a cert request for > > the server. > > > > The next day, when I got the server cert back from the 3rd-party CA, I > > imported the root CA cert and the sub-CA cert from my 3rd-party > > CA/sub-CA into the Local Machine Trusted and Intermediate stores, > > respectively. > > > > I then used IIS Server Certificate wizard to process the server > > certificate that I had received from my 3rd-party CA. > > > > Note that at this point, I had: > > > > - the root CA cert for MS Certificate Server installed on the machine > > - the certs for the root CA and sub-CA for my 3rd-party CA installed > > - the server cert issued by my 3rd-party CA imported into Windows, and > > installed in IIS > > > > I did not have a server cert issued by my MS Certificate Server (I had > > not issued any yet). As I alluded to in my previous post, I kind of am > > guessing that this is the "root' of this "bug" (sorry for the pun :)!). > > > > [Please DON'T FLAME me for the following! This is all just GUESSING on > > my part, trying to imagine what kind of mistake I might have made if I > > was coding this stuff myself that would result in the behavior that I am > > actually witnessing.]: > > > > I think what's going on is a kind of "boundary" problem, i.e., something > > like this: The code in either IIS or CryptoAPI (I can't determine > > which) *assume* that there is more than one certificate created by > > Certificate Server already in the system. So, during the SSL handshake, > > when it (either IIS or CryptoAPI) starts enumerating through these certs > > to build the SSL CertificateRequest message, it starts checking from the > > 2nd cert, rather than the 1st (the MS Certificate Server CA cert), and > > as a result, it skips checking the "Client Authentication" purpose in > > the first (the MS Certificate Server root cert) cert. > > > > > > > > > > > > > The list you specify for the root CA, is that from the Details pane or > the > > > General pane of the certificate UI? > > > > The list was from the Details tab, displayed in the lower pane of the > > certificate UI when I clicked on Enhanced Key Usage in the upper pane. > > > > > > > Also, are you attempting to perform client authentication from the same > > > machine as the root CA? > > > > I think that you're asking if the client machine that I'm testing with > > is the same as the machine that is running the MS Certificate Server? > > > > If that is an accurate interpretation of your question, then the answer > > is "no". > > > > As I explained in detail in the 1st post in this thread I am using two > > machines in these tests: > > > > 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 > > > > > > > > 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. > > > > Again, that (client machine = server machine) is not the configuration > > that I have. The client machine (running Win2K Pro) is a physically > > separate machine from the server (running Win2K Advanced Server). > > > > > > > > > > -- > > > 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. > > > >
and what's the outcome ??
-- Regards, Bernard Cheah http://support.microsoft.com/ Please respond to newsgroups only ... [quoted text, click to view] "Ohaya" <ohaya@NO_SPAM.cox.net> wrote in message
news:3FA1922B.C74AD692@NO_SPAM.cox.net... > Sergio, > > Thanks for the followup. Believe me, I am MORE than happy to provide > whatever information that I can on this. I'll try to respond to all of > your questions (interspersed below), and hope that I don't miss > anything... > > > > "Sergio Dutra [MS]" wrote: > > > > Could you specify how you generated the Root CA and SSL server certificates > > (enough details so I can reproduce it)? > > The certificate for the root CA (the one that is being used by the MS > Certificate Server) was created when I installed MS Certificate Server. > > When I installed the system (Win2K Advanced Server), I think that the > steps that I went through were: > > 1) Install Windows 2K Advanced Server SP3 (MS Cert Server not selected > during installation) and IIS from CD. > > 2) Using the popup program that starts up automatically after Windows > installation, configured machine as the first DC (i.e., installed AD). > Did not install DNS Server as part of this. > > 3) Installed MS Certificate Server. > > At this point, the root CA certificate now existed in the system. > > I then used Windows Update to bring IE to 6.0 and Windows to SP4. > > I then imaged my hard drive. I did this so that I could restore the > system back to this point for subsequent system, i.e., so I could use > this configuration as my test baseline. > > I then used IIS Server Certificate wizard to create a cert request for > the server. > > The next day, when I got the server cert back from the 3rd-party CA, I > imported the root CA cert and the sub-CA cert from my 3rd-party > CA/sub-CA into the Local Machine Trusted and Intermediate stores, > respectively. > > I then used IIS Server Certificate wizard to process the server > certificate that I had received from my 3rd-party CA. > > Note that at this point, I had: > > - the root CA cert for MS Certificate Server installed on the machine > - the certs for the root CA and sub-CA for my 3rd-party CA installed > - the server cert issued by my 3rd-party CA imported into Windows, and > installed in IIS > > I did not have a server cert issued by my MS Certificate Server (I had > not issued any yet). As I alluded to in my previous post, I kind of am > guessing that this is the "root' of this "bug" (sorry for the pun :)!). > > [Please DON'T FLAME me for the following! This is all just GUESSING on > my part, trying to imagine what kind of mistake I might have made if I > was coding this stuff myself that would result in the behavior that I am > actually witnessing.]: > > I think what's going on is a kind of "boundary" problem, i.e., something > like this: The code in either IIS or CryptoAPI (I can't determine > which) *assume* that there is more than one certificate created by > Certificate Server already in the system. So, during the SSL handshake, > when it (either IIS or CryptoAPI) starts enumerating through these certs > to build the SSL CertificateRequest message, it starts checking from the > 2nd cert, rather than the 1st (the MS Certificate Server CA cert), and > as a result, it skips checking the "Client Authentication" purpose in > the first (the MS Certificate Server root cert) cert. > > > > > > > The list you specify for the root CA, is that from the Details pane or the > > General pane of the certificate UI? > > The list was from the Details tab, displayed in the lower pane of the > certificate UI when I clicked on Enhanced Key Usage in the upper pane. > > > > Also, are you attempting to perform client authentication from the same > > machine as the root CA? > > I think that you're asking if the client machine that I'm testing with > is the same as the machine that is running the MS Certificate Server? > > If that is an accurate interpretation of your question, then the answer > is "no". > > As I explained in detail in the 1st post in this thread I am using two > machines in these tests: > > 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 > > > > 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. > > Again, that (client machine = server machine) is not the configuration > that I have. The client machine (running Win2K Pro) is a physically > separate machine from the server (running Win2K Advanced Server). > > > > > > -- > > 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
Sergio missing in action ?
I just enable this thread trace flags.. will keep monitoring :) sorry, I'm out on this one . -- Regards, Bernard Cheah http://support.microsoft.com/ Please respond to newsgroups only ... [quoted text, click to view] "Ohaya" <ohaya@NO_SPAM.cox.net> wrote in message
news:3FAEA65F.196E6003@NO_SPAM.cox.net... > Bernard, > > NONE so far :(.... > > > > > Bernard wrote: > > > > and what's the outcome ?? > > > > -- > > Regards, > > Bernard Cheah > > http://support.microsoft.com/ > > Please respond to newsgroups only ... > > > > "Ohaya" <ohaya@NO_SPAM.cox.net> wrote in message > > news:3FA1922B.C74AD692@NO_SPAM.cox.net... > > > Sergio, > > > > > > Thanks for the followup. Believe me, I am MORE than happy to provide > > > whatever information that I can on this. I'll try to respond to all of > > > your questions (interspersed below), and hope that I don't miss > > > anything... > > > > > > > > > > > > "Sergio Dutra [MS]" wrote: > > > > > > > > Could you specify how you generated the Root CA and SSL server > > certificates > > > > (enough details so I can reproduce it)? > > > > > > The certificate for the root CA (the one that is being used by the MS > > > Certificate Server) was created when I installed MS Certificate Server. > > > > > > When I installed the system (Win2K Advanced Server), I think that the > > > steps that I went through were: > > > > > > 1) Install Windows 2K Advanced Server SP3 (MS Cert Server not selected > > > during installation) and IIS from CD. > > > > > > 2) Using the popup program that starts up automatically after Windows > > > installation, configured machine as the first DC (i.e., installed AD). > > > Did not install DNS Server as part of this. > > > > > > 3) Installed MS Certificate Server. > > > > > > At this point, the root CA certificate now existed in the system. > > > > > > I then used Windows Update to bring IE to 6.0 and Windows to SP4. > > > > > > I then imaged my hard drive. I did this so that I could restore the > > > system back to this point for subsequent system, i.e., so I could use > > > this configuration as my test baseline. > > > > > > I then used IIS Server Certificate wizard to create a cert request for > > > the server. > > > > > > The next day, when I got the server cert back from the 3rd-party CA, I > > > imported the root CA cert and the sub-CA cert from my 3rd-party > > > CA/sub-CA into the Local Machine Trusted and Intermediate stores, > > > respectively. > > > > > > I then used IIS Server Certificate wizard to process the server > > > certificate that I had received from my 3rd-party CA. > > > > > > Note that at this point, I had: > > > > > > - the root CA cert for MS Certificate Server installed on the machine > > > - the certs for the root CA and sub-CA for my 3rd-party CA installed > > > - the server cert issued by my 3rd-party CA imported into Windows, and > > > installed in IIS > > > > > > I did not have a server cert issued by my MS Certificate Server (I had > > > not issued any yet). As I alluded to in my previous post, I kind of am > > > guessing that this is the "root' of this "bug" (sorry for the pun :)!). > > > > > > [Please DON'T FLAME me for the following! This is all just GUESSING on > > > my part, trying to imagine what kind of mistake I might have made if I > > > was coding this stuff myself that would result in the behavior that I am > > > actually witnessing.]: > > > > > > I think what's going on is a kind of "boundary" problem, i.e., something > > > like this: The code in either IIS or CryptoAPI (I can't determine > > > which) *assume* that there is more than one certificate created by > > > Certificate Server already in the system. So, during the SSL handshake, > > > when it (either IIS or CryptoAPI) starts enumerating through these certs > > > to build the SSL CertificateRequest message, it starts checking from the > > > 2nd cert, rather than the 1st (the MS Certificate Server CA cert), and > > > as a result, it skips checking the "Client Authentication" purpose in > > > the first (the MS Certificate Server root cert) cert. > > > > > > > > > > > > > > > > > > > The list you specify for the root CA, is that from the Details pane or > > the > > > > General pane of the certificate UI? > > > > > > The list was from the Details tab, displayed in the lower pane of the > > > certificate UI when I clicked on Enhanced Key Usage in the upper pane. > > > > > > > > > > Also, are you attempting to perform client authentication from the same > > > > machine as the root CA? > > > > > > I think that you're asking if the client machine that I'm testing with > > > is the same as the machine that is running the MS Certificate Server? > > > > > > If that is an accurate interpretation of your question, then the answer > > > is "no". > > > > > > As I explained in detail in the 1st post in this thread I am using two > > > machines in these tests: > > > > > > 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 > > > > > > > > > > > > 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. > > > > > > Again, that (client machine = server machine) is not the configuration > > > that I have. The client machine (running Win2K Pro) is a physically > > > separate machine from the server (running Win2K Advanced Server). > > > > > > > > > > > > > > -- > > > > 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
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |