Care, Share and Grow! : SSL

Configuring FTP 7.5 with Host Header and SSL

Saurabh Singh — Fri, 06 Nov 2009 20:59:39 GMT

FTP 7.5 comes with new features like Host header and SSL. I recently saw some cases coming in from our customers on this. Scanning the Internet made me realize that we need more information posted on this as far as the configuration is concerned.

If you are seeing any of these errors while connecting to an IIS FTP server using SSL/Host header like

534-Local policy on server does not allow TLS secure connections.
Win32 error: Access is denied.
Error details: SSL certificate was not configured.

Primary connection and data connection certificates don't match.
Error: Transfer connection interrupted: ECONNABORTED - Connection aborted

431-Failed to setup secure session.
Win32 error:
Error details: SSL certificate hash has invalid length.

534-Protection level negotiation failed.
Win32 error: Access is denied.
Error details: Protection negotiation failed. PROT command with recognized parameter must precede this command.

then check this blog post here.

I wrote this article on our Team blog site hoping it reduces the confusion around this topic.

Ciao!

Using System.Net trace configuration file to troubleshoot Certificate errors in ASP.Net

Saurabh Singh — Wed, 16 Sep 2009 20:46:28 GMT

System.Net trace configuration feature in ASP.Net 2.0 onwards is extremely useful when dealing with certificate related errors.

Jeff P. Sanders from WinInet/System.Net API Escalation team has written this valuable post for troubleshooting ASP.Net certificate related issues.

I am adding it here as a quick reference for others and myself.

http://blogs.msdn.com/jpsanders/archive/2009/09/16/troubleshooting-asp-net-the-remote-certificate-is-invalid-according-to-the-validation-procedure.aspx

Great article!

SSL Troubleshooting for IIS Web Sites contd...

Saurabh Singh — Tue, 27 May 2008 03:05:00 GMT

Recently a colleague of mine was working on a customer's case which was a Critical level incident. High pressure job, huhh!

The issue was with SSL not working for one of their web sites. They were seeing "Page cannot be displayed" when trying to access this site over SSL. It worked just fine over HTTP.

In the System event log we were seeing this intermittently:

Event Type: Error
Event Source: W3SVC
Event Category: None
Event ID: 1114
Description:
One of the IP/Port combinations for site 'NNNNN' has already been configured to be used
by another program. The other program's SSL configuration will be used.

We troubleshot on this issue for hours without luck :-(. We tried all the steps I guess as mentioned here .

Here is what all we tried:

Checked the Certificate properties to ensure it was a valid one. It was good.
Yet, replaced the current certificate with a new one, still no luck.
Here customer had all the sites running under different IP addresses. Rest of the other sites were working over SSL, except this one :-(.
We ran SSLDiag which gave a misleading error.
We tried running the site on a different SSL port, still no luck.
We setup the securebindings metabase property for the web site in question, still no luck.
We ran netstat -ano to check for any other process listening on this port, everything looked clean. refer this.
We disabled all the 3rd party non-MS services, restarted Windows Server in selective startup mode, no luck.
We installed Windows Server 2003 Service Pack 1 32-bit Support Tools on the server, ran the httpcfg query iplisten. It gave a clean output, no specific IP entries listed by it.
Restarted IIS/HTTP services umpteen number of times during the course of troubleshooting, no luck whatsoever. Even reboot was done a couple of times.

Finally after few hours of troubleshooting we decided to run this site on a different IP address (we had thought of this earlier but our customer was under a constraint) and hurray it worked this time!!!. Now everything was set but we had a lingering question in mind as to why, why, why this site did not work on that IP address we had. It had an entry in the Advanced TCP/IP Settings, was a valid one in all the sense to our best knowledge.

Finally we figured out that there was a problem with the IIS SSL listener.

To get a list of IP and port configuration binded to a certificate, run "httpcfg query ssl". Here is an excerpt from a technet article:

The HTTP API enables applications to communicate over HTTP without using Microsoft Internet Information Services (IIS). Applications can register to receive HTTP requests for particular URLs, receive HTTP requests, and send HTTP responses. The HTTP API includes SSL support so applications can also exchange data over secure HTTP connections without depending on IIS. It is also designed to work with I/O completion ports.....Such meta-information is maintained by the HTTP API in a metastore, and is used to locate certificates for certificate exchange in HTTPS sessions.

Below is a sample of a working and non-working scenario:
------------------------------------------------------------------------------

\Program Files\Support Tools> httpcfg.exe query ssl

Working scenario:

IP                      : 192.168.100.118:443
Hash                  : c96667684997887f 5b889b7b3f737c8c4da5f16
Guid                  : {4dc3e181-e14b-4a21-b022-59fc669b0914}
CertStoreName           : MY
CertCheckMode           : 0
RevocationFreshnessTime : 0
UrlRetrievalTimeout     : 0
SslCtlIdentifier        :
SslCtlStoreName         :
Flags                   : 0

Non-working scenario:

IP                     : 192.168.100.234:443
Hash                :
Guid                : {00000000-0000-0000-0000-000000000000}
CertStoreName : (null)
CertCheckMode : 0
RevocationFreshnessTime : 0
UrlRetrievalTimeout : 0
SslCtlIdentifier : (null)
SslCtlStoreName : (null)
Flags : 0

Here Hash will have the same value as the Thumbprint in your SSL certificate. You will notice that the Guid is all zero in a non-working scenario. You may see the Hash either having some value or blank. Even if we remove the certificate from the web site, and then run "httpcfg query ssl", the site with all Guid as all "0" will still be listed. If you see the GUID as "{0000...............000}, there is a problem.

We need to remove this entry by running the command "httpcfg delete ssl -i <IP:Port Number>". In the above example, we need to type "httpcfg delete ssl -i 192.168.100.234:443". Once we remove it, then we need to reinstall the certificate back on to the web site.

Also once certificate is installed, in the cmd prompt type in "httpcfg query ssl" to confirm the GUID is no longer all 0.

This fixed the issue for the web site on the failing IP address.

Hope this helps someone.

Till next time, Cheers!

HTTP to HTTPS (SSL) Web Request Redirection

Saurabh Singh — Fri, 04 Jan 2008 00:47:42 GMT

We often get requests from our customers asking how they can seamlessly redirect web requests from HTTP to HTTPS, i.e. how they can redirect a non-SSL request to an SSL based request. Recently a colleague of mine got a similar issue and we decided to use some existing scripts that we had in our database. Unfortunately none could meet the requirement.

Basically the existing scripts redirected an HTTP request to another URL and that URL was not the original request user had asked for. It took us to let's say the homepage of the site and from there one again has to click on specific links to reach the desired page. So this will be a problem for users who have book-marked their desired web page.

Here are the steps you can try for your website such that all HTTP requests get translated to HTTPS requests and have the original URL intact.

Here are two sample codes which one can try. Both of them should *hopefully* work. First one uses VBScript in an ASP page and second one uses Javascript in an HTML page.

a).

redirectSSL.asp

<%@ Language=VBScript %>

<%

strQueryString = Request.QueryString

sslPort = null

PlainURL = Right(strQueryString, len(strQueryString) - 4)

FindLastCOlon = InStrRev(PlainURL, ":")

FirstPart = Mid(PlainURL, 1, FindLastColon - 1)

LastPart = Mid(PlainURL, FindLastColon)

LastPart = (Mid(LastPart, InStr(LastPart, "/")))

'If the SSL Port is not the default 443, you need to uncomment the line below, by default SSL port is 443.

'sslPort = ":449"

if (sslPort = null) then

    url= FirstPart & LastPart

else

    url = FirstPart & sslPort & LastPart

end if

strSecure = Replace(url, "http:", "https:", 1, 1)

Response.Redirect strSecure

%>

Steps:

-- Copy the above code and put in a file redirectSSL.asp under your Website root directory for which you want redirection to work.

-- Force SSL on the web site. To do that follow the steps mentioned below:
- Go to --> <Your_Web_Site> -> Properties -> Directory Security -> Edit (Secure Communications)
- Select Require secure channel (SSL).

-- Uncheck "Require secure channel (SSL)" option for the redirectSSL.asp page. To achieve that:
- Go to --> <Your_Web_Site> -> redirectSSL.asp -> Properties -> File Security -> Edit (Secure Communications)
- Uncheck Require secure channel (SSL).

So now we are forcing SSL to be used for all of the website contents except the redirectSSL.asp page which can be accessed over non-SSL (HTTP).

-- In the IIS manager -> <Your_Web_Site> -> Properties -> Custom Errors, modify the entry for 403;4 to look like this:

Now if you try to browse to some URL, let's say http://www.abc.com/asp/test/ssl/iistsart.htm, you will be redirected to https://www.abc.com/asp/test/ssl/iistsart.htm, without you requiring to modify HTTP to HTTPS.

If your SSL port is not the default port 443 then you need to un-comment a line in the code as mentioned in there and it will redirect the request to the appropriate URL with corrected SSL port embedded in it.

b).

redirectSSL.html

<html>

<head>

<script language="javascript">

var currentURL=location.href.substring(0,5)

if(currentURL.toLowerCase()!="https")

currentURL = location.href.substring(4,location.href.lastIndexOf(''))

var portStartPos = currentURL.lastIndexOf(':')

var sslPort = null

if(portStartPos!=0)

var relativeURL = currentURL.substring(portStartPos)

var postPortURL = relativeURL.substring(relativeURL.indexOf('/'))

var URL = currentURL.substring(0,portStartPos)

// If you are running your SSL site on a non default port other than 443 then uncomment the next line and add the right Port number.

//sslPort = ":447"

if(sslPort == null)

    currentURL = URL + postPortURL

else

    currentURL = URL + sslPort + postPortURL

var targetURL = "https" + currentURL

window.location = targetURL

</script>

</head>

</html>

Steps:

-- Copy the above code and put in a file redirectSSL.html under your Website root directory for which you want redirection to work.

So now we are forcing SSL to be used for all of the Website contents.

-- In the IIS manager -> <Your_Website> -> Properties -> custom Errors, modify the entry for 403;4 to look like this:

You need not follow the step below since we are using File Type for custom error page and not a URL as shown above in the picture. If you select URL as Type above then you will need to follow the step below.

"-- Uncheck "Require secure channel (SSL)" option for the redirectSSL.html page. To achieve that:
- Go to --> <Your_Web_Site> -> redirectSSL.asp -> Properties -> File Security -> Edit (Secure Communications)
- Uncheck Require secure channel (SSL)."

This is all you need and you should see your URL changing automagically from HTTP to HTTPS (SSL).

Hope this helps...

Certificate Trust List not being honored by IIS 5.0/6.0/7.0?

Saurabh Singh — Sat, 08 Dec 2007 00:36:13 GMT

Something one should be aware of if one is dealing with Client certificate and assuming Certificate Trust List (CTL) will limit the list of Trusted Certificate Authorities (CA's) being sent to the client during the initial SSL handshake.

In IIS 5.0 Post MS04-011 update and IIS 6.0/7.0 using CTL's you cannot limit the list of CA's sent back to the client during the SSL/TLS handshake. i.e. you can't use CTL's to limit the list of certificates that Internet Explorer is showing. IE will show all the certificates irrespective of whether the issuing CA is a part of the CTL or not.

This however is not applicable to Apache web server. Apache will send the list of CA's which are part of the CTL. The above behavior was implemented in IIS as a security design feature. You can use OpenSSL to check the behavior:

Let's assume we have a web site www.test.com which accepts client certificates. OpenSSL will show the following transaction. Note that it sends the list of all the CA's even if you have configured CTL to allow specific CA's.

C:\>OpenSSL s_client -connect www.test.com:443 -prexit
Loading 'screen' into random state - done
CONNECTED(00000790)
depth=0 /C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
   i:/DC=com/DC=Saurabh1/CN=Microsoft
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIE3DCCA8SgAwIBAgIKEfew+wAAAAAANTANBgkqhkiG9w0BAQUFADBDMRMwEQYK
CZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIU2F1cmFiaDExEjAQBgNV
BAMTCU1pY3Jvc29mdDAeFw0wNzExMTYyMzE1MjFaFw0wOTExMTUyMzE1MjFaMGgx
CzAJBgNVBAYTAkNBMRIwEAYDVQQIEwlLYXJuYXRha2ExEjAQBgNVBAcTCUJhbmdh
bG9yZTEMMAoGA1UEChMDYWJjMQwwCgYDVQQLEwNJSVMxFTATBgNVBAMTDHd3dy50
ZXN0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyHwhBcSOgyfAe2WJ
2m391qWNTEKj9ScSKrbrzxEFWqEKIReH5pkabxG188vX1uQoo5MUCGd3WIEAb3Xa
T+mY7P/nA3fwMEUjF1apwXPwQf8hpx5GXhPM6YjyizFGxq06qgNTG3+gCh8arwhu
u8f9zKOEUicGDOJaQHIK1ofp4G8CAwEAAaOCAi8wggIrMAsGA1UdDwQEAwIFoDBE
BgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw
BwYFKw4DAgcwCgYIKoZIhvcNAwcwEwYDVR0lBAwwCgYIKwYBBQUHAwEwHQYDVR0O
BBYEFBi8sz9sklijc8tObd/kfYp13IQXMB8GA1UdIwQYMBaAFAVRxGOV1iHL6wJC
f2vFzSTt5QFwMEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9sYXhtaW5iLnNhdXJh
YmgxLmNvbS9DZXJ0RW5yb2xsL01pY3Jvc29mdC5jcmwwggEVBggrBgEFBQcBAQSC
AQcwggEDMIGpBggrBgEFBQcwAoaBnGxkYXA6Ly8vQ049TWljcm9zb2Z0LENOPUFJ
QSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25m
aWd1cmF0aW9uLERDPVNhdXJhYmgxLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/
b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBVBggrBgEFBQcwAoZJ
aHR0cDovL2xheG1pbmIuc2F1cmFiaDEuY29tL0NlcnRFbnJvbGwvTEFYTUlOQi5T
YXVyYWJoMS5jb21fTWljcm9zb2Z0LmNydDAhBgkrBgEEAYI3FAIEFB4SAFcAZQBi
AFMAZQByAHYAZQByMA0GCSqGSIb3DQEBBQUAA4IBAQAPf48JnKDC5qnGUOwzPsVY
iz454kHCa6hWxO4L8Lf4uZ/iTwhjvG+LsPZpsijxAkpa/Me2YAtTJS8HaKa0l+on
VAsDl4AJLK0epH7iQUfahe5BH3DxYcXFi2uAZeSFa12STxa5Ywtknrlxelimzak+
CgEZTSUDTtSDAOxwIpIXlmsPzBmaI7Cx6+R0Kul3H+DPRP/iE/Qh7yzlXbDqcAsA
i91ungRcHtiFxkLSwfRbV/qyr2OszKa+7SM9GJ6R0lJC5oRBy/JkQqWiAYvRaf5J
iTdC7eourVL+TH+GhXnFpmCs+YlotkWLj7EsLKwKiEuX8mm8T6UXKzis2OazfHfh
-----END CERTIFICATE-----
subject=/C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
issuer=/DC=com/DC=Saurabh1/CN=Microsoft
---
No client certificate CA names sent
---
SSL handshake has read 1384 bytes and written 324 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
SSL-Session:
    Protocol : TLSv1
    Cipher    : RC4-MD5
    Session-ID: B21A0000950C415B75F380724109AE354A29437F77C62FCEF493BD823C62C616
    Session-ID-ctx:
    Master-Key: 6A2F53DBE5ED1565D1E7CB218B4D1B7AF7CFE07594469D69772C26232BBB0253326ACC25A106D3A6B452
1B3B0989D57D
    Key-Arg   : None
    Start Time: 1197061986
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---
GET /test.asp
depth=0 /C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
verify error:num=21:unable to verify the first certificate
verify return:1
read R BLOCK
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>The page requires a client certificate</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=Windows-1252">
<STYLE type="text/css">
BODY { font: 8pt/12pt verdana }
H1 { font: 13pt/15pt verdana }
H2 { font: 8pt/12pt verdana }
A:link { color: red }
A:visited { color: maroon }
</STYLE>
</HEAD><BODY><TABLE width=500 border=0 cellspacing=10><TR><TD>

<h1>The page requires a client certificate</h1>
The page you are attempting to access requires your browser to have a Secure Sockets Layer (SSL) cli
ent certificate that the Web server will recognize. The client certificate is used for identifying y
ou as a valid user of the resource.
<hr>
<p>Please try the following:</p>
<ul>
<li>Contact the Web site administrator if you believe you should be able to view this directory or p
age without a client certificate, or to obtain a client certificate.</li>
<li>If you already have a client certificate, use your Web browser's security features to ensure tha
t your client certificate is installed properly. (Some Web browsers refer
to client certificates as browser or personal certificates.)</li>
</ul>
<h2>HTTP Error 403.7 - Forbidden: SSL client certificate is required.<br>Internet Information Servic
es (IIS)</h2>
<hr>
<p>Technical Information (for support personnel)</p>
<ul>
<li>Go to <a href="http://go.microsoft.com/fwlink/?linkid=8180">Microsoft Product Support Services</
a> and perform a title search for the words <b>HTTP</b> and <b>403</b>.</li>
<li>Open <b>IIS Help</b>, which is accessible in IIS Manager (inetmgr),
and search for topics titled <b>About Certificates</b>, <b>Using Certificate Trust Lists</b>, <b>En
abling Client Certificates</b>, and <b>About Custom Error Messages</b>.</li>
</ul>

</TD></TR></TABLE></BODY></HTML>

read:errno=0
---
Certificate chain
0 s:/C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
   i:/DC=com/DC=Saurabh1/CN=Microsoft
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIE3DCCA8SgAwIBAgIKEfew+wAAAAAANTANBgkqhkiG9w0BAQUFADBDMRMwEQYK
CZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIU2F1cmFiaDExEjAQBgNV
BAMTCU1pY3Jvc29mdDAeFw0wNzExMTYyMzE1MjFaFw0wOTExMTUyMzE1MjFaMGgx
CzAJBgNVBAYTAkNBMRIwEAYDVQQIEwlLYXJuYXRha2ExEjAQBgNVBAcTCUJhbmdh
bG9yZTEMMAoGA1UEChMDYWJjMQwwCgYDVQQLEwNJSVMxFTATBgNVBAMTDHd3dy50
ZXN0LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyHwhBcSOgyfAe2WJ
2m391qWNTEKj9ScSKrbrzxEFWqEKIReH5pkabxG188vX1uQoo5MUCGd3WIEAb3Xa
T+mY7P/nA3fwMEUjF1apwXPwQf8hpx5GXhPM6YjyizFGxq06qgNTG3+gCh8arwhu
u8f9zKOEUicGDOJaQHIK1ofp4G8CAwEAAaOCAi8wggIrMAsGA1UdDwQEAwIFoDBE
BgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAw
BwYFKw4DAgcwCgYIKoZIhvcNAwcwEwYDVR0lBAwwCgYIKwYBBQUHAwEwHQYDVR0O
BBYEFBi8sz9sklijc8tObd/kfYp13IQXMB8GA1UdIwQYMBaAFAVRxGOV1iHL6wJC
f2vFzSTt5QFwMEUGA1UdHwQ+MDwwOqA4oDaGNGh0dHA6Ly9sYXhtaW5iLnNhdXJh
YmgxLmNvbS9DZXJ0RW5yb2xsL01pY3Jvc29mdC5jcmwwggEVBggrBgEFBQcBAQSC
AQcwggEDMIGpBggrBgEFBQcwAoaBnGxkYXA6Ly8vQ049TWljcm9zb2Z0LENOPUFJ
QSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25m
aWd1cmF0aW9uLERDPVNhdXJhYmgxLERDPWNvbT9jQUNlcnRpZmljYXRlP2Jhc2U/
b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBVBggrBgEFBQcwAoZJ
aHR0cDovL2xheG1pbmIuc2F1cmFiaDEuY29tL0NlcnRFbnJvbGwvTEFYTUlOQi5T
YXVyYWJoMS5jb21fTWljcm9zb2Z0LmNydDAhBgkrBgEEAYI3FAIEFB4SAFcAZQBi
AFMAZQByAHYAZQByMA0GCSqGSIb3DQEBBQUAA4IBAQAPf48JnKDC5qnGUOwzPsVY
iz454kHCa6hWxO4L8Lf4uZ/iTwhjvG+LsPZpsijxAkpa/Me2YAtTJS8HaKa0l+on
VAsDl4AJLK0epH7iQUfahe5BH3DxYcXFi2uAZeSFa12STxa5Ywtknrlxelimzak+
CgEZTSUDTtSDAOxwIpIXlmsPzBmaI7Cx6+R0Kul3H+DPRP/iE/Qh7yzlXbDqcAsA
i91ungRcHtiFxkLSwfRbV/qyr2OszKa+7SM9GJ6R0lJC5oRBy/JkQqWiAYvRaf5J
iTdC7eourVL+TH+GhXnFpmCs+YlotkWLj7EsLKwKiEuX8mm8T6UXKzis2OazfHfh
-----END CERTIFICATE-----
subject=/C=CA/ST=Karnataka/L=Bangalore/O=abc/OU=IIS/CN=www.test.com
issuer=/DC=com/DC=Saurabh1/CN=Microsoft
---
Acceptable client certificate CA names
/DC=com/DC=Saurabh1/CN=Microsoft
/DC=com/DC=Saurabh1/CN=Saurabh CA
/C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign,
Inc. - For authorized use only/OU=VeriSign Trust Network
/C=US/O=VeriSign, Inc./OU=Class 4 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign,
Inc. - For authorized use only/OU=VeriSign Trust Network
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte P
ersonal Freemail CA/emailAddress=personal-freemail@thawte.com
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte P
ersonal Premium CA/emailAddress=personal-premium@thawte.com
/C=US/O=First Data Digital Certificates Inc./CN=First Data Digital Certificates Inc. Certification A
uthority
/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte P
ersonal Basic CA/emailAddress=personal-basic@thawte.com
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority
/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign,
Inc. - For authorized use only/OU=VeriSign Trust Network
/C=HU/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLock Uzleti (Class B) T
anusitvanykiado
/C=US/O=GTE Corporation/CN=GTE CyberTrust Root
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
/C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Li
mited/CN=Entrust.net Secure Server Certification Authority
/C=HU/ST=Hungary/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLock Kozjegy
zoi (Class A) Tanusitvanykiado
/C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign,
Inc. - For authorized use only/OU=VeriSign Trust Network
/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Root
/C=HU/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLock Expressz (Class C)
Tanusitvanykiado
/OU=Copyright (c) 1997 Microsoft Corp./OU=Microsoft Corporation/CN=Microsoft Root Authority
/DC=com/DC=microsoft/CN=Microsoft Root Certificate Authority
---
SSL handshake has read 7991 bytes and written 740 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
SSL-Session:
    Protocol : TLSv1
    Cipher    : RC4-MD5
    Session-ID: 7F0A00002D0024D14CCB9D959D185669A22B6F9ECF613E75C0B9A7DD75DD436A
    Session-ID-ctx:
    Master-Key: A17E388F8744B03CAA268418A700F92B5BABDBD09908F8E5503B299579CA4C09A93CCEC5BBCB7BD2F39A
2C64EF36F674
    Key-Arg   : None
    Start Time: 1197061993
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
---

This is the default behavior for IIS 5.0 (Post MS04-011), IIS 6.0 and to my knowledge will remain so going forward with IIS 7.0 as well.

Wildcard SSL certificate in IIS 6.0, Windows 2003 Sp1 and above

Saurabh Singh — Sat, 17 Nov 2007 07:12:02 GMT

Here I will be talking about configuring SSL wildcard certificates in IIS 6.0 on Win2k3 SP1 and above. You may have a scenario wherein you want to have the same certificate installed for multiple Websites. Now in a normal scenarios this is not possible....(read more)

You get a Security Alert when you try to access an SSL enabled web site when certificate has been issued by an internal root CA...

Saurabh Singh — Thu, 08 Nov 2007 01:39:58 GMT

Let's say you have your own internal Root Certificate Authority (CA) and you use it to grant server certificates to your Web sites. You are able to browse to your web site over SSL and can access the page. Things look good so far. However you get an unwanted...(read more)

Troubleshooting SSL related issues with IIS

Saurabh Singh — Thu, 06 Sep 2007 00:52:00 GMT

In this post I am going to discuss troubleshooting SSL server certificate related issues in IIS. Please remember I am no SSL expert...I am an IIS Asp.Net guy and will discuss issues with regard to SSL with IIS.

We have seen a lot many times that the issues could have been resolved by our customers if they were aware of some targeted troubleshooting techniques.

Here I will be walking through the steps which you can follow yourself before requiring to call Microsoft PSS.

Problem Description

The most common error associated with SSL not working for an IIS website is "The page cannot be displayed" or "Cannot find server or DNS Error".

Troubleshooting steps to be followed:

First thing first: You notice the above error when you browse to your website over SSL (HTTPS). Do you also see the same behavior when you access the website over HTTP? If yes then there is a different problem you need to address first. SSL doesn't come into picture when we access a site over HTTP.
So if you are facing the problem in both the scenarios ensure you first troubleshoot why the request is not reaching the IIS server...maybe a DNS configuration etc.

My topic today is SSL with IIS so I won't be focusing on HTTP.

We have the SSL port listed in IIS mmc as shown below. By default it's 443. You can configure it to listen on a different port.

Now, also check whether the issue is happening for all the users, i.e. External and internal users to the network. If the issue is happening only for let's say external users check whether the requests are coming over a firewall like ISA etc. At times Firewalls may block the SSL port. You may want to check the firewall settings to unblock the SSL port. Also firewalls like ISA requires certificate to be published on it as well apart from IIS server. Ensure that the certificate that we have installed on ISA is valid. In case of ISA, if you have renewed the cert on IIS server but not on ISA users will still see the old certificate and not the new certificate. Ensure that you replace the old certificate on ISA with the new certificate. Also you may want to check if the security gateway (if any) such as NFUSE (Citrix) controllers is still referencing the old certificate.

Also at times if you see a wrong certificate being displayed for your Web Site, ensure that you do not have kernel-mode SSL enabled on your web server.Although this improves the performance but I recommend to have it disabled when you have multiple SSL enabled-websites on your server. Kernel-mode SSL is only recommended if you have just one site, mostly static content and no client certificates. In all other cases you should use User-mode SSL.

Please find this link to enable/disable kernel-mode SSL. If it is set to 1 it means Kernel-mode SSL is enabled, if absent or set to 0 it means disabled and user-mode SSL will be used. Ensure that you stop and restart http service as shown below after doing the changes. No reboot is required for the above change.

~~>net stop http~~

~~>net start http~~

~~>net start w3svc~~

[There has been few concerns from people as to why this is suggested. I do not have a proper answer to it at this point, but I have seen such issues in some support incidents where disabling Kernel mode SSL had resolved the above problem]

------------------------------------------------------------------------------------------------------------------------------------------------------------------

Now once you have isolated the issue to be only with HTTPS and all users let's proceed with the following steps:

Run netstat -an (or fport.exe) for IIS 5 (and netstat -ano for IIS 6) and verify whether IIS is listening on the SSL port.

When you start Internet Information Services (IIS) 6.0 on Microsoft Windows Server 2003, IIS binds to all IP addresses on the server, not just the IP addresses that are assigned to Web sites. This is because of socket pooling enabled for IIS by default.

On IIS 6.0, if the website is listening on "All unassigned" IP address or some specific IP address (like 192.134.123.209 etc) and SSL port 443, verify that Local address entry is 0.0.0.0:443 in netstat output.

> netstat -ano

Active Connections

Proto Local Address          Foreign Address        State           PID
TCP    0.0.0.0:21             0.0.0.0:0              LISTENING       2396
TCP    0.0.0.0:25             0.0.0.0:0              LISTENING       2396
TCP    0.0.0.0:80          0.0.0.0:0            LISTENING       4
TCP    0.0.0.0:81             0.0.0.0:0              LISTENING       4
TCP    0.0.0.0:83             0.0.0.0:0              LISTENING       4
    ...................

  TCP   0.0.0.0:443          0.0.0.0:0             LISTENING       4
TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
TCP    0.0.0.0:446            0.0.0.0:0              LISTENING       4

Here the PID should show you which process is listening on that port.
Now let's say I have configured my website to run on a specific SSL port and that port is being used by a different process, then website will not start up.

Also you won't see the netstat output showing anything like this depending upon the port being used:

TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 4

TCP 0.0.0.0:443 0.0.0.0:0 LISTENING 4

You can run netstat -ano again and see the PID corresponding to the process which is listening on that port. Stopping or disabling that service/process should allow Websites to be up and listening on the desired port. For IIS 5.x you can run Fport.exe to find out which process is listening on a specific port.

The first thing that I check for (strictly my personal preference) when we have issues with SSL is MACHINEKEYS. Yes, this is a very important (I prefer to call strategic) part of your checklist while dealing with SSL issues. In my personal experience it has resolved a lot of issues for our customers. By default machinekeys folder should have permission for Administrator, System and Everyone according to this KB278381. Ensure that we inherit the above permission for all child objects under the machinekeys folder, that way all the machine keys have the necessary permissions.

This is done by clicking the "Advanced" button on the security settings page, Clicking the check box "Replace permissions entries on all child objects...." and
Apply. This will propagate the settings to the contents in the folder.

Another reason for the above error ('The page cannot be displayed') can be if you do not have a private key corresponding to the SSL server certificate. You can check that by opening the IIS mmc -> <<YourWebSite>> ->Properties ->Directory Security ->Secure Communications ->View certificate ->General -> "You have a private key that corresponds to this certificate" as shown below.

If you do not see the above then SSL won't work for your website.
You can try running the following command to recover the private key from the certificate thumbprint.

To associate the certificate with its private key, we run the following command:

> certutil -repairstore my "c9 66 67 68 49 97 88 7f 05 b8 89 b7 b3 f7 37 c8 c4 da 5f 16"

Note: "c9 66 67 68 49 97 88 7f 05 b8 89 b7 b3 f7 37 c8 c4 da 5f 16" is the Thumbprint of the missing certificate. You can see this if you double-click on the .cer file, choose the Details tab and select Thumbprint.

Make sure you use the 2003 version of certutil.exe (with the associated certadm.dll and certcli.dll), or you will not have access to the repairstore command.

If the above command does not get back the private key or for some reason it still does not work you may prefer to get a new certificate from the CA.

One of the best tools that Microsoft has come up with is SSL Diagnostics to troubleshoot SSL related issues. Just download it to the IIS server and run it and if there is an error due to configuration of IIS or certificate it will show up. You can also use this tool to issue a test certificate for your website to check whether the problem was occurring because of your server certificate or some other IIS configuration related issues. Things that can be shown quickly through this tool includes on "no private key", "SSL port being used by a different process", "machine keys not having enough permission", "IP address conflicts" etc.

Another scenario can be wherein if you view the certificate, it will state that "You have a private key that corresponds to this certificate," and if you run SSL Diagnostics, you'll get the error as below:

#WARNING: You have a private key that corresponds to this certificate but CryptAcquireCertificatePrivateKey failed

When you initially go through the IIS Certificate Wizard to create a new certificate, a file is added to the MachineKeys folder. This is the private key.

If you add permissions to the new file in the MachineKeys folder before you process the pending request in the IIS certificate wizard, the certificate will work properly. If you've already gone past that point and got a new certificate, then necessary permissions should be added to the MachineKeys folder and a new certificate request must again be submitted.

Now consider a scenario wherein you are able to access the site through SSL Diagnostics tool (through 'Simulate SSL Handshake') for the same certificate but not through IE. What I mean is your SSL handshake gives no error etc in SSL Diagnostics although when you access the website through IE over SSL it still fails. In that case there could be an IE setting that you may want to check for such a behavior. Check this out KB811834.

Now one last scenario. At times we see customers coming up with requests wherein they want to use the same server certificate for multiple websites.

This is not possible. You cannot use the same certificate for multiple websites on the same server. Check this KB187504.

Now there is a workaround in IIS 6.0 Windows 2003 SP1, wherein you can use Wildcard certificates to get a similar functionality. Here is the link.

If you have a Load balanced or clustered environment you can export the same certificate to all the servers and install them on the related websites. It should work fine.

Hope this helps....let me know if there are any questions around the topic.

Cheers!!!

Client Certificate revisited....How to troubleshoot client certificate related issues

Saurabh Singh — Sat, 09 Jun 2007 19:18:00 GMT

Well, I am back to Client certificate again, guess the reason being a lot of support calls that we getting off late are related to any of the following four errors, especially the first two.

403.7

403.13

403.16

403.17 ( I will cover .16 and .17 very briefly since they are very self-explanatory and easy to troubleshoot)

Earlier I had discussed the setup of the client certificate with IIS and AD for authentication mapping etc.

Here I will discuss the troubleshooting strategies on client certificate related errors that are listed above.

To understand how Client certificate is used while accessing a resource on the server, you may prefer to look at this brief but quite explanatory KB by David Dietz from IIS support.

http://support.microsoft.com/kb/907274/en-us

So here we go...

1) 403.7

We see that 403.7 can be thrown by IIS when Client certificate is required and the browser is not sending the client certificate details to the web server (IIS). Either the client did not send the certificate for some reason or else the client did not have a certificate issued by a CA that was also trusted by IIS server. If the client sends a certificate which is not mutually trusted by both client and the server you may see this error.

You may get a meaningful error like this in the browser:

HTTP Error 403 403.7 Forbidden: Client certificate required
This error occurs when the resource you are attempting to access requires your browser to have a client Secure Sockets Layer (SSL) certificate that the server recognizes. This is used for authenticating you as a valid user of the resource.
Please contact the Web server's administrator to obtain a valid client certificate.

To start with, follow this KB http://support.microsoft.com/kb/332077/en-us

You need to make sure that the client certificate is issued by a CA which is in the trusted root CA store on both the server and the client machine. Confirm whether the trusted root CA is part of CTL. The reason being that if your certificate's CA is not in the CTL; although present in the trusted root CA store in the server machine, you may still see the error.

A CTL is a list of trusted certification authorities (CAs) that can be used for client authentication for a particular Web site . You can use CTLs to configure your Web server to accept certificates from a specific list of CAs, and automatically verify client certificates against this list. Only users with a client certificate that is issued by a CA in the CTL can gain access to the server.
Each Web site on your server can be configured to accept certificates from a different CTL. You may want to do this if you need a different list of trusted CAs for each Web site.

If CTL is present, this is the list which is actually used to check for CA's which can issue client certificate to a user. If it is disabled then root CA store will be used for the above. Also make sure that the certificate is a valid client certificate. Make sure it is intended for user authentication.

Check the certificate for "Ensures the identity of a remote computer" and Enhanced Key usage says Client Authentication.

Also Using >Certutil -verify -urlfetch should show:

Verified Application Policies:
1.3.6.1.5.5.7.3.2 Client Authentication

You may also see 403.7 due to an update to the trusted Root CA list. This creates a list that is too large based on the size limit we enforce, the result being truncation of the list when this is sent to the client during the client certificate handshake. The limit is based on data size not CA count so there is no way to say this happens at a certain count of trusted CA’s.
To resolve this we need to delete some of the expired and unused/unknown trusted root certificates from the Trusted Root Certification Authorities list until it is working again.

The problem can also be identified when the following entry is logged on the Web server. It is quite explanatory in itself.

Event Type: Warning
Event Source: Schannel
Event Category: None
Event ID: 36885
Date: 2/9/2007
Time: 9:32:44 AM
User: N/A
Computer: USMASVGDOIM259
Description:
When asking for client authentication, this server sends a list of trusted
certificate authorities to the client. The client uses this list to choose a client
certificate that is trusted by the server. Currently, this server trusts so many
certificate authorities that the list has grown too long. This list has thus been
truncated. The administrator of this machine should review the certificate
authorities trusted for client authentication and remove those that do not really
need to be trusted.

Trusted root certificates that are required by Windows Server 2003, by Windows XP,
and by Windows 2000
http://support.microsoft.com/kb/293781
931125 Microsoft root certificate program members (January 2007)
http://support.microsoft.com/default.aspx?scid=kb;EN-US;931125

2) 403.13

The error you may see in the browser will be as shown below:

HTTP 403.13 Forbidden: Client certificate revoked
The page requires a valid client certificate

For an understanding of this error message check KB 248058.

This error message means that the client sent a certificate, but either the certificate shows up as revoked in the issuing authority's Certificate Revocation List or the server could not retrieve a CRL from the issuing authority.

You need to crosscheck whether the client certificate is revoked or not with the respective CA.
If CA confirms the certificate as valid and not revoked then the issue could be with IIS being unable to retrieve CRL from the CA.

IIS , by default retrieves a CRL whenever it receives a client cert to make sure that cert is not revoked as long as local cache is expired. For this it contacts the CA to get the CRL which is a list of revoked certificates and compares the list with the presented client cert. If for any reason it cannot retrieve the CRL, it will go ahead and throw error message as 403.13 even if cert is valid and not revoked. This can happen in cases where some Proxy/firewall may block access to CDP to get the CRLs.

If a CDP extension is present in a certificate that is part of the certification path, IIS must be able to download at least one of the CRLs. If IIS is unable to resolve the CRL, it returns the HTTP 403.13 error. In this case, we cannot access the above CDP so we fail. Prior to MS04-011 Win2k did not limit validation based on this. However, we now require that the CDP be reachable when validating a certificate chain.
To work around this we must either use a reachable CDP in the client certificate or disable CertCheckMode on the IIS server, thus preventing it from doing any revocation checking.

So, if we are getting Client certificate revoked errors, then check to see if the server can get to the CRL distribution point specified in the client certificate and if it can and is still giving this error, then download the Root and Subordinate CA CRLs and install them on the IIS server so that it can get to it locally.

Also there is a metabase key in IIS called certcheckmode, which if disabled will stop IIS from trying to retrieve CRL checking. In such a case client cert will be accepted even if the cert is revoked. Disabling CRL checking is a quick way to test the cause.

The CertCheckMode property enables or disables Certificate Revocation List (CRL) checking. When CertCheckMode is set to a value greater than 0 (CertCheckMode>0), the CRL does not search for certificates that have been revoked. When CertCheckMode is equal to 0 (CertCheckMode=0), the CRL searches for certificates that have been revoked.

With CertCheckMode disabled, IIS will no longer try to verify revocation of incoming client certificate requests. The client certificates will still need to be within their valid dates and still must be trusted by the IIS server (the IIS server must trust the issuing CA).

We disable the Certcheckmode key by setting it to 1.

>C:\Inetpub\Adminscript\cscript.exe adsutil.vbs Set W3SVC/<Website identifier>/CertCheckMode 1

I had seen an interesting case where 2 of the websites were accepting the same client cert whereas another one was not accepting it on the same web server.

Checking the metabase.xml for the server showed this:

Non-Working site:

=================

<IIsWebServer Location ="/LM/W3SVC/690402"

AuthFlags="0"

LogPluginClsid="{FF160663-DE82-11CF-BC0A-00AA006111E0}"

SSLCertHash="8bcfc28e346bb9ec49374d87479021354349cf85"

SSLStoreName="MY"

SecureBindings="XX.XX.XX.X:443:"

ServerAutoStart="TRUE"

ServerBindings="XX.XX.XX.X:80:"

ServerComment="CDB"

</IIsWebServer>

Working Site:

=============

<IIsWebServer Location ="/LM/W3SVC/90326589"

AuthFlags="0"

CertCheckMode="1"

LogPluginClsid="{FF160663-DE82-11CF-BC0A-00AA006111E0}"

SSLCertHash="a640634e38ff20ebd8c29c32aae635e5575e57f6"

SSLStoreName="MY"

SecureBindings="XX.XX.XX.Y:443:"

ServerAutoStart="TRUE"

ServerBindings="XX.XX.XX.Y:80:wcdb"

ServerComment="WCDB"

</IIsWebServer>

Look at the difference between them. You see CertCheckMode is absent in the Non-working site, and absence of this key is equivalent to it being enabled. So once we put the CertCheckMode set to "1" for non-working site we should be able to resolve the issue. But this means that CRL chekcing is disabled. You may downlaod the CRL on to the server or else open up the relevant ports in order to allow CRL to be retrieved.

Check the KB 294305.

You may also check KB 841632 if IIS 5.0 is in picture.

There was an interesting case, where users were getting 403.13 even when client cert was not revoked and we were able to access the get the CRL from the CDP for the client cert by accessing it through a browser. Yet after a lot of tracing and monitoring we found that there was a 4-level hierarchy in the certificate chain, with let's say Root CA1 ->Subordinate Root CA2->Subordinate Root CA3 -> Client certificate and one of the subordinate root CA's crl was not accessible. There are tools like certutil or SSLspy that can come handy. We ran certutil.exe -verify -urlfetch <location of the client cert.cer> on the IIS server and found that CRL retrieval for Subordinate Root CA2 was failing, and hence the issue.

So remember that we need to make sure that the CDPs for all the subordinate CAs certifcates in the chain should also be reachable.

Let's say for my client certificate, the Certification path shows:

Microsoft Corporate Root CA

|--> Microsoft Corp Enterprise CA 2

|--> Saurabh Singh

Here is the information for certificate "Saurabh singh"

CRL Distribution Points (Under Details->Field) shows:

[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=ldap:///CN=Microsoft%20Corp%20Enterprise%20CA%202(4),CN=CRL,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=corp,DC=microsoft,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint
URL=http://corppki/crl/Microsoft%20Corp%20Enterprise%20CA%202(4).crl
URL=http://crl.microsoft.com/pki/mscorp/crl/Microsoft%20Corp%20Enterprise%20CA%202(4).crl

Authority Information Access shows:

[1]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://corppki/aia/Microsoft%20Corp%20Enterprise%20CA%202(4).crt
[2]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://www.microsoft.com/pki/mscorp/Microsoft%20Corp%20Enterprise%20CA%202(4).crt

Here is the information for certificate "Microsoft Corp Enterprise CA 2":

CRL Distribution Points (Under Details->Field) shows:

[1]CRL Distribution Point
Distribution Point Name:
Full Name:
URL=http://corppki/crl/mscrca.crl
URL=http://crl.microsoft.com/pki/mscorp/crl/mscrca.crl

Authority Information Access shows:

[1]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://corppki/aia/mscrca.crt
[2]Authority Info Access
Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
Alternative Name:
URL=http://www.microsoft.com/pki/mscorp/mscrca.crt

Now runnning the Certutil.exe as shown below:

cmd prompt> certutil.exe -verify -urlfetch cert.cer <-------the client certificate

Here is the output:

Issuer:
CN=Microsoft Corp Enterprise CA 2
Subject:
CN=Saurabh Singh
Cert Serial Number: 258a555c0004008b1c42

dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
ChainContext.dwRevocationFreshnessTime: 176 Days, 6 Hours, 5 Minutes, 17 Seconds

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 176 Days, 6 Hours, 5 Minutes, 17 Seconds

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=Microsoft Corp Enterprise CA 2
Subject: CN=Saurabh Singh
Serial: 258a555c0004008b1c42
Template: AutoEnrolled Client Auth
48 b7 48 da 00 51 21 77 b3 e1 3a ce 98 7d 35 2f b7 e8 0c 1c
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
Verified "Certificate (0)" Time: 1
[0.0] http://corppki/aia/Microsoft%20Corp%20Enterprise%20CA%202(4).crt

Verified "Certificate (0)" Time: 1
[1.0] http://www.microsoft.com/pki/mscorp/Microsoft%20Corp%20Enterprise%20CA%202(4).crt

---------------- Certificate CDP ----------------
Verified "Base CRL (821)" Time: 0
[0.0] ldap:///CN=Microsoft%20Corp%20Enterprise%20CA%202(4),CN=CRL,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=corp,DC=microsoft,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint

Verified "Base CRL (821)" Time: 0
[1.0] http://corppki/crl/Microsoft%20Corp%20Enterprise%20CA%202(4).crl

Verified "Base CRL (821)" Time: 1
[2.0] http://crl.microsoft.com/pki/mscorp/crl/Microsoft%20Corp%20Enterprise%20CA%202(4).crl

---------------- Base CRL CDP ----------------
No URLs "None" Time: 0
--------------------------------
CRL 821:
Issuer: CN=Microsoft Corp Enterprise CA 2
fd 19 3c 2f 0c 24 ea 1c 4a 5d df c4 26 2a b0 1b 98 48 ef 99
Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication

CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=Microsoft Corporate Root CA, O=Microsoft Corporation
Subject: CN=Microsoft Corp Enterprise CA 2
Serial: 610d1de0000000000019
Template: SubCA
17 0a 7b 9d 52 85 07 7e 74 1a f5 a0 6b db 05 78 9e bc f1 8d
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
No CRL "Certificate (0)" Time: 0
[0.0] http://corppki/aia/mscrca.crt

No CRL "Certificate (0)" Time: 1
[1.0] http://www.microsoft.com/pki/mscorp/mscrca.crt

---------------- Certificate CDP ----------------
Verified "Base CRL (18)" Time: 0
[0.0] http://corppki/crl/mscrca.crl

Verified "Base CRL (18)" Time: 0
[1.0] http://crl.microsoft.com/pki/mscorp/crl/mscrca.crl

---------------- Base CRL CDP ----------------
No URLs "None" Time: 0
--------------------------------
CRL 18:
Issuer: CN=Microsoft Corporate Root CA, O=Microsoft Corporation
0e 70 65 69 a7 4c f9 7d 9f 50 7b db 9c e1 b8 27 9e 53 ba f4

CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=Microsoft Corporate Root CA, O=Microsoft Corporation
Subject: CN=Microsoft Corporate Root CA, O=Microsoft Corporation
Serial: 443c2a54b59cd69d4c09b18a9b02eb55
d2 d3 8e ba 60 ca a1 c1 20 55 a2 e1 c8 3b 15 ad 45 01 10 c2
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
No URLs "None" Time: 0
---------------- Certificate CDP ----------------
No URLs "None" Time: 0
--------------------------------

Exclude leaf cert:
8a cf e9 23 e2 d7 cd d1 f0 bb 05 6e 63 b5 31 95 6e 46 0d ad
Full chain:
5b fa 04 32 34 21 49 11 92 56 b3 ee 41 94 b4 b8 f3 f6 44 f2
------------------------------------
Verified Issuance Policies: None
Verified Application Policies:
1.3.6.1.5.5.7.3.2 Client Authentication
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.

If you notice the Certutil.exe tries to check the CRL accessibility by accessing the CRL Distribution points. The above command ouptput should give you an idea regarding the cause. You may see an error in accessing the CRL in the output above in cases where you get the above errors.

Here is something similar when you get an error:

---------------- Certificate CDP ----------------

Failed "CDP" Time: 0

Error retrieving URL: The specified network resource or device is no longer available. 0x80070037 (WIN32: 55)

ldap:///CN=CRL1, CN=xxxx, OU=xxxx, OU=xxxx. by ref. (limits liab.), O=xxxx, C=US?certificateRevocationList;binary,authorityRevocationList;binary,deltaRevocationList;binary

Failed "CDP" Time: 0

Error retrieving URL: The server name or address could not be resolved 0x80072ee7 (WIN32: 12007)

http://www.some_company.net/CRL/net1.crl

--------------------------------

Application[0] = 1.3.6.1.5.5.7.3.4 Secure Email

Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication

Application[2] = 1.3.6.1.5.5.7.3.2 Client Authentication

Application[3] = 1.3.6.1.5.5.7.3.3 Code Signing

Exclude leaf cert:

14 4c 46 42 11 66 a4 a9 42 70 ad b6 e0 1e 23 ca d4 9b 24 0e

Full chain:

fe 37 4a cf 76 3e 01 14 21 a6 c7 25 35 14 97 e5 91 87 e3 b7

Issuer: CN=A company, OU=PKI, DC=company, DC=com

Subject: OID.0.9.2342.19200300.100.1.1=ZALDI001, OU=People, OU=SAP, DC=company, DC=com

Serial: 42c550de

6e 33 5f 13 e1 67 ad 41 71 02 96 17 c7 57 c9 91 ea cb 1d 24

The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)

------------------------------------

Revocation check skipped -- server offline

Cert is an End Entity certificate

ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)

CertUtil: The revocation function was unable to check revocation because the revocation server was offline.

Ensure that the necessary firewall/network configuration changes to allow the IIS server to access ALL of the external CDP’s listed in the client cert’s revocation chain, or download the CRL(s) to the IIS server manually and set CertCheckMode to MD_CERT_CACHE_RETRIEVAL_ONLY (see this link http://technet2.microsoft.com/windowsserver/en/library/173427fd-eb90-44ef-8a9c-d7bb4ff41ab81033.mspx?mfr=true ). That will tell IIS to look at the CRL in its local store and not try to attempt to access the CRL via the CDP entries specified in the client cert.

One more confusing point that should be clarified here:

If you have a certificate chain, let's say: Root CA -> Intermediate CA1 -> Intermediate CA2 ->..... -><Your Client ceritficate>, then CRL checking will be done for all the Certificates in the hierarchy except the Root CA.

If you are really interested to dig further as to how Certificate Revocation etc. works at a lower level, here is a real exhaustive link to check it out.

http://technet.microsoft.com/en-us/library/af1e419e-ede5-8c4b-bf6e-1fb17658a99d.aspx

Another issue that pops up from time to time is:

"Choose a digital certificate" popup window in Internet Explorer is blank when attempting to use client certificates to authenticate against IIS.

This can happen in situations as explained earlier too in cases where:

The total size of the certificates in the Trusted Root Certification Authorities store on the IIS server was too large to send to the client. The list was truncated as a result.

The following event was written to the System log:
Event Type: Warning
Event Source: Schannel
Event ID: 36885
Description: When asking for client authentication, this server sends a list of trusted certificate authorities to the client. The client uses this list to choose a client certificate that is trusted by the server. Currently, this server trusts so many certificate authorities that the list has grown too long. This list has thus been truncated. The administrator of this machine should review the certificate authorities trusted for client authentication and remove those that do not really need to be trusted.

Resolution would be to Remove unused certificates from the Trusted Root Certification Authorities store on the IIS server, reducing the number of certificates.

Also another cause may be when the any of the Subordinate CAs->certificate->Details->Edit Properties button has Client Authentication disabled in the intended purposes.

Also this should be of help at times http://support.microsoft.com/kb/285069/

Also if we have certificate trust list(CTL) enabled, CTL that IIS sends is what the client uses to know if it has a client cert it can use.
Also there is a <12kb> limit on this and if the customer has applied the Trusted Root CA update, then we may not send the full list of trusted CA’s. Make sure that CA is in CTL as well as the size limit. You may want to revisit the article http://support.microsoft.com/kb/933430. Either install the hotfix if it is applicable or try deleting/moving to other store some of the unused/junk CAs from the Trusted Root Certificate Authority Store on the IIS server. That could do the trick for you!

Refer to one of our finest Escalation engineer (Andreas Klein)'s blog which talks about limiting the list of CA's allowed for Client authentication, without deleting the CAs from the store.

http://blogs.msdn.com/andrekl/archive/2005/04/19/409682.aspx

Also while you may have the certificate in your personal store (using the mmc snap-in it shows up properly), you may not see it in the IE browser. If you go through Internet Options->Content and click Certificates, it doesn’t show up at all. Open the certificate MMC and check whether the cert has a Private key or not.

If the General tab on the cert properties does not say at the bottom that you have a Private Key corresponding to this cert then you don’t, and this may lead to the above problem.

403.16 - Client certificate is untrusted or invalid.

This error message is primarily generated when the certificate that the client provided is improperly formed. It can also be generated if there are intermediate certification authorities in the certificate chain that are not trusted by the Web server.

403.17 - Client certificate has expired or is not yet valid

This error message is fairly self-explanatory. It means that the current date on the server is not within the valid date ranges that are presented in the client certificate. You may also want to ensure that the client certificate and its issuing CAs (including Intermediate CAs) are not expired or invalid.