Summary: I am trying to set up an RRAS server with SSTP support. If I issue this RRAS server a certificate from a standalone 2008R2 CA server, my Windows 7 client can establish an SSTP VPN connection but if I set up the same environment using an Enterprise CA server, it will always fail with Error 0x80092013 complaining that the revocation server was offline. I set up my original SSTP lab using instructions from http://technet.microsoft.com/en-us/library/cc731352(v=ws.10).aspx and was able to get it to work after some slight modifications and then proceeded to set up my own lab My environment: Domain Controller: 2008R2 Standard edition with a user account, vpnuser configured with dial-in permissions RRAS/CA server: 2008R2 Enterprise edition with one nic and a domain member Router: Hardware NAT router with port 443 forwarded to the internal IP address of my RRAS/CA server Client: Windows 7 Professional - 32-bit in a workgroup and is at another internet connected location. General setup: I have set up this lab many times in a virtual environment, rolling back to a base snapshot before reconfiguring and the only variation is that the Certificate server is sometimes set up as a standalone CA server and other times it is set up as an Enterprise Root CA server but everything else remains the same including names, IP addresses, etc. CA Server Setup: When setting up my CA server, I install the CA server and the web enrollment service and I choose all the default settings. After the initial installation, I choose the properties of the CA server and go to the Extensions tab and for the CRL distribution point, I remove all the preconfigured extensions and add one http extension in the form of http://www.mypublicwebserver.com/CertEnroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl and check the boxes to include in CRLs and CDP extensions. I publish the CRL to http://www.mypublicwebserver.com/CertEnroll/ where it is publicly available to anyone. Issuing the RRAS certificate: Standard CA: If I am using a standard CA server, I use webenrollment to go to http://localhost/certsrv and choose request a certificate / advanced certificate request / create and submit a request to this CA and in the Name field, I type the external dns address that my clients will use such as vpn.mydomain.com (this is NOT the internal dns name of my RRAS/CA server). Under Type of certificate needed, I choose the dropdown for Server Authentication Certificate and under Key options, I check the box to mark keys as exportable. I submit the request, approve it on the standalone CA, come back to my web page and install the certificate. I then export and re-import the certificate into the proper Certificates (Local Computer) / Personal. Enterprise Root CA: If I am using an Enterprise Root CA, my procedures are a little gray here because I am not entirely clear how it should be done. I use Certificate Templates (mydomaincontroller) to duplicate the computer template and I have also tried duplicating the RAS and IAS Server template. When duplicating a template, I go to the subject name tab and change it to "supply in the request". On the extensions tab, I sometimes click on Application polices and remove Client Authentication, leaving only Server Authentication. After duplicating my templates, I configure the CA to issue the duplicated certificates. I don't usually use the web enrollment page because it acts so much differently under enterprise than it does under standard. I usually use mmc to load up the certificates (local computer) snap-in and go to Personal and request the certificate from there. I have tried different variations but usually I only enter vpn.mydomain.com under Subjet Alternative Name / DNS and request the certificate. My resulting RRAS certificate: Whether I issued it from a standard CA or from an Enterprise Root CA, my resulting certificate appears very similar and seems to have the correct properties. Enhanced Key Usage: Server Authentication, CRL Distribution Points: URL=http://www.mypublicwebserver.com/CertEnroll/myCA.crl RRAS Server Setup: In my lab, I am setting this up on the same server as my CA server. Under Network Policy and Access Services, I select only the Routing and Remote Access Service checkbox, the Remote Access checkbox and the Routing checkbox. After installation, I right click to configure and enable routing and remote access and choose the Custom configuration (because I only have 1 nic) and check only the box for VPN Access. In this lab, my Domain Controller is also my DHCP server so I configure the IPv4 tab for DHCP. On the Security tab, under SSL Certificate Binding, I can hit view and see that it has bound to the correct certificate I have issued for the RRAS server. Windows 7 Client: I install the CA certificate and place it in Certificates (local computer) / Trusted Root Certification Authorities. I also verify that I can reach http://www.mypublicwebserver.com/CertEnroll/myCA.crl. My VPN connection is set up to only use SSTP. Attempting the connection from my Windows 7 client: I connect with the same user account vpnuser, supplying the password and domain name. RRAS issued certificate by Standalone CA: The connection is successful and everything works. The connection is solid and I have access to resources on my internal network. RRAS issue certificate by Enterprise Root CA: After a few seconds, I get: "Error 0x80092013 The revocation function was unable to check revocation because the revocation server was offline" Comments: In either scenario, my client can reach the public http address configured in the RRAS certificate so I don't understand what difference it makes whether the RRAS certificate was issued by a standalone CA or an Enterprise Root CA. From my Windows 7 client, for either scenario I can open Internet Explorer and type in the address of: https://vpn.mydomain.com/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ . I click the padlock and can view my RRAS certificate. I have been working on this for about a week and am very frustrated. Does anyone have any ideas? Thanks, RodRod Miller

OK. After taking a weekend to walk away from this, I think I have found the answer to my problem. I'm still very much a newbie in the certificate services arena so I'm still working out some of the details but here is the process I went through to finally get it to work. Summary of fix: Although I could not see it initially, the RRAS certificate pointed to a public crl which pointed to a non-public ldap delta crl. The problem seemed to be in the way I was configuring my extensions on my Enterprise CA server. I was deleting everything in the CRL extension area and replacing them with a single http entry. Apparently, since I had removed all the default entries, The Enterprise CA server had used some internal defaults to configure an ldap based delta crl. I fixed it by keeping all the defaults but replacing the http entry with a custom entry, checking the "Include in CRL" box and the "Include in the CDP" box and then clicking on ldap and unchecking all existing checkboxes. Read on for more detail Detailed troubleshoooting steps: 1st, I started Googling my problem in other ways and I found several posts by Brian Komar (author of what seems to be the only book on certificate services) talking about using pkiview.msc to do some troubleshooting. Keep in mind that whether I used an Enterprise Certificate server or a Standard standalone certificate server, I issued a certificate for my RRAS server that had only 1 CDP extension in it that pointed to an http public location. When viewing the resulting certificate, it only had that 1 http location defined it in and since that 1 public location was reachable by my Windows 7 client, I couldn't understand why my client computer claimed that the revocation server was offline. I ran pkiview.msc on my CA/RRAS server and found the following: When my lab was set up with a Standard CA server, pkiview.msc reported only a CDP Location #1 pointing to my public http siteWhen my lab was set up with an Enterprise CA server, pkiview.msc it reported CDP Location #1 AND a DeltaCRL Location #1 pointing to a ldap location that my external client did not have access to. I couldn't understand why an ldap location showed up on pkiview since I had only defined 1 http location and my RRAS certificates reported that one location. Then while on my RRAS/CA server I exported my RRAS certificate to a RRAS.cer file and ran the following command: certutil -urlfetch -verify RRAS.cerIn the Certificate CDP section, it reported that it verified a base CRL on my public http site (which I had defined)It also reported that it verified a Delta CRL at an ldap location (which I had NOT defined) I copied the RRAS.cer file to my offsite client location and ran the same command certutil -urlfetch -verify RRAS.cerIt reported the same two locations, the base CRL at the http siteIt reported the delta crl at the ldap site which it reported that it could not reach (which makes sense given the fact it was offsite)It also reported the same error that my Windows 7 client had reported when trying to establish the VPN ("Error 0x80092013 The revocation function was unable to check revocation because the revocation server was offline") At this point, not fully understanding this subject yet, I wasn't sure why the ldap location kept coming up since I had not defined it. So I did the following: On my RRAS/CA server, I went to c:\windows\system32\certsrv\CertEnrollThere were 3 files consisting of mycaserver.crl, mycaserver+.crl and mycaserver.crt (all of these files had also been manually copied to my public http site)I opened mycaserver.crl fileIt contained a "Freshest CRL" entry which I understand to be another name for Delta CRL. It contained the ldap location that kept coming up in my pkiview.msc report and explained the reason why my client said the revocation server was offline. Now, I think I understand the following when I try to establish a VPN connection from my Windows 7 client My Windows 7 client attempts to connect to my SSTP vpn server at vpn.mydomain.comMy hardware router at the VPN site forwards port 443 to my vpn server and my client views the RRAS certificate.The RRAS certificate has a CDP extension that points to my public http siteMy client, reads the mycaserver.crl at my public http site and finds that it contains a reference to mycaserver+.crl at an ldap siteSince my client does not have access to this ldap site, it fails with the error that it cannot reach the CDP server Now that I understand where the ldap location was coming from, I did NOT understand how the delta CRLs were being published with an ldap location. Through some troubleshooting and trial and error, I found the following: I am now on my RRAS/CA server (which is configured with a single Enterprise Root CA)Under Roles, I go to Active Directory Certificate services and right click on mycaserver and choose properties and go to the Extensions tabKeep the dropdown box at CRL Distribution Point (CDP)By default, if you simply install the CA server as an enterprise CA and take all the defaults, you have 4 entries in this area consisting of a C:Windows\system32..., an ldap entry, a file entry and an http entry.In my NON-Working Enterprise CA scenario, I had been deleting all of these entries and replacing it with one entry as follows: http://mypublicwebserver/CertEnroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl . Then underneath, I had been checking the two boxes for "Include in CRLs" and "Include in the CDP extension of issued certificates"When configured in this manner, even though I only had the single http entry, the system was somehow automatically issuing a delta crl at an ldap location. I'm not sure why it does this on an Enterprise CA and NOT a standard CA, but it seems to be the case This is what I did to get it to work This was only a lab, so I reset my lab snapshot and re-installed my Enterprise CA server taking all the defaultsProperties of my CA server / Extensions / CRL Distribution Point (CDP)By default, an http entry is defined pointing to the local CA server AND NO checkboxes are checkedI deleted the http entry replacing it with http://mypublicwebserver/CertEnroll/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl and checked the two boxes for "Include in CRLs" and "Include in the CDP extension of issued certificates"I left the C:\Windows\system32...... entry intact making no changesI clicked on the ldap entry. By default, all but the last check box are checked. I unchecked ALL of them (I'm not saying this is the right way yet and I may have introduced other problems that I am not aware of yet and I may go back later and fine tune this)I also left the file:// entry intact, making no changes here.I clicked OK and let it restart the CA services.I went to Certificate templates and duplicated the Computer template just leaving it as "copy of computer". I also clicked on the Subject name tab and changed it to "Supply in the request" and clicked OKUnder mycaserver / I right clicked Certificate Templates and chose New / Certificate Template to Issue and chose "Copy of Computer"I opened MMC and installed the certificates snap-in for (local Computer)I clicked Personal / Certificates and chose All tasks / Request new certificate / Next / NextI chose Copy of computer and clicked the "More information needed" linkUnder the Subject tab, under Alternative name, I changed the type to DNS and typed vpn.mydomain.com in the value field.I clicked OK and then enrollI restarted my RRAS services and then checked under the properties of RRAS / Security / SSL Certificate Binding / View ---- to verify that it was bound to the new RRAS certificate I had just issued. After doing all of this, I went back to my Windows 7 client and made sure the Root CA certificate was installed and then established my SSTP connection and everything worked. I know this is a long detailed response to my long question but hopefully someone else can be helped here. I am still trying to learn this subject but I find that the material is rather sparse on the subject compared to other areas. If anyone reads this and has some further pointers or best practices to offer, I would appreciate a response. What I am really interested in doing after this is setting up either an L2TP or IPSEC vpn that is more secure than PPTP. I'm not sure which one would be best. Rod Rod Miller

Hi rodqmiller, Glad to hear that the issue had been resolved and thanks for sharing these with us. We believe these will benefit others who also encounter such issue in future . Hope you will enjoy our TechNet forum ! Tiger LiTiger Li TechNet Community Support