Had to deal with an interesting case lately. This is what the customer wanted:
as you can see, 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 plain old HTTP. This is easily handled by the ProxySG when using the reverse proxy configuration. I won’t go into that here. The interesting thing was 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. The documentation available gave good clues but was not totally complete (hopefully we’ll get this content published in the BC KB to rectify this).
Turns out that the above scenario is possible using the “certificate authentication” in the ProxySG (configuration > authentication > certificate). There are four major sets 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 apporpriate 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 intot he 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
It’s important on the proxy for IE to work, that a separate CCL list is created under “SSL > CA certificates > CA certificate Lists” and within this CCL, add only the CA that was used above. This is critical for IE to work. Reason being that 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’ve 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 I’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 apporpriate 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 lcoal 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 my case, the certificate realm created in step 3 was named “tester_dv”, which is what I used here.
🙂
David Vassallo's Blog 