Hi, I am trying to set up SSTP with a public Thawte certificate but I get 0x80092013. I have seen several topics on this error but none of the answers seem to fit. I have checked that the CRL can be downloaded by the VPN client PC with no problem from the Distribution Point specified in the certificate: http://svr-ov-crl.thawte.com/ThawteOV.crl which is the only CRL distribution point specified. When I browse with IE on the VPN client PC to the SSTP server (https://mysstpserver.mycompany.com) I get a 403 error as expected but I can click the padlock and see the full certificication path chain and everything looks fine. "openssl s_client -connect" also works fine so I don't see anything obviously wrong at the SSL level. If I save the certificate to a .cer file and run certutil -verify -urlfetch mycert.cer on the same VPN client PC then I get the output below. Should I also pass in the intermediate certificate that I know is installed on the server? Issuer: CN=Thawte SSL CA O=Thawte, Inc. C=US Subject: CN=xxx OU=xx O=xxx L=xxx S=xxx C=xxx Cert Serial Number: xxx 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.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40) ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000) ChainContext.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000) SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40) SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000) SimpleChain.dwErrorStatus = CERT_TRUST_IS_PARTIAL_CHAIN (0x10000) CertContext[0][0]: dwInfoStatus=4 dwErrorStatus=1000040 Issuer: CN=Thawte SSL CA, O="Thawte, Inc.", C=US NotBefore: 1/02/2011 11:00 AM NotAfter: 2/02/2012 10:59 AM Subject: xxx Serial: xxx xxx Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4) Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40) Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000) ---------------- Certificate AIA ---------------- No URLs "None" Time: 0 ---------------- Certificate CDP ---------------- OK "Base CRL (025c)" Time: 1 [0.0] http://svr-ov-crl.thawte.com/ThawteOV.crl ---------------- Certificate OCSP ---------------- Unsuccessful "OCSP" Time: 0 [0.0] http://ocsp.thawte.com -------------------------------- Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication Exclude leaf cert: xxx Full chain: xxx Missing Issuer: CN=Thawte SSL CA, O="Thawte, Inc.", C=US Issuer: CN=Thawte SSL CA, O="Thawte, Inc.", C=US NotBefore: 1/02/2011 11:00 AM NotAfter: 2/02/2012 10:59 AM Subject: xxx Serial: xxx xxx A certificate chain could not be built to a trusted root authority. 0x800b010a (-2146762486) ------------------------------------ Incomplete certificate chain Cannot find certificate: CN=Thawte SSL CA, O="Thawte, Inc.", C=US Cert is an End Entity certificate ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613) CertUtil: The revocation function was unable to check revocation because the revocation server was offline. CertUtil: -verify command completed successfully. I know I can disable CRL checking but any changes to VPN client PCs are impractical because I won't have control over these and the users are non-technical. It's almost as if SSTP won't work with Intermediate certificates but I'm really hoping I've overlooked something simple. Many thanks in advance!

it looks like client PC is missing Thawte root CA certificate in Trusted Root CAs in computer store. Try to add it manually.http://en-us.sysadmins.lv PowerShell PKI module: http://pspki.codeplex.com/

Thanks for the suggestion. The Thawte root CA certificate is "thawte Primary Root CA" valid to 17 July 2036 (34 4e d5 57 20 d5 ed ec 49 f4 2f ce 37 db 2b 6d) which is installed in the Local Computer Trusted Root Certification Authorities certificate store by default on Windows 7 as far as I can tell. As above, it chains up fine when I point IE at my server ... wouldn't that mean the root is fine from the client's perspective?

Hi Richard, Thanks for posting here. According the error massage that client might unable to download the leaf certificate “ Thawte SSL CA “ due to no AIA URLs. ---------------- Certificate AIA ---------------- No URLs "None" Time: 0 Could you verify the certificate path properties of thawte Primary Root CA form CA server and VPN client ,please also post back the result here for further investigation? Thawte Primary Root CA |- Thawte SSL CA (Missing) |- <SSTP service> Please also capture the traffic from client when VPN connection is established by using network monitor and upload the captured result to the link below: https://sftus.one.microsoft.com/choosetransfer.aspx?key=cd569d6b-e829-4d20-a9e9-3206f6712ea9 Password: bC0Z7*fI)MCJpq For more information please refer to the link below: Microsoft Network Monitor 3.4 http://www.microsoft.com/downloads/en/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en How to use Network Monitor to capture network traffic http://support.microsoft.com/kb/812953 Thanks. Tiger Li TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.comPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

On Mon, 28 Mar 2011 05:03:06 +0000, Tiger Li wrote: According the error massage that client might unable to download the leaf certificate ? Thawte SSL CA ? due to no AIA URLs. That should the "intermediate" certificate and not "leaf" certificate. Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca Computer programmers do it byte by byte.

Thanks Tiger and Paul! To clarify... the "mycert.cer" file only contains my server's leaf certificate and not the intermediate certificate. But, the intermediate certificate is installed on the server and IE manages to chain up to the root OK. Would certutil -verify -urlfetch mycert.cer usually manage to find the intermediate certificate given that it is only being fed the leaf certificate? Note, the intermediate certificate is not installed on the client (cannot be because clients are vanilla standalone Win 7 users around the world not in my domain) I will research AIA because that is new to me and I will also play with Network Monitor because I've only used Wireshark before. Also happy to email the server URL if anyone has time to check it via the Internet (already sent to the email in your signature Tiger). Thanks again, Richard.

On Mon, 28 Mar 2011 05:35:25 +0000, Richard Swift wrote: Also happy to email the server URL if anyone has time to check it via the Internet (already sent to the email in your signature Tiger). Feel free to email me the URL Richard. pkadare AT gmail DOT com Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca Any sufficiently advanced bug is indistinguishable from a feature. -- Kulawiec

My assumption is that either: 1) certificate wasn't issued by real Thawte CA. This is because certificate chaining engine is unable to find corresponding issuer's certificate in the local store. 2) Required Thawte CA certificates are missing anyway. You may perform some basic checks: each certificate's Authority Key Identifier extension MUST match corresponding issuer's certificate Subject Key Identifier. Make sure if this is true for all certificates in the chain.My weblog PowerShell PKI Module

IE shows "Certificate status: This certificate is OK." there are the three certificates (root, intermediate and leaf) in the "Certification path" The root certificate is "thawte" Subject Key Identifier is: "7b 5b 45 cf af ce cb 7a fd 31 92 1a 6a b6 f3 46 eb 57 48 50" The intermediate CA is "Thawte SSL CA" Authority Key Identifier is: "KeyID=7b 5b 45 cf af ce cb 7a fd 31 92 1a 6a b6 f3 46 eb 57 48 50" Subject Key Identifier is: "a7 a2 83 bb 34 45 40 3d fc d5 30 4f 12 b9 3e a1 01 9f f6 db" My server certificate is: "secure.mydomain.com" Authority Key Identifier field does not exist Subject Key Identifier field does not exist Serial number is: "37 0f 1e 01 3e a5 87 7f 30 d6 02 85 d3 6d fe c3" Issuer is: CN = "Thawte SSL CA" O = "Thawte, Inc." C = "US" Does IE do something different to SSTP? I have several SSL web sites using similar certificates that all work fine but this is the first try with SSTP. Thanks again for

file uploaded as requested.... cheers.

does exist Thawte SSL CA certificate in Intermediate CAs store (in local computer context)? BTW, it looks like this is your case: https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO15171&actp=search&viewlocale=en_US&searchid=1282614432001 http://en-us.sysadmins.lv http://pspki.codeplex.com

The "Thawte SSL CA" certificate is installed on the server Intermediate CAs store. I cannot add intermediate certificates to every Windows 7 PC client PC but the root is installed.

check the link above.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

Thanks. I just double-checked again and the Intermediate certificate is already installed on the server (exactly as described in the link above). This is evidenced when I point IE at the server and I can see the intermediate certificate in the chain.

can you run 'certutil -verify -urlfetch' command and paste an output?My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

Thanks again for your help! Here is the output from the SSTP Server: certutil -verify -urlfetch secure.cer Issuer: CN=Thawte SSL CA O=Thawte, Inc. C=US Subject: CN=xxx OU=xxx O=xxx L=xxx S=xxx C=xxx Cert Serial Number: 370f1e013ea5877f30d60285d36dfec3 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) ChainContext.dwRevocationFreshnessTime: 4 Days, 3 Hours, 5 Minutes, 12 Seconds SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) SimpleChain.dwRevocationFreshnessTime: 4 Days, 3 Hours, 5 Minutes, 12 Seconds CertContext[0][0]: dwInfoStatus=104 dwErrorStatus=0 Issuer: CN=Thawte SSL CA, O="Thawte, Inc.", C=US NotBefore: 1/02/2011 11:00 AM NotAfter: 2/02/2012 10:59 AM Subject: xxx , S=xxx Serial: 370f1e013ea5877f30d60285d36dfec3 fe b6 cb 68 7d 6b c0 3b cc cd 41 f5 bf f5 4e 5e e0 ff c9 c6 Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- Certificate AIA ---------------- No URLs "None" Time: 0 ---------------- Certificate CDP ---------------- Verified "Base CRL (0265)" Time: 2 [0.0] http://svr-ov-crl.thawte.com/ThawteOV.crl ---------------- Base CRL CDP ---------------- No URLs "None" Time: 0 ---------------- Certificate OCSP ---------------- Verified "OCSP" Time: 0 [0.0] http://ocsp.thawte.com -------------------------------- CRL (null): Issuer: CN=Thawte SSL OCSP Responder, O="Thawte, Inc.", C=US 01 b8 74 12 4f ca 5a 01 d3 1f 17 66 00 85 7b ba 76 73 da e8 Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication CertContext[0][1]: dwInfoStatus=102 dwErrorStatus=0 Issuer: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US NotBefore: 8/02/2010 11:00 AM NotAfter: 8/02/2020 10:59 AM Subject: CN=Thawte SSL CA, O="Thawte, Inc.", C=US Serial: 4d5f2c3408b24c20cd6d507e244dc9ec SubjectAltName: Directory Address:CN=VeriSignMPKI-2-9 73 e4 26 86 65 7a ec e3 54 fb f6 85 71 23 61 65 8f 2f 43 57 Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) ---------------- Certificate AIA ---------------- No URLs "None" Time: 0 ---------------- Certificate CDP ---------------- Verified "Base CRL" Time: 1 [0.0] http://crl.thawte.com/ThawtePCA.crl ---------------- Base CRL CDP ---------------- No URLs "None" Time: 0 ---------------- Certificate OCSP ---------------- Verified "OCSP" Time: 0 [0.0] http://ocsp.thawte.com -------------------------------- CRL (null): Issuer: CN=thawte Primary Root OCSP Responder, O="thawte, Inc.", C=US e2 71 f4 13 87 7c 56 06 90 91 87 b0 a3 f2 97 d8 bb 70 b9 2f Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication Application[2] = 1.3.6.1.5.5.7.3.4 Secure Email Application[3] = 1.3.6.1.5.5.7.3.3 Code Signing CertContext[0][2]: dwInfoStatus=10c dwErrorStatus=0 Issuer: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US NotBefore: 17/11/2006 11:00 AM NotAfter: 17/07/2036 10:59 AM Subject: CN=thawte Primary Root CA, OU="(c) 2006 thawte, Inc. - For authorized use only", OU=Certification Services Division, O="thawte, Inc.", C=US Serial: 344ed55720d5edec49f42fce37db2b6d 91 c6 d6 ee 3e 8a c8 63 84 e5 48 c2 99 29 5c 75 6c 81 7b 81 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) ---------------- Certificate AIA ---------------- No URLs "None" Time: 0 ---------------- Certificate CDP ---------------- No URLs "None" Time: 0 ---------------- Certificate OCSP ---------------- No URLs "None" Time: 0 -------------------------------- Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication Application[1] = 1.3.6.1.5.5.7.3.2 Client Authentication Application[2] = 1.3.6.1.5.5.7.3.4 Secure Email Application[3] = 1.3.6.1.5.5.7.3.3 Code Signing Exclude leaf cert: 20 82 25 2a 5f 9a 58 9f 7a a2 e6 98 95 86 fe bb 35 80 a2 52 Full chain: 1a 80 36 95 c4 fb 9b c4 03 52 5b 52 36 0f 21 1d 52 9b a7 ab ------------------------------------ Verified Issuance Policies: None Verified Application Policies: 1.3.6.1.5.5.7.3.1 Server Authentication 1.3.6.1.5.5.7.3.2 Client Authentication Cert is an End Entity certificate Leaf certificate revocation check passed CertUtil: -verify command completed successfully.

now everything looks ok. Try again to instantiate VPN connection from a client.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

I still get the same error 0x80092013. The certutil output above is from the server. Output on the client is in the first post. I cannot install the Intermediate certificate on the clients.

On Mon, 28 Mar 2011 09:21:31 +0000, Richard Swift wrote: I still get the same error 0x80092013. Richard, if you'll email me the URL I'll have a look for you. pkadare AT gmail DOT com Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca A computer program does what you tell it to do, not what you want it to do.

On Mon, 28 Mar 2011 09:21:31 +0000, Richard Swift wrote: I still get the same error 0x80092013. The certutil output above is from the server. Output?on the _client_is in the first post. I cannot install the Intermediate certificate on the clients. So the problem you're having here with SSTP is that the SSL certificate installed on your server only has the On-line Certificate Status Protocol access method in the AIA extension. That works great for checking the certificate status with OCSP however, it will not work for certificate chain building: [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 In order for the certificate chain to be built correctly, the intermediate certificate in the chain need to be retrieved, and in order to retrieve them, the relying party needs to be told where to find them. This is done with the Certification Authority Issuer access method: [1]Authority Info Access Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2) Alternative Name: URL=http://xxx.xxx.com/pki/xxx.crt The certificate you have from Thwate, while acceptable for web servers is not acceptable for SSTP. The reason IE can build the chain correctly is that you have the intermediate certificate installed on the server and IIS sends the certificate chain, including the intermediate certificate to the client. This is why IE works in building the chain, and why your open-ssl command works, but both SSTP and the certutil commands fail. Neither SSTP nor the certutil command are hitting IIS on that server, they are both inspecting the presented certificate and trying to download the required intermediate cert and failing to do so due to the lack of the Certification Authority Issuer access method in the Authority Access extension in the certificate. The bottom line here is that you're either going to have to get Thwate to issue you a properly constructed certificate or find another vendor whose certificates are properly formed for SSTP. Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca You can't make a program without broken egos.

Hi Richard, since your client is missing the intermediate CA certificate , it's quite obvious your chain will not work. According to the RFC the chain must be filled up to the Root CA and you've got 3 ways to achieve it : - the client itself has the intermediate CAs in the store (filled manually or by GPO) - the endpoint connection is providing the full chain - the client is able to download from AIA location (however by the logs you've posted there are no locations referenced) could you try importing the intermediate CA to the store of the test computer and see if this works, just as PoC ? Alex

Thanks so much for your analysis Paul! Can anyone recommend a vendor that issues certificates that definitely work with SSTP? Verisign is ultra-expensive here so I'd prefer to use one of the cheaper guys if possible. btw, if SSTP and IIS both now sit atop http.sys for their SSL connections, isn't it more accurate to say that http.sys will send the intermediate certificate but the SSTP client is either ignoring it or not requesting it? Regardless, even if this was agreed to be a deficiency, it is what it is so I'll need to work around it and you are 100% right that a new certificate vendor is probably the easiest path! Cheers, Richard.

On Mon, 28 Mar 2011 10:42:24 +0000, Richard Swift wrote: btw, if SSTP and IIS both now sit atop http.sys for their SSL connections, isn't it more accurate to say that http.sys will send the intermediate certificate but the SSTP_client_is either ignoring it or not requesting it? No, IIS sends the chain, while SSTP does not. The client does not ignore the cert, SSTP simply does not send it. The RFC allows for three methods: 1. Installed locally. 2. The endpoint sends (this is what IIS does). 3. The client retrieves based on the AIA location. As far as vendors go, you could try GoDaddy. Before you choose a vendor ask them if their SSL certificates have the Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2) in the AIA extension. If not, move on to another vendor. Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca System going down at 5 pm to install scheduler bug.

Hi Alexander, >> the endpoint connection is providing the full chain The server does provide the full chain - "openssl s_client -connect" demonstrates this clearly. Cheers, Richard.

On Mon, 28 Mar 2011 10:54:34 +0000, Richard Swift wrote: The server?does provide the full chain - "openssl s_client -connect" demonstrates this clearly. That's because you've got IIS installed on the server and the openssl command is connecting to IIS and not the SSTP VPN server. Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca I smell a wumpus.

I am sure you are right Paul as you clearly know much more about this than I do .... but I am quite keen to understand why my theory is wrong. I just stopped IIS completely on the server ... no IIS running, only SSTP VPN is using 443 ... yet IE can still connect to the server and download the full certificate chain. How so if the SSTP server does not send the chain? My theory is that at the time the socket connection is established on port 443 and the SSL handshake is being negotiated the client has not yet revealed it wants /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ ... there is no secure socket established until the handshake is completed right? http.sys is shared between IIS and SSTP ... no? (all academic now - I know. I'll give GoDaddy a try - Cheers!)

On Mon, 28 Mar 2011 11:13:49 +0000, Richard Swift wrote: I just stopped IIS completely on the server ... no IIS running, only SSTP VPN is using 443 ...?yet IE can still connect to the server and download the full certificate chain. How so if the SSTP server does not send the chain? Are you sure that the intermediate cert wasn't cached locally on the client when you ran your test? Paul Adare MVP - Identity Lifecycle Manager http://www.identit.ca Overflow on /dev/null; please empty the bit bucket.

yep. 110% sure IIS is not running and openssl returns the whole chain on a host that has previously never connected to the SSTP server: Certificate chain 0 s:/C=xxx i:/C=US/O=Thawte, Inc./CN=Thawte SSL CA 1 s:/C=US/O=Thawte, Inc./CN=Thawte SSL CA i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA 2 s:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com

What paul meant I think is that the client where you are running openssl already has the intermediate cert cached ... clean the stores and do a reboot, then do it again

The client where I ran openssl had never connected to the sstp server before so it can't be cached. Futhermore, IIS has never been bound to port 443 on that server yet Paul was able to download the chain in IE...

I just got a GoDaddy certificate with the right Access Method but still get error... ERROR: Verifying leaf certificate revocation status returned The revocation was unable to check revocation because the revocation server was offline x80092013 (-2146885613) From the new cert: [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.godaddy.com/ [2]Authority Info Access Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2) Alternative Name:

Richard, haven't seen your setup, so i just followed the first error. You're right(with http.sys) that any player that comes into Schannel should extract the full chain with a function. However the certificates in stores are virtually accessible by anybody so different methods can be called. Since i'm not familiar with code behind SSTP and don't want to misguide you anymore please refer back to post of Tiger Li and compare captures while you're accessing the IIS with browser and SSTP. It should be visible at which point you fail

Thanks Alexander. I sent the netmon trace to Tiger Li yesterday. Cheers.

The error indicates the inability to verify a CRL ERROR: Verifying leaf certificate revocation status returned The revocation was unable to check revocation because the revocation server was offline x80092013 (-2146885613) Run the certutil -verify -urlfetch against the exported CER, needs to be done as the SYSTEM If this is 2003 you will need to open an interactive command prompt. If it is 2008 you will need psexec - http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx PSEXEC -i -s -d cmd These will probably fail due to the proxy – The computer account needs to be able to access at least one of the crl paths on the certificate. Sometimes when using a proxy server or a pac file this may not be possible. Based on the traces the seems you are using a PROXY – 53 1.464849 10.32.20.101 10.32.80.8 HTTP HTTP/1.1 407 Proxy Authentication Required ( Access is denied. ) , NTLMSSP_CHALLENGE Authentication on this proxy device must be disabled so the computer can access the CRL paths via WINHTTP without being prompted for credentials.Sumesh P - Microsoft Online Community Support

Thanks for this. It is possible the Client PC running Network Monitor was configured for a proxy server so I will double-check and run a clean test from a direct-internet-conected PC. I will also be sure to use psexec to run as system and report back.

I have managed to find a Thawte SSL certificate which is valid until Feb next year and was originally issued by a root CA with no intermediate CA. SSTP seems to like this so I've now used this domain name as my SSTP server and everything works well universally. Sadly when this cert expires it looks like Thawte, GoDaddy and Verisign now only issue certificates via intermediate CAs and the SSTP client refuses to play nicely with this arrangement (at least in my experience) without throwing up a lot of challenges. I suspect this will be a problem for users wanting to use SSTP in a public CA environment moving forwards but I guess we can watch this space and see how things pan out... maybe there will be a small update to the SSTP client released sometime soon (hopefully before Feb 2012!) Thanks for everyone's help.

Hi, I've got a similar problem with my SSTP. I've tried many things. My CRL is viewable from the internet, I've also installed the OCSP online responder in case my CRL didn't work correctly. Whatever I do my connections keep failing. I think I know why but I don't know know how to solve the problem. To get the certificates for my client hosts, I did the following : - From my host,, I browsed my web-CA (IP/certsrv) and I clicked Download a CA certificate, certificate chain or CRL and then 'Download certificate from CA'. This is the certificate I put on my hosts in local computer->root CAs store. The only problem I see with this certificate is that it doesn't contain URLs for CRL and OCSP. When I run and extract URLs from a '>certutil -URL my-cer.cer' the output is 'No URL' for both OCSP and CRL. Whereas when I run this command on my initial CA root certificate, the URLs appear. Is my method the right way to generate client certificates for this purpose ?

my problem relates to public chained certificates that use an intermediate CA but it may also apply to a private CA if there is an intermediate certificate in the chain.

Hi, I've got a similar problem with my SSTP. I've tried many things. My CRL is viewable from the internet, I've also installed the OCSP online responder in case my CRL didn't work correctly. Whatever I do my connections keep failing. I think I know why but I don't know know how to solve the problem. To get the certificates for my client hosts, I did the following : - From my host,, I browsed my web-CA (IP/certsrv) and I clicked Download a CA certificate, certificate chain or CRL and then 'Download certificate from CA'. This is the certificate I put on my hosts in local computer->root CAs store. The only problem I see with this certificate is that it doesn't contain URLs for CRL and OCSP. When I run and extract URLs from a '>certutil -URL my-cer.cer' the output is 'No URL' for both OCSP and CRL. Whereas when I run this command on my initial CA root certificate, the URLs appear. Is my method the right way to generate client certificates for this purpose ? I've answered you at my blog. Please run 'certutil -verify -urlfetch SSTP.cer' against *SSTP SSL* certificate, but not against root certificate.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com