The following KB article isn't anything new (it's been out a few years)
889859 Messages that you try to send over HTTPS may remain in the outgoing message queue in Message Queuing 3.0
but a customer asked me why the Certificate Revocation List could not be found so I looked into it.
The cause of the problem documented in the KB is:
"This problem may occur if Message Queuing 3.0 cannot reach the location of the certificate revocation list (CRL) that is specified in the properties of the certificate. Typically, this behaviour occurs when the site cannot be accessed or when the port that is specified in the certificate is not open."
Looking into the RFC for CRLs, I found that you can specify four different protocols for accessing the list:
Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile
5.2.5 Issuing Distribution Point
If the distributionPoint field is present and contains a URI, the following semantics MUST be assumed: the object is a pointer to the most current CRL issued by this CRL issuer. The URI schemes ftp, http, mailto and ldap are defined for this purpose. The URI MUST be an absolute pathname, not a relative pathname, and MUST specify the host.
So, after checking the obvious that the distribution point is in fact reachable over the network, you also need to ensure that the type of host for the list matches the protocol used to obtain it:
- Webserver - use FTP or HTTP
- Active Directory - use LDAP
[[I have NO idea at all how you would use MAILTO to get hold of a revocation list. Maybe you get sent a copy in response?]]
Note - you cannot assume that the CRL is available by running Internet Explorer with the Check for server certificate revocation option enabled as, by default, IE won't complain if there's a problem:
946323 Internet Explorer 7 does not send you any notification if it cannot obtain the Certificate Revocation List