A practical example of a client certificate authentication deployment.

Scenario:

The link between the client and the ProxySG is to be negotiated using HTTPS, while the link between the ProxySG and the OCS is to be HTTP. This is easily handled by the ProxySG when using the reverse proxy configuration, which is explained in other KB articles. The focus here is the client certificate.

The idea is that only computers possessing this client certificate would be able to reach the OCS (Original Content Server) in question

There are four major steps to achieve the above:

1. Define an appropriate CCL (CA Certificate List)

2. Define an HTTPS reverse proxy service

3. Define a certificate authenticate realm

4. Define appropriate CPL

Going into a bit more detail on the above steps:

1. Define an appropriate CCL (CA Certificate List)

In order for this to work, the appropriate certificates must be issued and imported into the participating network nodes. A brief summary of certificates needed:

• A certificate of type “webserver” must be issued to the ProxySG. Note: if you do not use a certificate of type “webserver” (i.e. with the correct constraints) IE will work, but FF will complain. This webserver certificate is known as the “keyring”. In my example, I chose to name this certificate and keyring as “proxy123”
• The root CA certificate, and any intermediate CA certificates, must be imported into the ProxySG under SSL > CA certificates.
• The correct client certificate of type “user”, issued by the same CA, should be given to the client and imported into their certificate store. This certificate is usually distributed in “pfx” format and requires a password to import.

For IE to work, you must create a separate CCL list (SSL > CA certificates > CA certificate Lists). Within this CCL, add only the CA that was used above. This is critical for IE to work because during the SSL/TLS negotiation, the proxy sends a list of all the CAs that it trusts, so that in turn the browser can send the correct client certificate. If this CA list is too long, it will span multiple handshake messages, which IE doesn’t like. So we instruct the Proxy to send only one CA in the list (via the CCL), which will fit in one message and so IE won’t complain. In this example, I have called the CCL "reverse_sg".

2. Define an HTTPS reverse proxy service

As previously noted, we definitely need reverse proxy setup, to convert between HTTPS and HTTP. There is plenty of documentation on how to set this up properly, but one thing of note here that differs from normal reverse proxy deployments is to ensure that the Verify Client option is enabled. In other words, under Configuration > Services > Proxy Services, edit the HTTPS reverse proxy service and you should see something similar to:

Note how the verify client option is enabled, and how the appropriate keyring (webserver certificate) and CCL created in step 1 is chosen.

3. Define a certificate authenticate realm

This is relatively straightforward. Simply create a new certificate realm, with any name needed (Authentication > Certificate > Certificate Realms). It’s interesting to note that the certificate realm is different from other realms in that it splits authentication and authorization into two distinct processes. Recall that authentication is the process of validating that a user is really who they say they are, while authorization decides what resources that user can use. In the certificate realm, authorization is optional. That’s to say, so long as a user can produce a valid certificate, they can access anything they need (also called a system-high access model).

This is the model that we'll be following in this example, so all that’s needed is to enter the correct OID under the “Extended Key Usage”. Under the “Certificate Main” tab, click the “ADD” button. This will ask for an OID that the proxy will check for in the client certificate. To obtain this OID, open a client certificate via MMC or IE, click the “Details” tab and select the “Enhanced Key Usage”. You’ll see the following:

Note the string of numbers near the client authentication: 1.3.6.1.5.5.7.3.2, this is the OID. It may differ depending on the CA of course.

4. Define appropriate CPL

The hard part’s been done. All that’s left is to enforce what’s been done. This is done via CPL. Open the local policy file, or create a new CPL layer under VPM. Insert the following:

<Proxy> ssl.proxy_mode = https-reverse-proxy
authenticate(tester_dv)

The first line instructs the proxy to use certificate authentication only for HTTPS reverse proxy users, not for all users.

The second line instructs the proxy which certificate realm to use. In this case, the certificate realm created in step 3 was named “tester_dv”, which is what was used here.