Update 28.05.2012: it appears that the same issue occurs with Remote Desktop Protocol too. Here is a fix for RDP: An RDP connection that uses SSL authentication and CredSSP protocol fails in Windows 7, in Windows Server 2008 R2, in Windows Vista and in Windows Server 2008
This is very interesting story of one customer (not my) and Thawte. It is common that you purchase SSL certificate from some of trusted commercial certification authority (CA) for public access. This reduces administrative effort on custom root CA (for example, your company own internal CA) installation on unmanaged computers (your company user's home computers). Or in partner organization. Also your company may not have own CA services and the only way to provide secure access to your web sites is to use certificates from commercial CAs.
Right now, you have purchased it and installed on a company HTTPS web server. All works fine, customers are able to see your company web site over HTTPS. And now you have decided to use the same certificate for public SSTP VPN. As the result company employees can establish a VPN connection to corporate network from their home computers or laptops during business traveling and so on.
Ok you set up SSTP VPN, assign certificate and..bump..get error message:
WTF? HTTPS works, but SSTP not. Ok, you copy SSL certificate to a client computer and open it:
Switch to Certification path tab:
Open the HTTPS web site:
But there everything is ok. I hope all my blog readers are familiar with certificate chaining engine basics and you know that certificate chain can be built by using either local certificate store, local cache or Authority Information Access extension.
At first you open local certificate store and cannot find Thawte SSL CA certificate. Ok, you open SSL certificate and lookup for this Authority Information Access extension and what you see:
[1]Authority Info Access
Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
Alternative Name:
URL=http://ocsp.thawte.com
There is no links to issuer's certificate! As the result certificate chain building fails. However web browser is able to build chain, but SSTP client not. Why?
The answer is not pretty trivial for most users. The default behavior for IIS (not sure for 3rd party web servers) is to send *full* certificate chain (in a PKCS#7 format) to a client web browser. Since intermediate certificates are installed on IIS (as required by Thawte), all web clients receive this "hidden" Thawte SSL CA certificate and use it to build a chain. The default behavior for SSTP VPN is to send only *leaf* server certificate. As the result VPN client is not able to verify whether the certificate was issued by a trusted authority and perform other revocation checks and connection fails.
Note: a message "The revocation function was unable to check revocation because the revocation server was offline" may not mean exact reason. This message is appeared when a certificate was issued by untrusted CA. Since certificate chain is untrusted it is useless to perform revocation checking and you see exact message.
Thawte has published an article to resolve this issue: SSL Web Server or Wildcard certificate issued after June 26 2010 not trusted after installation on Microsoft IIS.
Thawte provides a workaround — to install all certificate chain on IIS web server. This will resolve HTTPS trust issues, but not SSTP. To resolve this issue for SSTP you will have to install intermediate certificates on *all* VPN client computers. And VPN server too.
Since VPN clients mostly are external and it is not always possible to install corresponding intermediate certificates on them. This is hard question.The only workaround is to contact Thawte (or any other commercial issuer) to request a SSTP-capable certificate that will contains URLs to CRT files in AIA extension or which intermediate (along with root) certificates are already preinstalled on the common Windows systems.
HTH.
Hi, I think I've got the same or similar problem as described in your article. I've set up a SSTP server using the Microsoft Step by Step guide for SSTP Deployment released in 2007. I did all the steps twice and every time I try to connect my VPN from a public IP address, it fails with the message : "The revocation function was unable ....". On some blogs, the issue was to disable CRL check on Seven clients : no result at all. Furthermore, unlike your example, I've installed my own CA (ADCS) and I use a certificate which is delivered by this CA and not Thawte, Verisign or other Trusted provider. The connections to the SSTP Server are only successful when initiated from the LAN (the same as the SSTP server). Is my case concerned by this problem or have I got another problem with my CRL publishing ? And how do you explain that the certificate chain and connection validation succeed when connecting on the LAN and unsuccessful when connecting from outside the LAN.
can you show me an output of the command 'certutil -verify -urlfetch file.cer', where file.cer is your VPN server certificate. You need to run this command on the public client (that throws error). You can email me results. The problem can be caused due of root certificate trust issue. By default corporate CAs (that are instelled in your AD forest) are automatically trusted by domain members, but not members outside your forest.
Thanks for your answer. Here is the output of the certutil command. I don't have your mail. Maybe it'd be easier to send you the results. ?metteur: CN=qo-PERSEPHONE-CA DC=qo DC=fr Objet: CN=qo-PERSEPHONE-CA DC=qo DC=fr Num?ro de s?rie du certificat : 2d04b1d625ddf2874ce57bd7aab578df dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000) dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000) ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000) HCCE_LOCAL_MACHINE CERT_CHAIN_POLICY_BASE -------- CERT_CHAIN_CONTEXT -------- ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) CertContext[0][0]: dwInfoStatus=10c dwErrorStatus=0 Issuer: CN=qo-PERSEPHONE-CA, DC=qo, DC=fr NotBefore: 03/05/2011 14:47 NotAfter: 03/05/2021 14:57 Subject: CN=qo-PERSEPHONE-CA, DC=qo, DC=fr Serial: 2d04b1d625ddf2874ce57bd7aab578df 97 1d 0c bb c2 fb da 94 41 f5 cb 9d c7 8e 84 3b b5 2a ac 44 Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4) Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- AIA de certificat ---------------- Pas d�URL "Aucun" Heure : 0 ---------------- CDP de certificat ---------------- Pas d�URL "Aucun" Heure : 0 ---------------- Protocole OCSP du certificat ---------------- Pas d�URL "Aucun" Heure : 0 -------------------------------- Exclude leaf cert: da 39 a3 ee 5e 6b 4b 0d 32 55 bf ef 95 60 18 90 af d8 07 09 Full chain: 97 1d 0c bb c2 fb da 94 41 f5 cb 9d c7 8e 84 3b b5 2a ac 44 ------------------------------------ Strat?gies d�?missions v?rifi?es: Tous Strat?gies d�application v?rifi?es: Tous Cert est un certificat d�autorit? de certification ERREUR : la v?rification de l�?tat de r?vocation du certificat feuille a renvoy? La fonction de r?vocation n�a pas pu v?rifier la r?vocation car le serveur de r?vocation ?tait d?connect?. 0x80092013 (-2146885613) CertUtil: La fonction de r?vocation n�a pas pu v?rifier la r?vocation car le serveur de r?vocation ?tait d?connect?. CertUtil: -verify La commande s�est termin?e correctement.
You have posted a trace against your CA certificate. But I need trace against SSTP SSL certificate. p.s. on a main page you can find contact information under my picture.
Hi Vadim, Thanks for the great post, it helped me confirm I am not alone facing the problem. So is there any work around this problem in your knowledge? I also sent you an email, kindly if you respond, thanks, Uzair
As stated in the post you need to contact your certificate issuer (GoDaddy) to obtain SSTP-compatible certificate. Or find another commercial CA. However you must note that other certificate issues may cause this error message.
I'm in the process of setting up SSTP and I've read a number of articles regarding this problem. I'm curious if anyone has a list of CA's that readily provide certs that work with SSTP where the WIn7 clients already have the full chain in their cert store?
I'm in the process of setting up SSTP and I've read a number of articles regarding this problem. I'm curious if anyone has a list of CA's that readily provide certs that work with SSTP where the WIn7 clients already have the full chain in their cert store?
You followed all steps from a Deploying SSTP Remote Access Step by Step Guide. However, when windows 8.1 or windows 7 client tries to connect VPN server you get this error: ” Error 0x80092013: The revocation function was unable to check revocation because the revocation server was offline. ”
Solution: SSTP Windows VPN Client Error: The revocation function was unable to check revocation
Hope it helps you too.
Post your comment:
Comments: