So I managed to setup the 3 tier setup from the Brian Komar book, 1) My PKI is 100% OK 2) My OCSP server on the PKI is also showing OK and all certificates and setup seems to be working and OK on the OCSP server side. 3) Every time I request a certificate is shows up on the Certificate Authority MMC instantly. 4) I have 3 different provider links 2 http and 1 LDAP; they can be accessed internally and externally I revoke and publish some certificates to test but they still up and running and green light the user or computer that they were published for in whatever they could before revocation, example NAP access via a RADIUS server is still allowed, my https website still shows a healthy certificate as if nothing has happened. I know this is a very vague explanation of my setup, but I will be happy to provide the required information you need to be able to troubleshoot the setup. Running the certutil -verify -fetchurl <certname.crt> is pointless at this moment as it plainly shows that certificates are not revoking. Thanks in advance, Dave.

You need to research more on how CRLs work.Revocation recognition is not immediate.Even if you publish new CRLs, the clients will have cached versions of the previous CRL (where the certificate is still valid)Even when you use OCSP, it will cache responses for the validity period of the CRL that the response was based on.If you have daily CRL publication, try your testing tomorrow and you will see the results you are afterMore details:http://technet.microsoft.com/en-us/library/bb457027.aspx § http://technet.microsoft.com/en-us/library/ee619730(WS.10).aspxBrian

Thanks Brian once again for promptly replying to my distress call. I am still a bit unconvinced with my setup, I have left certificates revoked for days or at least more than 1 week and nothing at all, no change on the validity of a certificate. I can access my external website which the CRL's are published and I can see immediately that the revoked certificate serial is in the list, yet the client computer takes no action or knowledge of the updated revocation list. My current expectations are either absolutely wrong or indeed I still must have some configuration error somewhere but this is my hypothetical scenario which are well used in examples: Laptop security is compromised and has VPN access with NAP enable and needs a valid certificate to pass the criteria in the RADIUS server, yet when I revoke it from my lab computer it still has access to the network. There must be something on the client side of the setup that I have misconfigured; in the MMC certificates snap on client I can see all 3 trusted certificates, Root, Policy and Issuing. I will carry on investigating this as it’s a fundamental service to get it up and running or my whole CA setup is still nothing without being able to revoke certificates and have the client side acknowledge this. Here is a link to my test lab setup revocation and a revoked certificate that i copied into file, it may help to see if I do have a setup error.http://vaticansin.net/certdata/VaticanSIN-Issuing-CA.crlhttp://vaticansin.net/Certdata/test.p7b Thanks Dave.

I have tested some things based on your links. Your certificates aren't so well for external users.1) LDAP urls are plaeced in first order. This means that external clients will loose up to 15 seconds to download certificate and CRL from AIA and CDP extensions respectively.2) OCSP url is available within your AD domain/forest only (.local suffix is not recognized in internet)and certutil show that certificate is revoked.http://www.sysadmins.lv

Thanks Vadims for taking the time and test my setup, Yes I decided to use certutil and indeed they show revoked, I guess now I must figure out why my security layers are not acting on revoked certificates but I guess that is a complete different question altogether and I will trouble shoot respectively. Certificate Security is a new endeavour for me and I do acknowledge that my expectations are somewhat different from lack of insight of how Certificate Authority works in real environments. Regards, Dave.