Hello all,

I have read a lot of sites and posts regarding Cert revocation but still have not found a working setup yet. We are publishing a website using a dedicated listener that requires client certificates from either an internal PKI (Based on Windows 2008r2) and an External PKI (Based on the opensource XCA tool). The internal CA's have the CDP/AIA information published and updated and are available via HTTP and LDAP. The TMG 2010 Server is member of the domain and can retrieve all certificate revocation information successfully using CERTUTIL -f -urlfetch -verify my-user-cert.cer.

The TMG server can also download the CRL using the CERTUTIL -URL "http://crl.domain.com/CAInfo/filename.crl".

I have installed the root/issuing/personal certificates on my iPad in the profiles store and can successfully open the website using Safari after importing those certificates, which I could not without those certs. So Certificate issuing-check is working fine, however when I revoke the certificate on the CA and replublish the CRL then the iPad can still access the website. When I sniff the traffic on the TMG server I also cannot easily see any trace of the server trying to even access the CRL either via an LDAP query or HTTP request.

When I run the CERTUTIL revocation check internally or via the internet works fine and shows the certificate is revoked. I also cleared the CRL cache locally on the TMG servers and downloaded the lates one via the CERTUTIL -f -urlfetch ... command.

What am I missing? On the TMG Server the System Policy "CRL Download" is enabled.

I hope you can help me out!

Many thanks,

Eric 

Hi,

Web Access Policy > Tasks > Related Tasks > Config Cert revocation check those settings

Thanks Vasily for your comment. Those settings are however already enabled (2 of 3 checkboxes checked).

We ran a network trace again and no sign of communication between TMG and DC's on LDAP nor HTTP to the CDP/AIA.

I hope you have another idea!

Tx

Eric

Hi Eric,

During the client authentication process, TMG tries to retrieve the CRL . This request is a transparent Web Proxy request from the Local Host network to the network in which the Certification Authority that issued the client certificate resides.

Can you access the CRL from the TMG web browser? Does the client cert has CDP?

Hi Vasily,

again thanks for that comment. I did try to download the CRL via a PSEXEC commandprompt running as system as I expected it to follow a similar process in the background. I could always download the CRL from my internal PKI servers though from the IE on these reverse-TMG servers. The TMG's are used for reverse-proxy only I have to say so the internal network does NOT have proxy-enabled. Just for testing purposes I enabled it after making sure no rules were active to allow internal requests to go out via this array.

In the System Policy Rules there is an enabled default rule "[System] Allow all HTTP traffic from Forefront TMG to all networks (for CRL
downloads)" and that rule get's hit quite some time actually. I find that quite an interesting default system rule I have to admit. So based on this I'd say that there is already a rule in place that should enable the LOCALHOST to go anywhere it pleases to but still the revocation-check is not performed.

So basically all is in place to allow revocation checks but still no go :(

Any more

Hi Eric,

I have the same on my side. I am gonna test it as well and look a little bit deeper.

Hi Vasily,

thanks for digging into it. We've come a little further ourselves too: it has to do with the authentication requirement on the RULE too! If you set it to All authenticated users it DOES also do the revocation check. That shouldn't be the case and should work when the rule is set to "All Users" too, so the MS Engineer is working on that.

Keep you posted!

Hi Eric,

So, if we have All Users on the TMG then it doesn't have to check certificate as it doesn't authenticate a user. To my mind it does make sense. On one hand If TMG authenticates a user it does all stuff on the other if it allows all users so it shouldn't care...

Hi Vasily,

actually the publishing rule is not meant for 'authenticated' users that can authenticate themselves with a user/password-combo or built-in windows credentials. It is a rule meant to be accessible by iPads that have a certain certificate in their profile. If we set the rule to All Authenticated Users that would trigger a popup on the iPad to authenticate everytime they access the resource. The moment we setup the rule for all-users and set the certificate requirement on the listener to require a cert from a specific CA then it works and the user only gets access to the site the moment the cert is in place. We expect this then to also perform a revocation check on the certificate presented by the user. That is also the way it is supposed to work anyway but it does not, at least not in a predictable manner. Today we 'suddenly' did correctly get denied on the website with a test-certificate that was revoked last week. When we revoked it last week, updated/published the new CRL and flushed the CRL cache on the TMG we were still granted access to the site. This afternoon we wanted to do the same and send the logs to Microsoft for investigation we correctly were denied access because of revoked cert. We then installed another valid certificate on the iPad and try again we were again denied access because of a revoked certificate but that simply wasn't true as it was a new, non-revoked cert.

So, there will probably be some issue with CRL caching that might confuse us here.. We hope to hear more tomorrow.

Rgds,

Eric

Hi Eric,

Any news on this from engineers?

Hi All,

after a lot of reading and testing we found that:

• the root (and intermediate) authorities' certificate must be in the NTAUTH store of the active-directory certificate store. If you have an internal Enterprise CA this is automatically the case. If not use CertUtil -dsPublish <CertFile> NTAuthCA to publish the third-party CA certs in the store;
• the root (and intermediate) authorities' certificate must be in the Trusted Root Authorities (and intermediate.. where applicable) store of the involved domain-controllers and TMG servers (can be arranged via AD policies if you whish);
• the user-cert must be published into the AD user-account;
• the TMG publishing rule must be set to All Authenticated Users (NOT TO ALL USERS);
• the TMG publishing rule's listener must be set to require a user-certificate and you must specifiy the trusted issuer of that certificate;

As we use aninternal PKI to issue certificates for this particular customer, I setup a custom template with the following characteristics:

• mark private key exportable
• publish in AD
• auto-enroll to a specific user group only
• key-usage: digital signature
• enhanced key usage: smart card logon, client authentication
• subject=distinguished name, subject alternate name=UPN

This way the user gets the certificate automatically published in AD and we setup a user-manual to assist the user to:

• locate that certificate in his/her AD-user
• export that certificate including private-key
• email that exported and password protected file to the mailbox they use on the iPad
• open the email on the iPad and import the certificate into the iPad profiles

This way the user can open the protected URL and get the request to choose an appropriate certificate. The only 'problem' is now that if the user has multiple certificates he/she needs to select a cert every time the site is opened or a link in the site is clicked...

All in all quite a difficult requirement for a simple thing as revocation check to work. I hope this helps anyone.

Rgds,

Hi Eric,

thanks for sharing!