Answered by:
ADFS 3.0 client certificate authentication display with no result on WAP

Question
-
I have the setup as ADFS 3.0 client authentication method enabled. When I open browser to logon, the ADFS 3.0 page displays a message as "Select a certificate that you want to use for authentication. If you cancel the operation, please close your browser and try again." the certificats are displayed from internal when browsers access directly to ADFS 3.0 Server but the certificates are displayed for selection when I use external acces througt Web Application Proxy (WAP) with TCP port 49443 enabled inbound on the firewall between the clients and the Web Application Proxy (netstats show Etablished state on 49443 of the WAP with no resluts
It smells it's the only requirement is :
if client user certificate authentication (clientTLS authentication using X509 user certificates) is required, AD FS in Windows Server 2012 R2 requires that TCP port 49443 be enabled inbound on the firewall between the clients and the Web Application Proxy. This is not required on the firewall between the Web Application Proxy and the federation servers).
source : https://technet.microsoft.com/en-us/library/dn554247.aspx#BKMK_7
All sources tell that 49443 is the only requirement
https://technet.microsoft.com/en-us/library/dn486819.aspx
Anyone can help me to solve this issue ?
https://technet.microsoft.com/en-us/library/dn283415.aspx
thank you for your help
- Edited by Stéphane Mendez Friday, March 18, 2016 12:00 PM
Thursday, March 17, 2016 8:48 PM
Answers
-
Hi,
When the certificate selection dialog popup, if we select one of them, what happens?
If the dialog box is frozen, please check if the CRL of the certificate is available. I've seen a similar case which is caused by the revocation check failure.
Best Regards,
Steven Lee Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.
- Proposed as answer by Steven_Lee0510 Sunday, March 27, 2016 2:43 PM
- Marked as answer by Steven_Lee0510 Monday, March 28, 2016 3:21 PM
- Unmarked as answer by Stéphane Mendez Monday, April 4, 2016 12:50 PM
- Unproposed as answer by Stéphane Mendez Tuesday, April 5, 2016 9:10 AM
- Marked as answer by Stéphane Mendez Monday, July 11, 2016 2:50 PM
Monday, March 21, 2016 2:22 PM -
Hey,
ok maybe it is a CRL problem -- but if I checkt it with the cerutil certutil -f –urlfetch -verify all seams fine on the WAP.
Now I made a workaround with the following guide:
https://blogs.msdn.microsoft.com/kaushal/2012/10/15/disable-client-certificate-revocation-crl-check-on-iis/
- netsh http add sslcert hostnameport= adfs.xyz.de:49443 certhash=<the old value> appid={<the old value>} certstorename=My verifyclientcertrevocation=disable clientcertnegotiation=enable
Use the IIS 8 settings ...
Now it works without a CRL checking - not nice but it works. I start to debug the pki ... maybe something is wrong here.
- Edited by sbidys Tuesday, May 24, 2016 2:31 PM
- Proposed as answer by sbidys Tuesday, May 24, 2016 2:32 PM
- Marked as answer by Stéphane Mendez Monday, July 11, 2016 2:40 PM
Tuesday, May 24, 2016 10:07 AM -
It was an issue with CRL
The main problem was the fact that the WAP was not able to verify the revocation status of the client certificate (presence of error 30 and / or 53 at the CPAI newspaper on WAP server).
In fact the latter had only a single LDAP path in the CDP extension, while the LDAP traffic between the web server (located in DMZ) and domain controllers was not allowed.
Configuration of the issuing CA client certificates was then changed so that in the CDP extension of newly issued certificates there is an additional way of http.
After obtaining (enrollment) a new client certificate with dual path (CRL at the CDP extension), it was nevertheless necessary to do the following to the WAP server to properly validate the revocation status of the client certificate (in the scenario where the revocation check of the client certificate in the SSL binding of the 49443 port was again "ENABLE"):
The publication of an updated CRL was performed from the administration of the intermediate CA mmc.
Purge CRL "caching" in the context "local system" in the WAP server (via the use of the tool "psexec / s / i cmd"):
certutil -urlcache CRL delete
certutil -setreg chain \ ChainCacheResyncFiletime @Now
Restart the service "Cryptographic Service"
Once ADFS authentication via WAP on the basis of a client certificate were then possible.- Marked as answer by Stéphane Mendez Monday, July 11, 2016 2:39 PM
Monday, July 11, 2016 2:39 PM
All replies
-
Hi,
When the certificate selection dialog popup, if we select one of them, what happens?
If the dialog box is frozen, please check if the CRL of the certificate is available. I've seen a similar case which is caused by the revocation check failure.
Best Regards,
Steven Lee Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.
- Proposed as answer by Steven_Lee0510 Sunday, March 27, 2016 2:43 PM
- Marked as answer by Steven_Lee0510 Monday, March 28, 2016 3:21 PM
- Unmarked as answer by Stéphane Mendez Monday, April 4, 2016 12:50 PM
- Unproposed as answer by Stéphane Mendez Tuesday, April 5, 2016 9:10 AM
- Marked as answer by Stéphane Mendez Monday, July 11, 2016 2:50 PM
Monday, March 21, 2016 2:22 PM -
hello Steven,
When I select the good certificate nothing happens, the dialog box isn't frozen, I don't think that the CRL need to be published although it was a private certificate it's that because when I use the internal acces through the ADFS server it works so the revocation check need to be use only after 7days.
In this case I then tries external access via WAP which request appears not achieve while connection on the TCP port 49443 is well established, so if the revocation list has already been verified that audit does not seem yet necessary since there was no expiration which leads to consult again
Monday, April 4, 2016 12:50 PM -
Hey,
same here - we have the exact same behavior with the WAP and a client certificate authentication.
I checked the external and internal CDP and AIA of the user certificate - it is accessible and valid (checked with certutil -url).
If i tried to connect to the https://adfs.urls.com:49443/adfs/ls/idpinitiatedsignon.aspx --> I select a valid user certificate --> the Borwser accept his and tries to connect to the WAP. I saw some TCP keepalive packages at my client to the WPA system.
and the trace to the URL
Tuesday, May 24, 2016 7:44 AM -
Hey,
ok maybe it is a CRL problem -- but if I checkt it with the cerutil certutil -f –urlfetch -verify all seams fine on the WAP.
Now I made a workaround with the following guide:
https://blogs.msdn.microsoft.com/kaushal/2012/10/15/disable-client-certificate-revocation-crl-check-on-iis/
- netsh http add sslcert hostnameport= adfs.xyz.de:49443 certhash=<the old value> appid={<the old value>} certstorename=My verifyclientcertrevocation=disable clientcertnegotiation=enable
Use the IIS 8 settings ...
Now it works without a CRL checking - not nice but it works. I start to debug the pki ... maybe something is wrong here.
- Edited by sbidys Tuesday, May 24, 2016 2:31 PM
- Proposed as answer by sbidys Tuesday, May 24, 2016 2:32 PM
- Marked as answer by Stéphane Mendez Monday, July 11, 2016 2:40 PM
Tuesday, May 24, 2016 10:07 AM -
It was an issue with CRL
The main problem was the fact that the WAP was not able to verify the revocation status of the client certificate (presence of error 30 and / or 53 at the CPAI newspaper on WAP server).
In fact the latter had only a single LDAP path in the CDP extension, while the LDAP traffic between the web server (located in DMZ) and domain controllers was not allowed.
Configuration of the issuing CA client certificates was then changed so that in the CDP extension of newly issued certificates there is an additional way of http.
After obtaining (enrollment) a new client certificate with dual path (CRL at the CDP extension), it was nevertheless necessary to do the following to the WAP server to properly validate the revocation status of the client certificate (in the scenario where the revocation check of the client certificate in the SSL binding of the 49443 port was again "ENABLE"):
The publication of an updated CRL was performed from the administration of the intermediate CA mmc.
Purge CRL "caching" in the context "local system" in the WAP server (via the use of the tool "psexec / s / i cmd"):
certutil -urlcache CRL delete
certutil -setreg chain \ ChainCacheResyncFiletime @Now
Restart the service "Cryptographic Service"
Once ADFS authentication via WAP on the basis of a client certificate were then possible.- Marked as answer by Stéphane Mendez Monday, July 11, 2016 2:39 PM
Monday, July 11, 2016 2:39 PM