This has been frustrating to say the least. I have a little lab of VMs I'm using to test configuring SSTP VPN connections: I have: External client: A win7 clientDC: A 2008 R2 DCcert srv: A 2008 R2 srv running ADCS, IIS for web enrollment, and the OCSP serviceVPN srv: A 2008 R2 srv running NPS, RRAS with external and internal nics I set everything up following tutorials I found online and this is where I am right now: Added the http crl, AIA, and OCSP locations to the cert I issued to my vpn srv I have the root CA cert and the cert for the vpn (which I exported from the VPN server) installed on the clientMade sure http: crl locations were accessible to the external clientWhen I run certutil -URL [mycert] on the external client it successfully verifies the http CRL and AIA locations. It even successfully verifies the OCSP AIA location. BUT when I try to initiate an SSTP vpn it fails with the "revocation server offline" error. What could I be doing wrong?

most likely this is because your root is installed in the current user's profile (user certificate store). Instead, it must be installed in the computer store, Trusted Root CAs container. Run blank MMC (in elevated mode), add Certificates snap-in and point it to local computer context. Switch to Trusted Root CAs node and import your root CA certificate.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

I did this. On the external client the root cert is definitely installed in the local computer's trusted root ca certificate's store and the vpn cert is installed in the local computer's personal store.

please, run 'certutil -verify -urlfetch sstpcert.cer' command against SSTP SSL certificate. The command must be completed on the client where you recieve error message.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

sorry it took me so long to respond. Here are the names of my VMs so this output makes more sense win7 client: "WK01" DC: "DCM" cert srv: "DC2" (this is not a domain controller) VPN+RRAS srv: "infra-01" domain: "lab.local" This is the output of certutil -verify -urlfetch: C:\dump>certutil -verify -urlfetch C:\Users\Administrator.WK01\Desktop\sstpcert. cer Issuer: CN=lab-DC2-CA DC=lab DC=local Subject: CN=10.111.222.10 Cert Serial Number: 116bee99000000000013 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.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40) ChainContext.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000) ChainContext.dwRevocationFreshnessTime: 2 Days, 9 Hours, 31 Minutes, 26 Seconds SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) SimpleChain.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40) SimpleChain.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000) SimpleChain.dwRevocationFreshnessTime: 2 Days, 9 Hours, 31 Minutes, 26 Seconds CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=1000040 Issuer: CN=lab-DC2-CA, DC=lab, DC=local NotBefore: 10/21/2012 12:32 AM NotAfter: 10/16/2013 6:53 AM Subject: CN=10.111.222.10 Serial: 116bee99000000000013 Template: 1.3.6.1.4.1.311.21.8.8258498.6913409.4803508.10294571.266286.210.975 3765.15554154 d3 2d 5d 9b da 0f 7f 32 4c 82 e7 e5 95 d2 08 19 ba ee d0 9e Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2) Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100) Element.dwErrorStatus = CERT_TRUST_REVOCATION_STATUS_UNKNOWN (0x40) Element.dwErrorStatus = CERT_TRUST_IS_OFFLINE_REVOCATION (0x1000000) ---------------- Certificate AIA ---------------- Failed "AIA" Time: 0 Error retrieving URL: Logon failure: unknown user name or bad password. 0x80 07052e (WIN32: 1326) ldap:///CN=lab-DC2-CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Confi guration,DC=lab,DC=local?cACertificate?base?objectClass=certificationAuthority Verified "Certificate (0)" Time: 0 [1.0] http://dc2.lab.local/CertEnroll/DC2.lab.local_lab-DC2-CA.crt ---------------- Certificate CDP ---------------- Failed "CDP" Time: 0 Error retrieving URL: Logon failure: unknown user name or bad password. 0x80 07052e (WIN32: 1326) ldap:///CN=lab-DC2-CA,CN=DC2,CN=CDP,CN=Public%20Key%20Services,CN=Services,C N=Configuration,DC=lab,DC=local?certificateRevocationList?base?objectClass=cRLDi stributionPoint Verified "Base CRL (05)" Time: 0 [1.0] http://dc2.lab.local/CertEnroll/lab-DC2-CA.crl Failed "CDP" Time: 0 Error retrieving URL: Logon failure: unknown user name or bad password. 0x80 07052e (WIN32: 1326) [1.0.0] ldap:///CN=lab-DC2-CA,CN=DC2,CN=CDP,CN=Public%20Key%20Services,CN=Se rvices,CN=Configuration,DC=lab,DC=local?deltaRevocationList?base?objectClass=cRL DistributionPoint Expired "Delta CRL (05)" Time: 0 [1.0.1] http://dc2.lab.local/CertEnroll/lab-DC2-CA+.crl ---------------- Base CRL CDP ---------------- Failed "CDP" Time: 0 Error retrieving URL: Logon failure: unknown user name or bad password. 0x80 07052e (WIN32: 1326) ldap:///CN=lab-DC2-CA,CN=DC2,CN=CDP,CN=Public%20Key%20Services,CN=Services,C N=Configuration,DC=lab,DC=local?deltaRevocationList?base?objectClass=cRLDistribu tionPoint Expired "Delta CRL (05)" Time: 0 [1.0] http://dc2.lab.local/CertEnroll/lab-DC2-CA+.crl ---------------- Certificate OCSP ---------------- Expired "OCSP" Time: 0 [0.0] http://dc2.lab.local/ocsp -------------------------------- CRL 05: Issuer: CN=lab-DC2-CA, DC=lab, DC=local db 92 7f c5 cc 66 fc 4d 91 84 79 fe ab 38 3e c1 a7 27 91 4d Delta CRL 05: Issuer: CN=lab-DC2-CA, DC=lab, DC=local b8 3c 0c 0f c3 30 94 6c 2e 1e 3d 98 42 02 6a 22 74 25 9a 6c Application[0] = 1.3.6.1.5.5.7.3.1 Server Authentication CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0 Issuer: CN=lab-DC2-CA, DC=lab, DC=local NotBefore: 10/16/2012 6:43 AM NotAfter: 10/16/2013 6:53 AM Subject: CN=lab-DC2-CA, DC=lab, DC=local Serial: 5220174a8a653ca842a0362c17326c98 f5 60 40 58 48 6f 5a 3e 9e 40 89 e9 09 47 df 19 c4 b9 4d ae 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 -------------------------------- Exclude leaf cert: 18 5e e4 e7 11 f1 dd f4 78 e9 f0 fd df 3e f2 33 1f ab 4f 00 Full chain: 74 c9 87 4d 77 8e ef cc b5 e2 4f f0 a0 ee 7a 56 c7 d2 2d 68 Issuer: CN=lab-DC2-CA, DC=lab, DC=local NotBefore: 10/21/2012 12:32 AM NotAfter: 10/16/2013 6:53 AM Subject: CN=10.111.222.10 Serial: 116bee99000000000013 Template: 1.3.6.1.4.1.311.21.8.8258498.6913409.4803508.10294571.266286.210.975 3765.15554154 d3 2d 5d 9b da 0f 7f 32 4c 82 e7 e5 95 d2 08 19 ba ee d0 9e The revocation function was unable to check revocation because the revocation se rver was offline. 0x80092013 (-2146885613) ------------------------------------ Revocation check skipped -- server offline ERROR: Verifying leaf certificate revocation status returned The revocation func tion was unable to check revocation because the revocation server was offline. 0 x80092013 (-2146885613) CertUtil: The revocation function was unable to check revocation because the rev ocation server was offline. CertUtil: -verify command completed successfully. ---------------------------------------------------------- It looks like its verifying the http locations right? If there are any other commands I can run to provide more info let me know and I'll run them when I get back from work.

Expired "Delta CRL (05)" Time: 0 [1.0] http://dc2.lab.local/CertEnroll/lab-DC2-CA+.crl ---------------- Certificate OCSP ---------------- Expired "OCSP" Time: 0 [0.0] http://dc2.lab.local/ocsp your delta CRL is expired.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

So I should publish my CRL on the CA and try this again? I don't think this is the issue though because when I was looking at this before by doing a certutil -URL and verifying through the little GUI it said verified for the delta- not expired. The delta CRL must have expired after I opened this thread. I'll publish the CRL on my CA and try again, but if I still have this issue is there additional info I can provide or things I should try? Thanks a lot for your help on this.

I think the use of non-accessible LDAP based CDPs is enough to upset SSTP. Try issuing a new SSTP certificate which does not contain the LDAP CDP entries and see if that helps. The latest MS best practice recommends the use of a single highly available CDP using HTTP only: http://technet.microsoft.com/en-us/library/ee619783(v=ws.10).aspx Cheers JJ Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

I'll try this. Do you think it is possible the sstp connection is timing out before getting to the http CDP locations?

I'll try this. Do you think it is possible the sstp connection is timing out before getting to the http CDP locations? I might be wrong, but I think SSTP expects all defined CDPs to return verified.Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

since SSTP uses default revocation checking APIs, this may not be the case. I think, there are problems with expired CRLs.My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com Windows PKI reference: on TechNet wiki

Well I published the CRLs and refreshed the OCSP revocation cache AND removed all internal (ldap) CDP and AIA extensions and now its finally working. I guess it was the expired CRLs, but I swear it verified all the http locations before and still failed. Either way I'm glad its working. Thanks for all the help, this forum is such an awesome resource.

It would be interesting to see if it fails again if you put the ldap references back in, but I am guessing Vadims may be right ;) May be useful to others if you can spare the time to test? Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

I issued another cert with the LDAP locations and it works now. I think maybe I screwed something else up before. Wish I knew what that could have been, but oh well.