BUG?: Can't disable "Trusted" for Certificates Issued by MS CertificateServer

[Ohaya]

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.

 

[Ohaya]

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]

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???

 

[Sergio Dutra [MS]]

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?

 

[Ohaya]

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.

 

[Ohaya]

Sorry, I forgot to mention that the MS Certificate Server was installed
as a Standalone (root) Certificate Authority Server (i.e., not
subordinate)...

 

[Sergio Dutra [MS]]

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.

 

[Ohaya]

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]]

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.

 

[Ohaya]

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

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

 

[Bernard]

and what's the outcome ??

--
Regards,
Bernard Cheah
http://support.microsoft.com/
Please respond to newsgroups only ...

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

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




allowed
by usages
and on
end listed
the issued
by it the
EKU Client
Auth contain
that Server
have so
I'm me)
a happening
as install
the server,
by the
root tried
to I
tried the
root to
the is
set from
being for
my server
cert thankfully,
with

 

[Ohaya]

Bernard,

NONE so far ....

and what's the outcome ??

--
Regards,
Bernard Cheah
http://support.microsoft.com/
Please respond to newsgroups only ...

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

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




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.





:

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



:

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

 

[Bernard]

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

Bernard,

NONE so far ....

and what's the outcome ??

--
Regards,
Bernard Cheah
http://support.microsoft.com/
Please respond to newsgroups only ...

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



:

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





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.





:

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



:

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?

confers
no

rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
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.