Here is a simple circuit which check a Certificate Revocation List following SSL on the Vordel Gateway:
First things first
Firstly, it's important to setup an HTTPS listener on the Gateway which is requiring that a client sends a mutual SSL certificate to it. To do this, in Policy Studio, look under "Gateway", the "Listeners", and then your Gateway instance and then a particular Services group (by default there is one there called "Default Services"). You can right-click here, on your Services group, and choose "Add Interface" and then "HTTPS".
Here you choose your port for SSL (by default this is 443, but ensure that nothing is already running on that port or else when you try to deploy, the Gateway will detect this and tell you). Under the "Mutual Authentication" tab choose the option to "Require Client Certificates". In my example I have set the "Maximum Depth of Certificate Chain" to "3". Now ensure that you check the CA Certificates of all certs which will be trusted to be sent by clients. It's important to note that here you are checking the CA Certificates. If you have 1,000 clients who are sending certs all signed by the same CA, clearly it would be infeasible to check 1,000 boxes, one for each client. Instead, the trust is at the CA level.
[ Note: If you want to ensure that clients can only access your APIs or services over SSL, then simply delete the existing plain HTTP entry under the Services Group. Or, create a new "HTTP Services", only put an HTTPS listener in there, and then the only way to access the paths in that group is through SSL].
Next, right-click on your Services in Policy Studio again and this time choose "Add Relative Path". For my example, I am adding "/SSL" and it links to the policy I've made.
Step by Step
So, now let's look at the policy, step by step:
SSL filter. This filter is from the "Authentication" group in Policy Studio. The purpose of this filter is to force SSL authentication and to retrieve the certificate which is presented by the client. If you hover the mouse over this filter, you can see that one of the attributes it creates is a "certificate" attribute, which is the certificate presented by the client.
Check certificate against CRL filter. This is a "CRL (Dynamic)" filter. It is from the "Certificate" group in Policy Studio. I have configured the URL to "http://localhost:8080/GetCRL/MyCRLName.crl" . This means that the CRL is being served up by the Gateway (which is also listening on port 8080) using a Static Content Provider. The Static Content Provider is essentially a Web Server, which serves up the content of a directory. In this case, I map it to a folder on the same machine as the Gateway. I then place the CRL in there, and, under the services entry under "Listeners" in Policy Studio, I right-clicked and choose "Add Static Content Provider", and then pointed it at this directory. You can verify it works, once you deploy this, by simply pulling the CRL down through the browser (point your browser to: http://
"Certificate is Valid" and "Certificate is not Valid" filters. These are simply "Set Message" filters, which return a message of "Certificate is Valid" or "Certificate is not valid", depending on the outcome of the CRL check filter above them in the decision tree. I choose the content-type of "text/html" since I am testing this with a browser.
"Return HTTP 200" filter. This is simply a "Reflect" filter, which returns the message I've set ("Certificate is valid" or "Certificate is not valid") with a HTTP response code of 200.
In order to test this, I imported a client certificate into the "Personal" group of certificates in Internet Explorer. For some reason, the certificates configuration in Internet Explorer is under the "Content" tab (not the "Security" tab as you might expect) in Tools->Internet Options. This is where I clicked "Import" and imported a certificate to test. I then opened up https://GatewayAddress/SSL in the browser and presented my certificate for authentication. I then received the "Certificate is Valid" response from the Gateway, and in the Gateway's Real-Time Monitoring (port 8090) I could see the successful path through the CRL-checking policy.