Re: Can't disable "Trusted" for Certificates Issued by MS Certificate Server

From: Bernard (qbernard_at_hotmail.com)
Date: 11/12/03


Date: Thu, 13 Nov 2003 03:47:41 +0800

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 ...
"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.


Relevant Pages

  • Re: Fax on Terminal Server from SBS2K3
    ... please make sure the Fax service is installed on the TS server. ... you can try the steps below to install Shared Fax Client: ... 248340 Installing and Using Programs in Windows 2000 Terminal Services ...
    (microsoft.public.windows.server.sbs)
  • Re: New Event Log Errors!
    ... Somehow along those lines I'd also installed the Certificate Authority ... Did you apply the last Server Pack for SBS Server? ... Please install Windows Support Tools on the win2k3 sp1 problematic ... Microsoft is providing this information only as a convenience to you: ...
    (microsoft.public.windows.server.sbs)
  • RE: Fax monitor incoming + outgoing calls?
    ... The detail steps to install share fax client as follows: ... Start server management console, locate Client Computers node, click ... To the folder redirection GPO issue: ... How to stop Folder Redirection in Windows Server 2003 and in Windows 2000 ...
    (microsoft.public.windows.server.sbs)
  • RE: No Client or Server Desktop Access Through RWW SBS 2003 SP2
    ... The SBS server is running SP2. ... However I don't know if the client computers do. ... To successfully install SBS 2003 SP1, ...
    (microsoft.public.windows.server.sbs)
  • Re: Adding EXCH2007 SP1 box to existing EXCH2003 SP2 Org
    ... Certificates - going to be using a SAN Certificate like I have many times before. ... We are making this a virtual server (someone is going on-site on Thursday to install VMWare (which will kill everything on this box) and WIN2008 Server SP1 x64 and then I will install EXCH2007 SP1. ... as mentioned - ISA was not involved in any of those eight environments.... ...
    (microsoft.public.exchange.admin)