SSL: Inside & Out (well, as much as I know!)

 

Introduction 

The one thing that makes me proudest is the release of tool called ssl diagnostics 1.0. 

I recently reliazed that there were 100’s of customer’s of Microsoft didn’t realize we released these tools.  For the most part, I am talking about tools in the diagnostics area of IIS and what we (Microsoft) call the IIS Diagnostics Toolkit.

In 2003, I was approached by Uladmir (ulad), a tester on the iis team, and Satisha (his boss) asking why SSL issues were top issues in Product support (pss).

In mid-july of 2003 after months of development and testing, microsoft released SSl diagnostics 1.0.   This tool released independently on the web on Microsoft’s download center.

This tool allows the following which i will cover in the next few days”

  • verify that the SSL Filter is loaded properly based on iis version
  • Ensure that the port, based on the iis configuration, is set correctly
  • Will review the SSL Cert Hash assigned to the website to ensure it is accurate
  • Look directly at the ssl certificate, part of windows. is accurate and working

Secure Socket Layers & IIS 4.0, 5.0, and 5.1 – Filter

SSL was implemented as a single instance filter loaded in the core web service Inetinfo.exe.  This filter, called sspifilt.dll, is loaded as a global filter and status can be viewed using typical utilities such as tlist (resource kit utility) or sometimes using the IIS Manager.  The sometimes indicates that there have been historically some issues with false positives by the IIS Manager whereby it shows the filter status as *unknown* or Loaded when in fact it was the opposite.  Hence, the best and safest approach is to use TList or another method.

If the SSL filter is not loaded in the Inetinfo process then all SSL requests will fail to work as no work can be performed on the request since it is encrypted.  It is important to understand that the HTTP protocol is a text-based protocol and hence any binary data presented to IIS will be mis-understood, or better said, disregarded.  The filters primary responsibility is to capture the request and marshal it to the LSASS.exe process for all decryption\encryption work to be completed.  Upon completion, the HTTP request complete with all headers and body are returned to Inetinfo for processing.

The easiest, and most approachable, method to find out the status of the filter is to avoid using TList as indicated above and use the SSL Diagnostics tool.  SSL Diagnostics 1.0 has the ability to identify that status of this filter using the User Interface or via command-line.  For demonstration purposes, I will display the command-line means -

ssldiag -log

This will produce a log file in the running directory for SSLDiag (by default, %programfiles%\iis resources\ssldiag) that can be viewed using your favorite text editor.  To determine if the filter is loaded, simply look for the following:

sspifilt.dll loaded into process 464 (Inetinfo.exe)

If this value says not loaded then you have a problem.

SSL on IIS 4.0, 5.0, and 5.1 – Port (SecureBinding)

The most common failure or problem with SSL issues on these legacy versions of IIS is the lack of a correctly defined binding.  IIS stores a binding per site in the configuration, metabase.bin, called ServerBindings & SecureBindings.  The one we are concerned about in the realm of SSL is the SecureBindings property that controls what IP address, Port combination to use for SSL connections. 

This property will be passed to the connection manager which is Winsock in Windows NT 4.0 & 2000.  The often confused and failed mistakes are caused by the lack of definition of the SSL port and\or the use of a invalid port such as one that is already assigned to that unique endpoint. 

All said and done, the most effective means of determining if you have an invalid port configuration is to check the actual port status using the following:

netstat -an

This will indicate the IP addresses and ports which are being listened on.  SSL Diagnostics can also help you as it will indicate to you when you have failure to set a port such that the following will be listed in the log file –

#WARNING:Incorrect SecureBindings

To correct this problem, you can use either the IIS Manager and set the SSL port, or by using the following command using ADSUTIL.vbs -

cscript adsutil.vbs set w3svc/{site instance}/SecureBindings “:{port #}:“

Secure Socket Layer & IIS 6.0

You will quickly notice that there is a new service on Windows Server 2003 called HTTP SSL Service if you view the services applet in Administrative Tools.  This is different from previous versions of the operating system and IIS.  This service is designed to be loaded by the HTTP.sys driver and W3SVC service when they start, hence, the reason it is set to a Manual as the startup.

The filter name, previously called sspifilt.dll, is now called & loaded in a different process.  LSASS.exe is responsible for hosting the filter and also communicating directly with the HTTP.sys kernel driver.  As for the name, the new name is strmfilt.dll and it does not load in the worker process (w3wp) or inetinfo processes as was the design in past versions.

Very much like discussed yesterday, SSL Diagnostics 1.0 can determine if the filter is loaded successfully or not.  It will tell you also the process it is loaded in for assistance in any diagnostics you might be doing.

“The parameter is incorrect” & SSL

One of the very first things one might notice with IIS 6.0 is the beginning of a strict binding rule whereby IIS websites will fail to start if a HTTPS binding is invalid.  By invalid, I mean that there is a conflict with another site or the value set in the SecureBindings property is invalid.  The simplest means to see an error in this state is to have two sites, both with a certificate installed, bound to the very same SSL port.  In most cases this will be port 443 which is most common for SSL.

The error thrown when  you attempt to start the 2nd site is “The parameter is incorrect.”  The one unforunate aspect of this error is we (IIS) doesn’t give a good indication of what parameter we are talking about.  Thus, often users are struggling to understand why the failure is occurring.

This is caused by IIS 6.0’s strict rules that both a valid ServerBindings & SecureBindings metabase property exists.  If one, or both, are invalid then the conflicting site will fail to start.  This is very similar to DHCP’s ability to sometimes assign the same IP address hence causing an error on the 2nd and beyond computers.  This can be detected by SSL Diagnostics 1.0 using both the User Interface or log-mode and will do so by issuing a error\warning depending on the problem.  The problem might be caused by one of the following:

    a).  The SecureBindings property conflicts, exactly, with another site’s configuration

    b).  The SecureBindings property is invalid, hence, not conflicting but instead invalid

These are both usually easy to detect based on events thrown to the Event Viewer and with a smart eye you will be able to determine what is invalid and the cause.  To correct this, ensure that the binding set for SecureBindings for Site A is different and unique from Site B, and so forth.

In the end, IIS 6.0 is powerful and very much architected similar to previous versions though with slight difference.  The biggest difference is related to IIS 6.0’s changes in the worker process where the filter is loaded, along with the name.  Later this week I will discuss a bit further a new Service Pack 1 feature called Kernel SSL, but beyond that, most of the concepts & diagnostics can be done similar to previous versions of IIS.

One-way Identification:  Server Certificates

The use of Secure Socket Layers (SSL) requires the use of certificates which are either stored on the local machine or on another source such as a smart card.  The typical deployment of IIS & SSL uses the local computer and the local registry to store the certificate.\

This certificate aims at identifying to the client (i.e. browser) who the server is in the form of a certificate.  The certificate sends 3 key pieces of data:

  • Certificate Issuer (the Certificate Authority)
  • Certificates expiration date
  • The websites identifier, or better known, URL

All of the above is transfer after the client & server have already negotiated and determine the SSL session’s communication such as the cipher, etc.  For the purpose of this blog, I will assume that the connection can be successfully negotiated.  The server certificate is the culmination of the site’s owner providing information such as Organization, Organizational Unit, and the location of the owner.  This is merged together with the Certificate Authorities public key.  This is the information that is passed between the server & the client during the initial handshake.

Client’s, such as Internet Explorer, can choose whether or not to continue the connection based on the users input.  This option started after Internet Explorer 4, but prior to that, the connection would automatically be rejected with an error.  This continues to today’s version of IE 6.

Two-way Mutual Identification (Authentication):  Client Certificates

A very secure mechanism for authentication is to use client certificates.  This certificate, just like its sister server certificates, can be stored on the server or on another device.  The difference is the location of this certificate and the role it plays during the SSL handshake.  Client certificates can only be used when SSL is already enabled thus it has a dependcy on server certificates.

In IIS’s default configuration, client certificates are completely ignored.  Thus, the browser can store client certificates but IIS will indicate during the handshake that it is not accepting (ignoring) client certificates.  IIS’s configuration has the following options:

  • Ignore Client Certificates
  • Accept Client Certificates
  • Require Client Certificates

Each one of these are determined by the following value in the IIS configuration property – CertCheckMode – and these can be changed using the IIS Manager or using scripting technologies such as adsutil.vbs (%systemdrive%\inetpub\adminscripts).

When using client certificates, the first step is to negotiate and complete the server certificate process.  At the successful completion of this process, the client certificate authentication process will begin.  At this point, the user can choose the client certificate to send to the server and the client will transmit the certificate information to the server at which the server will parse the same information the client does.  In this case, the server determines whether it trusts the Certificate Authority who issued the client certificate, as well as the certificate is not expired.  This is how the server goes about determining the identity of client.

In this situation, IIS can have all authentication types disabled and the server still function.  This is based on the notion that the server certificate & client certificate ensure the identity of the client.

Building and creating Certificates

For 80% of SSL users, the process of creating a certificate are done using the help of the IIS Manager.  This wizard-based process helps obtain the correct information from the user and place that in a file that can be sent to the certificate authority.  In some environments, Active Directory enabled systems can submit the certificate immediately to the Certificate Authority.  This is in situations where an implementation of Microsoft’s Certificate Server has been installed and configured.

The other 20% of users will deploy certificates by importing them from another system, or create the certificate using the Certificate snap-in.  You can create the certificate snap-in by doing the following:

   1).  Click Start —> Run —> MMC

   2).  In the Microsoft Management Console (MMC), click File —> Add\Remove Snap-in

   3).  Click Add

   4).  Locate Certificates and click Add

   5).  After clicking Add, you will be asked whether to load the certificates for the local computer (HKey_Local_Machine), User (HKey_Current_User), or a service.  Choose local computer for management of server certificates, or User for management of client certificates.

   6).  After going through the wizard, close the Add\Remove Snap-in

You can find these instructions using the article – How to add the Certificates Snap-In to the MMC

You can now manage certificates that exist on the local computer.  The certificates are loaded under the Personal section, and drilling down here will do the trick to locate the certificates.  You can step through creating the certificates by making a certificate request as indicated above, but you can truly simplify this by using tools such as SelfSSL and IIsCertDeploy.vbs.

SelfSSL is part of the IIS 6.0 Resource Kit Tools and allows you to create a certificate that can be deployed to your website.  This is a sample command you can use to create the certificate:

selfssl /n:cn=www.contoso.com /t /s:1

/n = The common name, or in this case the Fully Qualified Domain Name.  This can also be a IP Address.

/t = This adds to that local computer this certificates “common name” to the Trusted Root Certificates

/s = This instructs, after creating the certificate, SelfSSL to bind this certificate to the site listed (in this case, 1, which is Default Web Site)

After creating this certificate, you can use IIsCertDeploy.vbs (also part of the IIS 6.0 resource kit) to export and deploy this certificate to another server.  This is useful in web farm scenarios.  The command that you will use to do this is as follows -

Export Certificates:

IIsCertDeploy.vbs -e .pfx -I w3svc/# -p pfxpassword

Import Certificates:

IIsCertDeploy.vbs -c cert.pfx -p pfxpassword -i w3svc/1 -s servertoimportto -u administrator -pwd 123456

This only grazes on the surface of the fascination that is called certificates.  However, for IIS users out there, it should give you a good start on how to effectively implement IIS.

Resources

~Chris

No Comments