Why such a delay on certificate acknowledgement?
Hi Guys,Just another query for the security experts that are so helpful around this forum.Thanks to the help of Brian Komar and others for clarifying on solutions to certain issues and requirements for my CA infrastructure. I have it up and running on my test environment but there is just one thing I find hard to believe on such a critical aspect of security, why upon revocation it takes a lot of time for the security services such as my RADIUS server to deny access to my network due to a revoked certificate?If I was running a live environment and a laptop is stolen with access to critical servers, when I revoke the certificate currently held on that laptop I would expect it to be denied access as instantly as if I changed the password of a compromised user account. Is this what I should expect? Or is there still some infrastructure issue that I have failed to configure on either server or client side to have almost or if not instant acknowledgement of my certificates?Thanks again guys.Dave.
February 20th, 2010 11:59am

There are some things for that. In real world certificates consume a lot of network bandwith. And to reduce it here is some caching mechanisms. For example, you buy some items on eBay. When you log on, you go to SSL-secured page. While you validate vertificate you need to download CRL from VeriSign and check server certificate. When you bought items you need to pay for them and you are reirected to PayPal service that is secured with SSL. Without caching mechanisms you will have to download the same CRL and check new SSL certificate against this CRL. Also there would be enermous requirements for CRL-hosted web servers and network bandwith. To reduce network overload, when CRL is downloaded it is cached for a certain time. It is a good way to cache this CRL until it is expired and use short-time lived CRLs, aka DeltaCRL. By default they are published each 24 hours.Another thing that allow to mitigate this issue is to use OCSP responder that will allow to adequately detect certificate status. You may change internal cache refresh periods (for example, refresh it each 10 minutes). In that case if you revoke certificate and publish new CRL, in next 10 minutes OCSP responder will be able to detect particular revocation status. Of course if RADIUS will ask OCSP for certificate status, OCSP will return 'Revoked' while CRL-based check will assume that certificate is valid (until CRL expire).I think you need to examine Brian's whitepaper: http://go.microsoft.com/fwlink/?LinkId=145008http://www.sysadmins.lv
Free Windows Admin Tool Kit Click here and download it now
February 20th, 2010 9:24pm

Things are still not working as they should, my OCSP is set to refresh every 5 minutes on the provider configuration. The CRL's that the OCSP retreives does have an upto date revoked list that is instant which is availible both on LDAP, intranet and internet.I have issued certificates that only has the AIA and OCSP locations in them in order to bypass CDP checking. upon using certutil -url it verifies my external OCSP and AIA, which is what I want as the test computer is not connected to my internal network and its to test revocation over the internet.I still do not believe it should rely on a 12 hour cache to revoke a critical security certificate from a compromised laptop. I thought the point of having a OCSP or any other certificate system is to have almost instant security control over allowed and revoked certificates, not a critical delay in which a 'hacker' has time to do what ever as long as the cache has not updated.EDIT:Strange things going on, so i come back from work and i run a certutil -url and its finally revoked but still not denied access, i decide to restart my RADIUS server and suddenly the server denies access to the revoked certificate holders computer, there is defently something not resheshing properly.
February 23rd, 2010 10:44am

Hi, As the certutil –url shows the certificate as revoked, I think the OCSP responder has the current CRL. Please run the command “certutil -setreg chain\ChainCacheResyncFiletime @now” to flush cached CRLs on the computer and check if it works. How to refresh the CRL cache on Windows Vista http://blogs.technet.com/pki/archive/2007/09/13/how-to-refresh-the-crl-cache-on-windows-vista.aspxThis posting is provided "AS IS" with no warranties, and confers no rights.
Free Windows Admin Tool Kit Click here and download it now
February 24th, 2010 6:08am

Hi Joson, Thanks for the hints, but I did this yesterday and as one of the examples does state I get the registry error which I do not know how to rectify. Also I would expect the whole process to be automatic and hassle free up to a certain extent, if I was running a live environment with a sizeable infrastructure I would not be expected to worry about trivial things like having to check every hour to see if the certificate has finally been revoked or not or having to restart servers to make them acknowledge the certificate. The client has a revoked certificate which was manually checked by me but the RADIUS still lets them access the network and I have to restart the server in order to deny them access? What kind of automated system is this!? I thought the reason to have an online responder is to get certificates checked faster, the OCSP has access directly to revocation CRL's which do have the revoked certificate serial in the list but it somehow fails to use this until the next refresh and after this has been refreshed the RADIUS still grants access to the network unless I restart it. I tried to follow most of the examples, tutorials and whitepapers on the net or books but I still do not believe that it can seriously take hours and a few restarts to deny access to the network to a revoked certificate. I will keep on hacking at the setup until I find what the issue is. Thanks Dave.
February 24th, 2010 10:37am

Hi Dave, >>Thanks for the hints, but I did this yesterday and as one of the examples does state I get the registry error which I do not know how to rectify. Do you mean you encountered the error message “The system cannot find the file specified”? Please confirm whether you encountered the error message when running “certutil –getreg” or when running “certutil –setreg”. As the article mentions, it is expected that you encounter the error message when you run “certutil –getreg” and the error can be ignored because default CRL caching takes place in this case. Therefore, please let me know the output after you run the command “certutil -setreg chain\ChainCacheResyncFiletime @now” on the RADIUS server. >>Also I would expect the whole process to be automatic and hassle free up to a certain extent, if I was running a live environment with a sizeable infrastructure I would not be expected to worry about trivial things like having to check every hour to see if the certificate has finally been revoked or not or having to restart servers to make them acknowledge the certificate. The client has a revoked certificate which was manually checked by me but the RADIUS still lets them access the network and I have to restart the server in order to deny them access? What kind of automated system is this!? When a certificate is issued, it is expected to be in use for its entire validity period. The benefit of caching CRLs locally is that CryptoAPI will always look for a cached copy first to avoid traversing the network and introducing latency in the revocation status checking. Under the circumstances that we need to revoke a certificate and force it to take effect immediately, it is reasonable (in my opinion) that we need to manually revoke the certificate, publish the latest CRL and clear the local cache. Restarting servers is not required however, based on my understanding. >>I thought the reason to have an online responder is to get certificates checked faster, the OCSP has access directly to revocation CRL's which do have the revoked certificate serial in the list but it somehow fails to use this until the next refresh and after this has been refreshed the RADIUS still grants access to the network unless I restart it. Based on my research, OCSP determines the revocation status of the certificates based on CRLs issued by the CA. Although we can have it update CRLs every a few minutes, it is still affected by the time granularity issue. Due to the time granularity issue we should never rely only on the certificate (only) for access if we wish to have real time control over access . This is part of the standard. http://www.faqs.org/rfcs/rfc2459.html Thanks.This posting is provided "AS IS" with no warranties, and confers no rights.
Free Windows Admin Tool Kit Click here and download it now
February 26th, 2010 9:45am

Hi,How are you? I want to check if you need any further assistance. If there is anything we can do for you, please do not hesitate to respond back.Thanks.This posting is provided "AS IS" with no warranties, and confers no rights.
March 3rd, 2010 9:54am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics