Creation and deployment of self-signed certificates for a two-machine scenario

Question

Let us assume that I have two computers:

• client
• server

Now, in the server computer, I set up a legacy ASMX web service which will going to be used by the client. Before the client can connect to to the web service, however, I want him to be authenticated using digital certificates.

So I do the following:

1. Create a self-signed certificate on the server (certification authority)
2. Install the certificate in the Trusted Root Certification Authorities on the server (through MMC).
3. Install the certificate in the Trusted Root Certification Authorities on the client (through MMC).
4. Generate a certificate (based on the self-signed certificate) for the web service application and install it in the Personal certificates section (through MMC) on the server machine.
5. Generate a certificate (based on the self-signed certificate) for the client and install it in the Personal certificates section (through MMC) on the client machine.
6. When the client communicates with the server using the web service, the two entities exchange certificates for authentication.

Is the procedure highlighted above correct? I am asking this because I found a lot of articles overloaded with information and which fail to describe the basics in a simple manner.

Answer 1

Your principles are correct, but the particulars can be a devil to set right.

Indeed, the general schema is that:

• The client needs to validate the certificate from the server, i.e. verify that the certificate has been issued (signed) by a trusted CA, and that the alleged server certificate contains the name of the server.

• Similarly, the server needs to validate the certificate from the client, i.e. verify that the certificate has been issued (signed) by a trusted CA, and then obtain the "client name" from the certificate.

So both client and server need to trust some root CA certificate -- not necessarily the same (but it does not hurt that they both trust the same). Moreover, both client and server can be a bit picky about what they find in their own certificate, and in the certificate from the peer. The server certificate will have to contain the server name as prescribed by RFC 2818 (section 3.1). If you include the Extended Key Usage extension, then IIS and Internet Explorer will tend to require the "server authentication" key usage (1.3.6.1.5.5.7.3.1). For the client certificate, IE and IIS will again want to see a specific key usage, namely "client authentication" (1.3.6.1.5.5.7.3.2).

The server (IIS) must also make something out of what it finds in the client certificate. There are several methods. "Account mapping" is about associating the client certificate with a client account, accounts being the notion of identity which prevails within a Windows operating system. If an Active Directory domain is in force, the mapping can be direct (the certificate is mapped to the account which, on the AD server, contains a copy of the certificate) or indirect (the certificate contains a copy of the User Principal Name of the account, in its Subject Alt Name extension). Non-mapped authentication is possible, too, in which case the application is responsible for making sense of the certificate.

Certificate revocation can be a problem, too. Conceptually, a CA who has issued a certificate can "express remorse", and announce to the World at large that a given certificate, though seemingly all signed and signed and valid, must nonetheless be rejected. This supports emergency situations such as a stolen private key. This announcement uses a Certificate Revocation List, a short-lived object signed by the CA. Both the server and the client may want to obtain a fresh CRL which covers the certificate they are trying to validate. Your homemade PKI does not publish CRL regularly, so if the client or the server gets into its head to verify revocation status, things will fail.

Whether IIS and/or IE will engage into revocation check depends on what they find in the certificates, but that's not documented with the utmost clarity. IIS can be configured to disregard revocation checks. For Internet Explorer, this can also be done, apparently on a zone basis (IE categorizes servers in "zones", such as "local intranet" or "Internet", and can apply different security settings for each zone, one of which being "enforce revocation status check").

This blog post seems to cover your situation. I suggest you follow its indications. Don't fiddle with revocation unless you get some error messages stating that some revocation status check could not be obtained, in which case you may have to build a CRL and push it on both client and server (with mmc.exe), or deactivate revocation checks (as indicated above).