Hello, I have done some preparation for my classes but I have encountered a problem. I have only one machine - it is simplier for what I am doing. Here there are ALL steps which I did witch AD CS. 1. I installed Root CA Enterprise on Domain Controller. 2. I logged in onto user account and encrypt one catalogue with a txt file. 3. When I switched to the Administrator account there was a new certificate issued for Basic EFS. 4. Then I revoked this certificate, published new CRL list and did a gpupdate /force command. 5. After that I logged in to the user account again (logged in, not switched). Unfortunately the user could still read/modify this file. I checked his certificates in mmc and there was his certification for EFS eventhough it was revoked. Why it is so? How to cause that this certification is revoked and the user could not read/modify this file?

1) Revocation does not work this way. The client has downloaded a CRL to the cache and it is still time valid, even though you have revoked the certificate 2) Revocation does not prevent decryption of data. The revoked certificate can still be used to open the file 3) If they tried to save the file, they would need a new certificate with the EFS application policy OID (once the previous CRL has expired from the cache) Brian

Brian, thank you for your response. > 1) Revocation does not work this way. The client has downloaded a CRL to the cache and it is still time valid, even though you have revoked the certificate Ok, so when it will get to know that this certificate is revoked? I manually published new CRL, when it will be downloaded by the user? > 2) Revocation does not prevent decryption of data. The revoked certificate can still be used to open the file Thank you. Now, it's clear for me. > 3) If they tried to save the file, they would need a new certificate with the EFS application policy OID (once the previous CRL has expired from the cache) I do not know if I understand this statement. I assume that the certficate is revoked. User can open file with revoked certification, modify and save it. But while saving he would generate next valid certification? Is that a correct interpretation of number 3?

1) It will be downloaded when the CRL in the cache expires. Each CRL has a valid from and valid to attribute. When it expires, it can then be replaced with an updated CRL. 3) He would need a *new* certificate to save the file. This would be obtained either manually, self generated, or through autoenrollment. Without a new certificate, they would be prevented from saving the file Brian

On Tue, 17 May 2011 02:48:32 +0000, Brian Komar [MVP] [MVP] wrote: 3) He would need a new certificate to save the file. This would be obtained either manually, self generated, or through autoenrollment. Without a new certificate, they would be prevented from saving the file Are you certain this is the case? My understanding is that EFS only does revocation checking in two instances: 1. When requesting a cert from a CA and key archival is enabled, the key recovery agent's certificate is checked for revocation. 2. When attempting to share an encrypted file with another user, that user's cert is checked for revocation status. Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca Long computations that yield zero are probably all for naught.

It does not work. - I create files and then encrypt them. - I get certification for Basic EFS - I revoke this certificate - I publish new CRL manually - On the user account, I do 'certutil -urlcache CRL delete' - Then I modify and save encrypted files - I can still do it - cerutil -urlcache CRL shows empty window - and there is no new certificate for Basic EFS So three questions: 1) Is there any way to enforce CRL update? (I hoped that modyfing and saving file would have done it) 2) I wanted to share this folder but the administartor credential was needed, why? 3) Can you tell me some other scenario in which I can show how revocation works? It need not to be a EFS encryption but anything else (but keep in mind that I have only one machine).

1) Issue an SSL Certificate and implement to protect a Web site 2) Connect showing working connection 3) Revoke the certificate 4) Wait for the CRL to expire. Clearing the cache is not reality. The reality is that a client will cache the CRL until it expires 5) Connect to the Web site and see that the certificate is revoked Brian

OK one very annoying thing. I have created new domain certificate for a common name - https://localhost/ When I type EXACTLY the same address in the IE I have address mismatch error - "the security certificate presented by this website was issued for a different webiste's address." And that is not true! How to avoid this message? I have tried to install this certificate, add this address to trusted sites etc. Nothing is changed.

OK one very annoying thing. I have created new domain certificate for a common name - https://localhost/ When I type EXACTLY the same address in the IE I have address mismatch error - "the security certificate presented by this website was issued for a different webiste's address." And that is not true! How to avoid this message? I have tried to install this certificate, add this address to trusted sites etc. Nothing is changed. Change localhost in your common name to your FQDN. (And https should NOT be a part of the common name. Only the NetBIOS name or the FQDN of the computer should be in the common name or SAN attribute field.) There is no need to issue a certificate for localhost since that traffic will not be transferred over the network (only internally within the computer) and therefor does not need or require encryption. Furthermore, certificates are issued to validate a unique identity. Localhost is NOT a unique identity! ;) // Fredrik "DXter" Jonsson - http://www.poweradmin.se