Client Certificates V/s Server Certificates

In the past I have blogged about various certificate file extensions along with their usage. Here is the link: http://blogs.msdn.com/b/kaushal/archive/2010/11/05/ssl-certificates.aspx

I use blogs as reference so that they can refer the content and I need not repeat the same thing every time. Saves time and helps others too.

This time I thought of writing another blog explaining the difference between Client Certificates and Server Certificates. Something which is not clearly understood by everyone. I will be discussing this strictly in context of IIS only. (There are several types of certificates)

One of my colleagues, David Dietz has already published a KB article relating to this:

IIS and client certificates: http://support.microsoft.com/kb/907274

The above documentation is good enough to understand the difference between client and server certificates along with error messages associated with them.

Lets start off in an Layman’s language and then I’ll discuss it in complete depth.

How are Client and Server Certificates different?

Server Certificates: Server Certificates are used to identify a server. Typically they are issued to hostnames, which could be a machine name (like “PIIS-SVR01”) or a host-header (like “www.Microsoft.com”). Both client and server certificates have the “Issued to” section. For a server certificate the “Issued to” section’s value would specify the hostname for which it has been issued.

Server Certificates serve the purpose of encrypting and decrypting the content.

</p>

Server Certificate

</font></font></a>

Read the highlighted text in the above certificate, it says “Ensures the identity of a remote computer” i.e., “localhost”. This is a self-signed certificate i.e., one issued a certificate to itself. (To be precise where the “Issued to” and the “Issued by” value is same. In the real world only Root-CA’s have self-signed certificates).

Server certificates are stored in the Personal store of the “Local Computer” account.

Note: Certificates can be put in the personal store of a user account. However IIS will always search for the server certificate in the personal store of computer account.

Client Certificates: Client certificates as the name indicates are used to identify a client or a user. They are meant for authenticating the client to the server. In case of a client certificate the value of this field would be set to a users name.

Yes, I know it is a certificate too, but it is not used for encryption or decryption of data, but represents a user identity. Smile Below is a Client Certificate which I issued to myself using my CA (KAUSHAL-CA).

Client Certificate

As seen above, the line is more than enough to inform you about the purpose of the certificate. It reads “Proves your identity to a remote computer”. Here ‘your’ means the user (Kaushal in this context).

How are Client and Server Certificates Similar?

The only similarity between them is the keyword “Certificate”. They both contain public and private keys. For that matter, every certificate contains a public and a private key.

How does IIS distinguish between Client and Server Certificates?

The above explanation was good enough to explain a user on how to identify client and server certificates. However, this is not how IIS determines it. The best way of determining the purpose of a certificate is to look at its “Enhanced Key Usage” field. (this is a optional field and may not be seen for all the certificate types).

The Enhanced Key Usage field specifies what can the public key of the certificate be used for. If the value is set to “Client Authentication(1.3.6.1.5.5.7.3.2)”then you know what it is used for. Smile

For Server Certificates the value of this filed would be set to:
“Server Authentication (1.3.6.1.5.5.7.3.1)”.’

Every certificate has a Object Identifier (OID) associated with it. If you observed the OID for server certificate is “1.3.6.1.5.5.7.3.1” and for Client Certificate it is “1.3.6.1.5.5.7.3.2”.

Here is a snippet from RFC 3280

</p>

Housley, et. al. Standards Track [Page 40]
RFC 3280 Internet X.509 Public Key Infrastructure April 2002
</p>

id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }

ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId

KeyPurposeId ::= OBJECT IDENTIFIER

Key purposes may be defined by any organization with a need. Object identifiers used to identify key purposes MUST be assigned in accordance with IANA or ITU-T Recommendation X.660 [X.660].

This extension MAY, at the option of the certificate issuer, be either critical or non-critical. If the extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. Certificate using applications MAY require that a particular purpose be indicated in order for the certificate to be acceptable to that application.

If a CA includes extended key usages to satisfy such applications, but does not wish to restrict usages of the key, the CA can include the special keyPurposeID anyExtendedKeyUsage. If the anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT be critical.

If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions. If there is no purpose consistent with both extensions, then the certificate MUST NOT be used for any purpose.

The following key usage purposes are defined:

anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }

id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }

</font>id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
— TLS WWW server authentication
— Key usage bits that may be consistent: digitalSignature,
— keyEncipherment or keyAgreement </p>

</font></font></font>id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
— TLS WWW client authentication
— Key usage bits that may be consistent: digitalSignature
— and/or keyAgreement </p>

</font>id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
— Signing of downloadable executable code
— Key usage bits that may be consistent: digitalSignature </p>

id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
— E-mail protection
— Key usage bits that may be consistent: digitalSignature,
— nonRepudiation, and/or (keyEncipherment or keyAgreement)

id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
— Binding the hash of an object to a time
— Key usage bits that may be consistent: digitalSignature
— and/or nonRepudiation

id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
</font>— Signing OCSP responses
— Key usage bits that may be consistent: digitalSignature
— and/or nonRepudiation

</td> </tr> </tbody> </table></div>

snippet of RFC describing the various Object ID’s associated with certificates.

How do I know what is the Enhanced Key Usage value for that certificate?

Double click on the certificate to view it. FYI, it opens with “Crypto Shell Extensions”.

Go to the Details tab and select “Extension Only” from the “Show” drop down box as shown below:

This is a clear indication of the intended purpose of the certificate.

Can I use a Server Certificate as a Client Certificate or Vice-Versa?

NO is the answer to this question and its very obvious. If you try importing a client certificate to the IIS 7/7.5 you will receive the following error:

Note: There are certificates which can be issued for multiple purposes like the one shown below. This is meant for both Client and Server Authentication.

Hope this cleared some doubts! Smile