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:
Authority Info Access Access Method=On-line Certificate Status Protocol (126.96.36.199.188.8.131.52.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.
Post your comment: