MSMQ client is not getting updated CRL when the cache expires

[mglee]

I have MSMQ sending messages over SSL. My understanding is that when a
request is initiated, the MSMQ client tries to establish a connection with
the server by first validating the SSL certificate of the server. As part of
this validation it checks to make sure the SSL certificate has not been
revoked by looking up the Certificate Revocation List (CRL) for the CA that
issued the SSL certificate. It will cache the CRL for future requests, and
when the cache expires, it will get an updated CRL from the locations (CDPs)
listed in the certificate.

My problem is that when the cached CRL is expired MSMQ doesn't get the
updated CRL. The outgoing requests just sit on the outgoing queue with a
status of "Waiting to connect". I believe the CRL is being cached here:
C:\WINDOWS\system32\config\systemprofile\Application
Data\Microsoft\CryptnetUrlCache\Content. The timestamp on the file
corresponding to the CA in question isn't updated. However, when I restart
the MSMQ service, the timestamp is updated (indicating that it got the
updated CRL), and the messages are finally sent. I've had other similar
setups that have worked without having to restart MSMQ, so I'm stumped on why
this one isn't working.

Yes, the CRL is accessible. I can get to it via Internet Explorer just
fine. The first CDP listed in the SSL certificate is not accessible, but the
second one is. My understanding is that only one has to be accessible.

Also, when I try to access the web server that the MSMQ client is trying to
send to via https I can get to it--indicating that my browser indeed is
getting the CRL as expected. So why can my browser do it but the MSMQ client
can't?

As a short term solution I have set the SkipRevocationCheck registry setting
described in http://support.microsoft.com/kb/889859. However I don't want to
disable revocation checking permanently so I need to find another solution.

Any help would be appreciated. Thanks.

[John Breakwell (MSFT)]

I think it might be best to raise a support case so that an engineer can
look at your MSMQLOG.BIN fles to see why the revocation list is not being
dynamically refreshed.

Post by mglee
I have MSMQ sending messages over SSL. My understanding is that when a
request is initiated, the MSMQ client tries to establish a connection with
the server by first validating the SSL certificate of the server. As part of
this validation it checks to make sure the SSL certificate has not been
revoked by looking up the Certificate Revocation List (CRL) for the CA that
issued the SSL certificate. It will cache the CRL for future requests, and
when the cache expires, it will get an updated CRL from the locations (CDPs)
listed in the certificate.
My problem is that when the cached CRL is expired MSMQ doesn't get the
updated CRL. The outgoing requests just sit on the outgoing queue with a
C:\WINDOWS\system32\config\systemprofile\Application
Data\Microsoft\CryptnetUrlCache\Content. The timestamp on the file
corresponding to the CA in question isn't updated. However, when I restart
the MSMQ service, the timestamp is updated (indicating that it got the
updated CRL), and the messages are finally sent. I've had other similar
setups that have worked without having to restart MSMQ, so I'm stumped on why
this one isn't working.
Yes, the CRL is accessible. I can get to it via Internet Explorer just
fine. The first CDP listed in the SSL certificate is not accessible, but the
second one is. My understanding is that only one has to be accessible.
Also, when I try to access the web server that the MSMQ client is trying to
send to via https I can get to it--indicating that my browser indeed is
getting the CRL as expected. So why can my browser do it but the MSMQ client
can't?
As a short term solution I have set the SkipRevocationCheck registry setting
described in http://support.microsoft.com/kb/889859. However I don't want to
disable revocation checking permanently so I need to find another solution.
Any help would be appreciated. Thanks.