Whilst attempting to upload an ISO into a VMware datastore this morning, I got this error;
The operation failed for an undetermined reason. Typically this problem occurs due to certificates that the browser does not trust. If you are using self-signed or custom certificates, open the URL below in a new browser tab and accept the certificate, then retry the operation.
Solution
I’ve encountered this exact problem once before here: VMware: ISO Upload or Deploy OVA Fails ‘Undetermined Reason’ It happens because you do not trust the CA that signed the certificate that vSphere is using. Go back to the initial logon page and click ‘Download Trusted Root CA Certificates‘. Note: if you have a stupid browser that tries to open the file (I’m looking at you Microsoft Edge!) Then choose ‘Save target as’ and save the zip file containing the root CA Certificates.
Open the Zip file and choose the Windows or Mac version and locate the file that has the CRT extension, (the other file is a certificate revocation list, and you don’t need this). Double click the certificate and choose ‘Install Certificate‘.
Select ‘Local Machine‘.
Select the option to choose which store to use and put it in ‘Trusted Root Certification Authorities‘ > Then complete the import wizard, (and ensure it says import successful). Then restart your browser, log back into vSphere and try again.
Related Articles, References, Credits, or External Links
NDES, is the name for what we used to call MSCEP, which was an ‘add-on’ for the Server 2003 family of servers. In Server 2008 it was renamed to NDES. It is a role service that runs on a Certificate Services Server, and is used to create a registration authority (RA) that can issue certificates from your PKI infrastructure to network devices, i.e. Routers, Firewalls and Switches.
Solution
Installing Network Device Enrollment Service
I’m assuming you already have an Active Directory Certificate Services Server setup, if not you can deploy that and add in NDES at the same time.
1. Either: Launch Server Manager > Manage > Add Roles and Features > Below Active Directory Certificate Services select Network Device Enrollment Service.
2. Or: From within PowerShell run the following command;
1. Create a domain user (below I’ve called it SVC_NDES) > Add that user to the IIS_IUSRS group on the CA server.
2. From within Server Manager launch the post deployment configuration wizard.
3. Next.
4. Select Network Device Enrollment Service, (if not already selected).
5. Change the account details, to the service account you created above.
6. Enter the details that will be used to enroll the RA certificate.
7. Accept the defaults > Next.
8. Configure.
9. Close.
10. Launch the Certificate Authority management console > Certificate Templates > Right Click > Manage.
11. Open the properties of the ‘IPSec (Offline request)’ certificate > Security Tab > Make sure the account you created (above) has the ‘Enroll’ permission.
NDES Disable Password Requirement.
I’ve read a few blogs and articles that say;
“There is no way for Cisco devices to supply the required password to enroll with NDES/MSCEP, so you need to disable the requirement for a password.”
This is NOT TRUE, however the whole point of issuing certificates via your PKI infrastructure, is that it can scale dramatically. If you are creating passwords and embedding those passwords in all your enrollments, it can get a little unwieldy. So it may be sensible to remove the password requirement.
Update: 22/10/21: You may also need to recycle the SCEP application pool in IIS (on the Certificate Services Server)
From IIS Manager > CA > Application Pools, SCEP. > From the right hand panel > Advanced Settings. > Set Load User Profile to ‘True‘ > OK.
Again in the right panel > Recycle > From IIS Manager > Sites > Default Web Site. > From the right panel, click Restart.
Below you can see the difference, with the password requirement enforced, and without.
2. Restart the Certificate Services Service;
[box] net stop certsvc net start certsvc [/box]
NDES More Password Options and Renewing Certificates
If you do want the more secure option of using passwords, but don’t want to ad a new password every time you have a new enrollment, you can specify that the password does not expire after the default 60 minutes, in fact it never expires. This is handy if you want to renew certificates without generating new passwords. To do that carry out the following procedure;
[box] HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Cryptography > MSCEP[/box]
Create a new 32 bit DWORD value called ‘DisableRenewalSubjectNameMatch’ Set the value to 1 (one).
3. If (as above), you are running NDES under a service account, ensure that account has full control of the MSCEP key. (Again don’t forget to restart the Certificate Server service.)
IIS Query String Problem
You may find that with the default IIS settings you may encounter some problems. This is because (by default) IIS will only accept a Query String that’s less than 2048 characters long. If that happens you may see the following errors;
Request URL Too Long
HTTP Error 414. The request URL is too long.
HTTP Error 404.15 – Not Found
The request filtering module is configured to deny a request where the query string is too long.
When attempting to contact a server running the Certification Authority Web Enrolment role, you may see the following error.
In order to complete certificate enrolment, the Web site for the CA must be configured to use HTTPS authentication
Solution
The correct fix is to set the web server (IIS) to serve the certificate website securely using https, though you can just set Internet explorer to ‘work’ from your client machine if you are in a hurry.
Make Internet Explorer Accept Your Certification Authority
Note: This would need to be done on every machine that you wanted to access the Certificate Services web portal from.
1. From within Internet Explorer > Internet Options > Security > Trusted Sites > Sites.
2. Untick ‘Require server verification (https:) for all sites in this zone’ > Then add in the URL of the CA > Close.
3. With Trusted sites still selected > Custom level > ‘Initialize and script ActiveX controls not marked as safe for scripting’ > Enable > OK > Yes.
4. Restart the browser and try again.
Set IIS to serve Certificate Services Securely (via https).
This assumes you have your CA and the web portal installed correctly.
1. On the Certificate Services Server > Launch IIS Manager > Expand {server-name} > Sites > Default Web Site > Right Click > Edit Bindings > https > Edit > Select the self signed server certificate [NOT the CA ONE] > OK.
Note: If https is missing simply add it!
2. Expand Default Web Site > Certsrv > SSL Settings.
3. Tick ‘Require SSL’ > Apply.
4. That should be all you need, if it does not take effect straight away then drop to command line and run iisreset /noforce.
Related Articles, References, Credits, or External Links
I was setting up some HTTPS/SSL inspection this week and while testing it, I ran into this problem;
Firefox Certificate Settings
So the machine I’m using DOES trust the CA that issued that certificate, (it’s a FortiGate firewall) But the BROWSER does not. (Firefox maintains its own list of certificates, and more importantly which CA certificates it will trust). Essentially the browser is trying to protect you from a MITM attack.
Browse to about:prefernces#privacy > Certificates > View Certificates.
Import.
Navigate to the CA certificate for the authority that signed the certificate(s) you are having a problem with, and import it > Select ‘Trust this CA to identify websites” > OK
Related Articles, References, Credits, or External Links
With the newest version of AnyConnect (4.7) there’s an added feature called ‘Management VPN’. It’s there, so that if you have remote users who don’t VPN in very often, then you may struggle to mange them, e.g. put software updates, AV updates, SCCM packages etc. down to them.
Before version 4.7 you could configure ‘Automatically Connect’, or ‘Start before Logon’ to handle these problems, well now you can use Management VPN. What it does is, it automatically connects (using the computer certificate to authenticate), and it automatically disconnects when a remote user brings up a normalAnyConnect VPN user connection. When they disconnect again, the Management VPN (after a few seconds) will re-establish again.
As usual the Cisco documentation is not brilliant! So I built it out in EVE-NG to test. Here’s the Lab I used;
I’ve got a Windows 2012 R2 Server that’s doing Certificate services and DHCP, I’ve also got an external (Windows 7) client with AnyConnect 4.7 installed.
Solution
My first task was to setup normal user AnyConnect, which I secured with certificates, (user certificates), I sent the certificates out using auto-enrollment. Also while I had my certificate hat on, I generated a certificate for the outside of the ASA as well. (I didn’t bother setting up NDES I just imported the CA Certificate eon the ASA).
Note: If you already have working AnyConnect, then you can skip this section.
In addition, (much as I prefer to work at CLI, you need to go into the ASDM to do the following). Create a new connection profile and associate it with the group policy we just created (above).
Add to the ‘Server list‘ the URL you specified (above).
To avoid being prompted for which certificate to use, untick ‘Disable Automatic Certificate Selection’ (Yes the name makes no sense to me either!) Save the profile.
Then make sure the VPN works as expected.
Setup AnyConnect Management VPN
Prerequisites
Your ASA needs to be running newer than version 9, and your ASDM image needs to be 7.10(1) or newer.
You need to have the Anyconnect client software (4.7 or newer!)
I’ve already mentioned certificates, but you will need to have the CA certificate from the CA that’s generating your COMPUTER certificates installed and trusted, mine’s already there, as I’m already authenticating my USER certificates with it.
Add another Tunnel-Group and Group-Policy for your Management-VPN, I’ll drop back to CLI to do that (to keep things neat and tidy).
Add a new connection profile, set the type to ‘AnyConnect Management VPN Profile’, and link it to the Group-Policy for your AnyConnect USER connections.
As before add an entry to the server list with the same URL you specified in the Management VPN tunnel group.
Add an Automatic VPN policy, to connect whenever you are on a network that is NOT your corporate network. Here if a client sees my server, on the same network, or gets my domain name via DHCP it WONT connect.
Additional Settings Required for Management VPN
Edit the Group-Policy you are using for Management VPN > AnyConnect Client > Custom Attributes > Add > Create an Attribute called: ManagementTunnelAllAllowed.
Create a value for it called true/true.
In the ‘AnyConnect Client‘ section, ENABLE ‘Client Bypass Protocol’.
Your client will need to connect at least once to get the new settings, once they have when they disconnect the Management VPn will establish.
As soon as the user tunnel comes up, the Management VPN tunnel will drop.
Related Articles, References, Credits, or External Links
This is pretty much part two of the last article I wrote, so make sure you have the vCenter CA setup as a Sub CA of your Microsoft Certificate Services Deployment. See the following article;
Now we take the next step, and replace the certificates on the ESXi hosts.
Solution
Note: Joining the ESXi Hosts to the domain is not essential, it just makes things a little smoother. Ensure the host is set with the correct hostname and DNS settings.
Join the host to your domain.
vCenter 6.5
vCenter 6.0
Supply the domain name and suitable credentials.
Set the domain members to trust the vCenter CA Certificate. Back in part one we issued a SUB CA cert to the vCenter. Now I’m going to get a copy of this certificate, and get all my domain members to trust it, (and by definition all the certificates it issues). Browse to the vCenter https address > And open the certificate properties (click the padlock) > Certificate path > CA > View Certificate > Install Certificate.
Local machine.
I’m going to put it in Intermediate Certificate Authorities.
Then open an MMC console, and add in the certificate snap-in for Local Computer > Intermediate Certification Authorities > Certificates > Locate the ‘CA’ Certificate.
Export the certificate.
DER encoded is fine.
Save it on the root off the C: drive with a sensible name.
Open an administrative command window, and issue the following commands;
Now you will see the domain members start to get the CA certificate, (either in Intermediate or Root, depending on the command you issued above).
Meanwhile back in vCenter Web Client > Right click each host > Certificates > Refresh CA Certificates > Then Refresh Certificate.
WARNING: You may see the error below; if you do, it’s a bug don’t panic, there is a fix published on VMware Support. But if you wait 24 hours and attempt to renew the certificates it will work without an error.
A general system error occurred: Unable to get signed certificate for host: esx-host.your-domain.pri. Error: Start Time Error (70034).
You should see something like this;
If you browse to each ESXi host on https it should connect without errors or warnings.
Related Articles, References, Credits, or External Links
I’ve been doing a lot of PKI work over the last few days, testing device enrollment and NDES etc, and came across this problem being logged on my issuing/subordinate CA server;
Log Name: Application
Source: Microsoft-Windows-CertificationAuthority
Event ID: 53
Task Category: None
Level: Warning
Keywords:
User: SYSTEM
Description:
Active Directory Certificate Services denied request 35 because The public key does not meet the minimum size required by the specified certificate template. 0x80094811 (-2146875375 CERTSRV_E_KEY_LENGTH). The request was for SERIALNUMBER=4279256517 + OID.1.2.840.113549.1.9.2="sprugal.testbench.local ". Additional information: Denied by Policy Module Resubmitted by TESTBENCHAdministrator
Solution
In addition on the server itself in the Certification Authority Management console, under failed requests, it was showing the same error;
By default the certificate that NDES / MSCEP used as a template for your network devices is called ‘IPSec (Offline request)’ I’ve cloned that and made my own called NDESTemplate, but if you take a look on the Cryptography tab you can see that the minimum key size is set to 1024.
The network devices that are attempting to enroll with my server must have a key-length that is shorter, how can you tell? Well my devices are all Cisco ones (Routers and Firewalls). The Cisco ASA will tell you what key length is uses, but there is no command in router IOS to let me know. However if you use Putty and open an SSH session to the device it will tell you.
In the example below, the key length on this device is 2048 so that should be fine;
But this one is only 768 bits long! This device would generate the sort of errors I’m seeing on my Windows server.
So how do you fix the problem on the device, if you have not got your trustpoint setup then simply issue the following commands;
[box]
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#crypto key zeroize rsa
% All RSA keys will be removed.
% All router certs issued using these keys will also be removed.
Do you really want to remove these keys? [yes/no]: yes
R1(config)#
*Jul 11 14:26:50.619: %SSH-5-DISABLED: SSH 1.99 has been disabled
R1(config)#
[/box]
If you have setup a trustpoint, simply remove the trustpoint and it removes all the keys
[box]
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#no crypto pki trustpoint PNL-TRUSTPOINTNOTE YOUR TRUSTPOINT WILL HAVE A DIFFERENT NAME!!
% Removing an enrolled trustpoint will destroy all certificates
received from the related Certificate Authority.
Are you sure you want to do this? [yes/no]: yes
% Be sure to ask the CA administrator to revoke your certificates.
No enrollment sessions are currently active.
R1(config)#
[/box]
Related Articles, References, Credits, or External Links
ESXi comes with a self signed certificate, and for most people thats fine, but some clients want to have a ‘Trusted’ certificate on theirs, and have their own PKI infrastructure for issuing them.
Below I will generate a new certificate for my ESXi server using the Active Directory Certificate Services role on Windows Server 2012. Then replace the self signed certificate with my new one.
Solution
Generating a Certificate Request From the ESXi Server
1. Before we start there are a couple of hoops to jump through, and a Windows machine (it does not mater which one), install the following tow pieces of software;
Microsoft Visual C++ 2008 Redistributable Package (x86) and Shining Light Productions installer for OpenSSL x86 version 0.98r (or later)
Accept all the defaults and it should install to C:OpenSSL-Win32 go there, and in the bin directory make a backup of the openssl.cfg file.
2. Open the original openssl.cfg file and delete everything out of it, then paste in the following text, replace the values in red with your own, and save the file.
You will notice rui.csr has been created in the bin directory this is the file you need to request your certificate, if you open the file with Notepad you can copy the text.
Submit the Certificate Request and Get an ESX Certificate From a Windows CA
4. Open the web console of your certificate services server (it needs to be running the Certification Authority Web Enrollment role). The URL is usually http://{servers IP or Name}/Certsrv. Select ‘Request a certificate’.
5. Advanced certificate request.
6. Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
7. Paste in the text from your csr file (with no extra spaces!). Set the Certificate Template to ‘Web Server’ (the default lifetime for the Web Server template is 2 years. If you require longer, I suggest you clone the Web Server Template, change the lifetime and republish it in Active Directory Certificate Services).
8. Base 64 encoded> Download certificate.
9. Save the file as rui.cer and put it in the bin directory.
10. ESX needs the certificate to be in x509 format, so open a command window and execute the following commands;
[box]
cd C:OpenSSL-Win32bin
openssl x509 -in rui.cer -out rui.crt
12. Connect to the ESX host via SSH, and make a backup of the current keys (just in case).
[box]
cd /etc/vmware/ssl
mv rui.crt backup.rui.crt
mv rui.key backup.rui.key
[/box]
13. Using WinSCP copy the rui.crt and the rui.key files from the bin directory, to the /etc/vmware/ssl directory on your ESX host. WARNING: Set the copy type to ‘Text’ or ASCII or you may get some strange results.
14. Then either restart the management agents, or from your SSH session execute the following command;
[box]/sbin/services.sh restart[/box]
15. The simplest way to check is browse to the FQDN or your ESX host (the same name you used as the common name in step 2), and take a look at the certificate.
Related Articles, References, Credits, or External Links
I was trying to enroll some ASA firewalls to NDES to get some certificates. Each time the process failed with the following error.
[box]
% Error in receiving Certificate Authority certificate: status = FAIL, cert length = 0[/box]
That’s a pretty generic error, and does not give me a lot to go on. So I thought I would try from another network device, (a Cisco Catalyst switch). It’s a little easier to ‘debug’ the process in IOS rather than on the ASA, so that’s what I did.
[box]
Enable NDES Debugging
Petes-Router# debug crypto pki messages
Crypto PKI Msg debugging is on
Petes-Router# debug crypto pki transactions
Crypto PKI Trans debugging is on
Petes-Router#
[/box]
The switch failed with the same error as the firewall but at least now I had some debugging information.
[box]
Petes-Router# show logg
Jan 4 10:31:11.818: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/21,
changed state to up
Jan 4 10:32:40.648: CRYPTO_PKI: pki request queued properly
Jan 4 10:32:40.648: CRYPTO_PKI: Sending CA Certificate Request:
GET /CertSrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACert&message=PNL-Trustpoint HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Cisco PKI)
Host: 192.168.1.100
Jan 4 10:32:40.648: CRYPTO_PKI: locked trustpoint PNL-Trustpoint, refcount is 1
Jan 4 10:32:40.656: CRYPTO_PKI: http connection opened
Jan 4 10:32:40.656: CRYPTO_PKI: Sending HTTP message
Jan 4 10:32:40.656: CRYPTO_PKI: Reply HTTP header:
HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Cisco PKI)
Host: 192.168.1.100
Jan 4 10:32:40.656: CRYPTO_PKI: unlocked trustpoint PNL-Trustpoint, refcount is 0
Jan 4 10:32:40.656: CRYPTO_PKI: locked trustpoint PNL-Trustpoint, refcount is 1
Jan 4 10:32:40.673: CRYPTO_PKI: unlocked trustpoint PNL-Trustpoint, refcount is 0
Jan 4 10:32:40.673: CRYPTO_PKI: Reply HTTP header:
HTTP/1.1 200 OK
Content-Length: 7946
Content-Type: application/x-x509-ca-ra-cert
Server: Microsoft-IIS/8.5
Date: Wed, 07 Jan 2015 10:30:36 GMT
Connection: close
Content-Type indicates we have received CA and RA certificates.
Jan 4 10:32:40.673: CRYPTO_PKI:crypto_process_ca_ra_cert(trustpoint=PNL-Trustpoint)
Jan 4 10:32:40.673: CRYPTO_PKI: status = 0x722(E_SIGNATURE_ALG_NOT_SUPPORTED :
signature algorithm not supported):crypto_certc_pkcs7_extract_certs_and_crls failed
Jan 4 10:32:40.673: CRYPTO_PKI: status = 0x722(E_SIGNATURE_ALG_NOT_SUPPORTED :
signature algorithm not supported): crypto_pkcs7_extract_ca_cert returned
Jan 4 10:32:40.673: CRYPTO_PKI: Unable to read CA/RA certificates.
Jan 4 10:32:40.673: %PKI-3-GETCARACERT: Failed to receive RA/CA certificates.
Jan 4 10:32:40.673: CRYPTO_PKI: transaction GetCACert completed
Petes-Router#
[/box]
So we are getting the CA cert and the RA cert from the NDES server but we can’t read them.
Here’s the slightly less descriptive debug from the ASA firewall.
[box]
Petes-ASA(config)# debug crypto ca transactions
Petes-ASA(config)# crypto ca authenticate PNL-Trustpoint
ERROR: receiving Certificate Authority certificate: status = FAIL, cert length = 0
Petes-ASA(config)# show loggcrypto_certc_pkcs7_extract_certs_and_crls failed (1826):
crypto_certc_pkcs7_extract_certs_and_crls failed
CRYPTO_PKI:crypto_pkcs7_extract_ca_cert returned 1826
Petes-ASA(config)#
[/box]
Solution
I really struggled with this one, the bottom line is the Cisco device can’t read the certificates, and the reason it can’t is actually shown above;
E_SIGNATURE_ALG_NOT_SUPPORTED
What this is telling us is that the signature algorithm that Windows Certificate Services is using can not be understood by the Cisco network devices. At first I thought It might be because I was using Windows Server 2012 R2, and it might have some new security feature.
So I built a test Server in VMware Workstation, and presented an ASA and router to it from GNS3 and it worked first time, (annoyingly). When I looked at the certificates and compared them, and took into account the debug above, I spotted the difference.
If the signature algorithm is set to sha1RSA, it works if it’s set to RSASSA-PSS it fails. To compound my problem even further I have a three tier PKI deployment with an offline root, intermediate (Sub CA), and an issuing CA (Sub CA). And the signature algorithm needs to be correct for EVERY CERTFICIATE IN THE CERTIFICATE PATH (CHAIN).
Why Has This Happened?
Basically when the offline root was created, I followed the instructions for deploying an offline CA as per the instructions on Technet. Before you even install the role, Microsoft recommend you create a CApolicy.inf file with the following line in it;
[box]AlternateSignatureAlgorithm=1[/box]
I says that this signature algorithm is more secure, but it’s not compatible with Windows XP. What IT DOES NOT SAY, is it’s incompatible with Cisco devices wanting to get certificates from NDES!
Note: Executing the following command also enables this;
From this point forward, all new certificates issued by this CA will use the older signature algorithm. So if you renew the CA Certificate the new one will be fine.
WARNING: When renewing the CA Cert MAKE SURE YOU DO NOT generate new keys (or previously issued certificates may stop working!)
If you only have one certificate server you can then simply remove NDES.
When NDES is reinstalled the new RA certs will use the correct signature algorithm.
What If You Have a Two or Three Tier PKI Deployment
If like me you have a multi tiered PKI deployment, you need to go all the way back to the Root CA > Fix that > Reissue all the Sub CA certs down the certificate path fixing each tier as you go.
Here’s the process I used, (Use at you own risk and I accept no responsibility if you trash your PKI environment).
Related Articles, References, Credits, or External Links
SSTP gives you the ability to connect to your corporate network from any location that has an internet connection, and is not filtering https. This port is usually open for normal secure web traffic. Traditional VPN connections require ports and protocols to be open for them to work, which makes a solution that runs over TCP port 443 attractive.
Thoughts: While I can see why this is a good idea, Microsoft has basically changed some existing protocols so they work on a port that wont be blocked by most firewalls. This is not a new approach, (Microsoft did it before with RPC over HTTP). I can’t help feeling that the more traffic we push over ports 80 and 443, sooner or later security/firewall vendors are going to statefully inspect/block traffic that isn’t supposed to be on that port. (If you think ‘that would never happen!’ Try running an Exchange Server through a Cisco firewall with SMTP inspection turned on). Anyway, it’s there, I’ve been asked to do a walkthrough, so read on,
Solution
I’ve got a Windows 2012 Server already setup, it’s a domain controller, and is running DNS. You don’t have to have the same server running SSTP/RRAS but in this lab environment that’s what I’m doing. In addition my remote VPN clients will get an IP address from my normal corporate LAN.
1. On the server I have two network cards installed, the first (NIC1) is the normal network connection for the server, the second (NIC2) will be the one that the remote clients get connected to (once they have authenticated to NIC1).
2. Make sure the Internet facing NIC has good comms, and works OK.
3. NIC2 as you can see, does not even need a default gateway.
Windows Server 2012 Add Certificate Services
I’m going to use a ‘self signed’ certificate, if you have purchased one, then skip this section.
4. From Server Manager (ServerManager.exe) > Add Roles and Features > Next > Next > Next > Select > Active Directory Certificate Services.
5. Add Features > Next > Next > Next > Tick ‘Certificate Authority Web Enrolment’.
6. Add Features > Next > Next > Next > Install > Close > From the warning (top right) > Configure Active Directory Certificate Services on this server.
7. Next.
8. Select both Certificate Authority and Certificate Authority Web Enrolment > Next.
9. Next > Next > Next > Next > Next > Next > Next > Configure > Close > Close Server Manager.
10. Open a Microsoft Management Console.
11. File > Add Remove Snap-in > Certificate Authority > Add > Local computer > Finish > OK.
12. Drill down to Certificate Templates > Manage.
13. From the list that appears locate IPsec > Right Click > Duplicate Template.</p:
14. General tab > Change the name to SSTP-VPN.
15. Request Handling tab > Tick ‘Allow private key to be exported’.
16. Subject Name tab > Tick ‘Supply the request’ > Click OK when prompted.
18. Add > Locate the ‘Server Authentication’ policy > OK > OK > Apply > OK > Close the Certificate Template console.
19. From the Certificate templates Folder > New > Certificate Template Issue.
20. Locate the SSTP-VPN entry > OK > Close the MMC.
SSTP Firewall Setup
In this example my server is behind a corporate firewall. If yours is internet facing then you may simply want to add an exception/rules for allowing https/TCP443. My server will ultimately have a public IP address that resolves to its public name (vpn.pnl.com) so I just need to allow the ports in. If your server does not have its own public IP address, then you may need to setup port forwarding instead. You will see later I’m also going to use TCP 80 (normal HTTP) to access my certificate services remotely, so I’ve got that open as well. You may want to access certificate services via HTTPS instead in a corporate environment.
21. On this server I’m simply going to disable the firewall > Start > Run > firewall.cpl {enter} > Turn Windows Firewall on or off > Set as appropriate.
Grant users SSTP VPN/Dial-in rights.
22. Make sure that any user who wants to access the SSTPVPN has had their Dial-in set to ‘allow access’.
Windows 2012 Server Install and Configure RRAS for SSTP
23. From Server Manager (ServerManager.exe) > Add Roles and Features > Next > Next > Next > Select > Network Policy and Access Services.
24. Add Features > Next > Next> Next > Next > Install > Close.
25. Back at Server Manager (ServerManager.exe) > Add Roles and Features > Next > Next > Next > Select ‘Remote Access’.
26. Add Features > Next > Next > Next > Tick ‘Routing’ > Next > Install.
27. Close.
Note: At this point you may see the warning that there are additional steps to take, (to configure routing an remote access), if so you can launch and then close this wizard because we will do it manually.
28. Close Server Manager > Open a new MMC > File > Add/Remove Snap-in > Certificates > Add > Computer account > Finish > OK.
29. Expand Personal > Certificates > All Tasks > Request New Certificate.
30. Locate the SSTP-VPN entry > Click the ‘More information required..’ link.
31. Change the Type to common name > Enter the public name of the SSTPVPN server > Add > OK.
Note: This will be the common name on the certificate, i.e. vpn.pnl.com, which will need a public A/Host record creating for it in your public DNS, (speak to your ISP or DNS hosting company). That way when your remote clients go to https://vpn.pnl.com they wont get an error, (providing you imported the root cert correctly on THAT machine).
35. Right click the server > Configure and Enable Routing and Remote Access.
36. At the Wizard > Next > Next > Tick VPN > Next.
37. Select NIC1, In this case I’m unticking the ‘Enable security’ option, (or is disables RDP and locks the NIC down) > Next.
38. I’m going to use this server so select the bottom option > Next.
39. New > Create a range of IP addresses. (Note: You may need to exclude these from your existing DHCP scope) > OK > Next.
40. Next.
41. Finish > OK > OK > At this point you will see the services restarting.
42. Right click the server > Properties.
43. Security tab > Change the certificate to the one we created > Apply > Yes > OK > Close the console.
Windows Server 2012 – Connect to SSTP from a Remote Client
At this point I have the correct ports open on the firewall, and I’m on a Windows 7 client outside the corporate network.
44. Because we are using a self signed certificate, we need to get the client to trust it. We can give the user the root certificate, or they can connect and download it, here I’m connecting to the Certificate Services web portal. Note: Remember that’s on the same server.
45. Supply your domain credentials > OK > Download a CA Certificate > Download CA Certificate > Save As.
46. Put the certificate somewhere, and call it something sensible.
47. Now launch an MMC on the client machine, and add the certificate snap-in (for ‘computer account’).
48. Drill down to Trusted Root Certification authorities > Certificates > All Tasks > Import > Navigate to, and select the certificate you just downloaded.
Note: If you double click the cert and import it manually, then it gets put into the user accountNOT the computer account, and this will cause you problems. (Error 0x800b0109).
Registry Key Required for SSTP Access
The title is not really true, but as we are using a self signed certificate the client cannot check the CRL for the CA. Even with some purchased certificates you may need to to do this.
49. Open the registry editor and navigate to:
[box]
HKLM > SYSTEM > Current > CurrentControlSet > services > SstpSvc > Parameters
[/box]
50. Create a new 32 bit DWORD called NoCertRevocationCheck and set its value to 1 (one).
Setup a SSTP VPN Connection
51. Open the Network and sharing Center.
52. Setup a new connection or network.
53. Connect to a workplace.
54. Use my Internet Connection.
55. Supply the Internet Address (that matches the common name you used above) > Next.
56. Supply your domain credentials > Connect.
57. Connected successfully.
Note: If it fails at this point, it usually gives you an error code you can Google, or it gives you the option of logging for you to troubleshoot.
58. Just to prove I’m connected, this client can ping the SSTP servers private address.
Related Articles, References, Credits, or External Links
