Helping Your Customers Help Themselves

If you tell your customers whether they are sending a certificate you can solve their problem for a day, but if you provide them with a service that tells them if they are sending a certificate you can solve their problems for a lifetime (or at least a little more often).

See my "Diagnostic Service" post for the Layer 7 policy logic for a REST service that informs the requester of the following common client mistakes:

• Failing to use a secure (SSL) connection
• Failing to attach a client certificate to their request
• This can easily be changed to test for other authentication methods
• Sending a client certificate that is expired
• For this you have to check what the audit code was that failed the require ssl with client certificate assertion because the certificate properties are not populated when the assertion fails in earlier versions of the gateway (though I believe Layer 7 Technologies may have corrected this).
• Sending an otherwise invalid certificate; these errors are not differentiated from each other in the policy example provided.
• Not provisioned for use as a client certificate (not sure if this actually fails the assertion)
• Self signed un-trusted root, etc.

Because I have crafted it as a REST service I setup the responses as JSON, but you can convert them to XML for SOAP clients and have them repoint any applications they are having trouble with in order for them to test without any assistance; they just have to look at the response they receive to validate whether or not they are properly sending their certificate (and that they are sending the one they expect to be).  Since it is REST it has no WSDL to validate their operations against and will therefore service traffic regardless of message content.