Re: Can't disable "Trusted" for Certificates Issued by MS Certificate Server
From: Sergio Dutra [MS] (sergiod_at_online.microsoft.com)
Date: 12/08/03
- Next message: Sergio Dutra [MS]: "Re: CertEnumCertificatesInStore() and IE"
- Previous message: Robert Scarab: "Problems using hToken from Winlogon"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 8 Dec 2003 11:36:28 -0800
I attempted to repro the scenario with certificates issued by MS CAs and
certificates issued by non-MS CAs, and here's what I observed: What matters
only are the properties on the root certificates on the SSL server, and not
the properties on the root certificates on the client.
That is:
Client machine C installs two certificates, one issued by CA "A" and one
issued by CA "B", both being client authentication certificates.
Server S trusts both "A" and "B", and the EKU properties on S allow for
client authentication for both "A" and "B".
Client C disables the client authentication property for "A", and attempts
to connect to S using IE. IE pops up the dialog with both certificates
issued by "A" and "B" - because S still trusts "A" and "B" for client
authentication.
Server S now disables the client authentication EKU property for "B". The
client is unchanged.
Client C attempts to connect again. This time, only the cert issued by "A"
is available, since S no longer trusts "B" for client authentication.
Hence, it seems IE allows you to use only those certificates which the
server will accept - even if you chose not to accept them on the client by
disabling the Client Authentication usage on the local root. However, I
would claim that if you do not wish to use a certificate for client
authentication, then you should remove the certificate, or perhaps try
disabling the Client Authentication property on the END certificate (if the
certificate is good for more than one usage).
So, double check that when you install the new CA, that the EKU property is
set on the server end, not the client end.
-- 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:3FBDE705.E7700CF1@NO_SPAM.cox.net... > Sergio, > > Thanks. Believe me, I understand... > > > > "Sergio Dutra [MS]" wrote: >> >> Sorry for the delay, but I'm afraid I have been extremely swamped and >> will >> get back to you on this sometime this week or next week. I am not a >> product >> support person and have many, many other issues which are currently >> taking >> high priority. >> >> If you need a quicker reponse, please go through PSS. >> >> Just to clarify what I intend to do from my end: I will attempt to repro >> the >> issue and, if able to repro it, I will file a bug on it and let you know. >> If >> there is a workaround I will also let you know. However, if I am unable >> to >> repro it and you still have your problem, you must go through PSS to >> continue resolving the issue. >> >> -- >> 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: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 >> > > > > > 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: Sergio Dutra [MS]: "Re: CertEnumCertificatesInStore() and IE"
- Previous message: Robert Scarab: "Problems using hToken from Winlogon"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
Loading
