I first saw this problem a few years ago trying to get some Windows clients to auto enrol with server 2008, then this week my colleagues could not get new 2019 Domain Controller to enrol for a Kerberos certificate, and the this was caused by the same problem.
Symtoms (RPC Error)
1. Test to make sure the client can see the CA, and is able to communicate with it, issue the following command;
[box]
certutil -pulse
[/box]
As you can see above, the first time I ran the command I got the following error;
I then ran the command window ‘as administrator’ and it completed, this was the first inkling I had, that permissions were probably not right.
2. Run mmc on an affected machine, and add in the certificates (local computer*) snap-in. right click the ‘personal container’ > attempt to get the certificate you have published manually.
Problem seen on a Domain Controller (Attempting to get a Kerberos Certificate).
An error occurred while enrolling for a certificate. The Certificate request could not be submitted to the certification authority
Url: {CA Server Path}
Error: the RPC server is unavailable. 0x80076ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE)
Problem seen on Windows Client (attempting to enrol for a Computer Certificate).
*Or local user if you are auto enrolling user certificates.
At that point I on the Windows cliebntgot this error;
Active Directory Enrollment Policy
STATUS: Failed
The RPC server is unavailable.
Resolution (Windows Certificate RPC Error)
The most common cause for that error, is the membership of the ‘Certificate Service DCOM Access’ group is incorrect, check yours and make sure it matches the one below.
On the CA Server launch the Certification Authority management tool and look at the properties of the CA Server itself, on the security tab make sure yours looks like this, (Domain computer and domain controllers should have the ‘request certificates‘ rights).
Still on the CA Server, check the permissions on the C:Windows\System 32\certsrv directory, authenticated users should have Read & Execute rights.
This is the change that finally fixed mine: In active directory users and computers, locate the Builtin container, within it there is a group called ‘Users’. Make sure it contains Authenticated Users and INTERACTIVE.
Run a ‘gpupdate /force’ on your test client, and/or reboot it.
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
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
One of the often overlooked tasks of a PKI deployment is setting your Certificate Services CRL. For smaller deployments, with only one server then you don’t have to worry about how this will be designed (though a CRL does not have to be hosted on a Certificate Services server). In my test environment I only have one PKI server so everything will be going on that one box, In more complex environments you may have multiple root and subordinate PKI servers writing to your CRL (you may even have multiple CRL’s).
Solution
I would consider this a ‘post’ certificate services install task, so I’m assuming you already have that installed and configured.
1. Launch the Certification Authority management console > Right click the server-name > Properties > Extensions tab.
2. With CRL selected > Add > Type into the location http://crl.{your-domain-name}.{your-domain-extension}/crld
Note: You can use https:// but you may need to add a certificate in IIS manager and select ‘require TLS’ for the crld virtual directory.
3. In the variable section, select then ‘Insert’ the following onto the end of the URL;
Note: Is ‘should’ look like http://{FQDN-Of-Server}/crld/<CAName><CRLNameSuffix><DeltaCRLAllowed>.crl
4. With the CRL entry you have just created selected > Enable the following two options;
Include in CRL’s. Clients use this to find Delta CRL locations.
Include in the CDP extension of issues certificates.
Apply > OK > Yes.
5. Change the ‘Select extension’ drop down to ‘CRL Distribution Point (CDP)’ > Add > Type in a UNC path as follows ‘{Server-name}crldist$ > Then select and inset the variables onto the end of the path, (like you did above);
<CaName>
<CRLNameSuffix>
<DeltaCRLAllowed>
And then (as above) add .crl onto the end of the path > OK.
6. With the CDP selected > Select the following options;
Publish CRL’s to this location
Publish Delta CRL’s to this location
Apply > OK > Yes.
Windows DNS Requirements for CRL
7. So that your clients can resolve the name of the CRL you have just created, they need to be able to resolve the name you just created. On your DNS server open the DNS management console > Expand server-name > Forward Lookup Zones > {your-domain-name} > Right click > New Host (A or AAAA) > name crl > IP address = The IP address of the IIS server that will host the CRL > Add Host > Close DNS Manager.
Windows IIS Requirements for CRL
8. On the web server, open the Internet Information Services (IIS) Manager console > Expand and select your server-name > right click > Add Virtual Directory >Set the alias to CRLD.
9. Under ‘Physical path’ select the browse button > Select the C: Drive, (or another drive if you wish) > Make New Folder > Call the folder CRLDist > OK > OK.
10. Select server-name > Directory Browsing
Note: If you are serving other services from this web server, you might wish to only set directory browsing on the CRLD virtual directory.
11. Enable.
12. Select the CRLD directory (Click refresh if you cant see it) > Configuration Editor.
13. Navigate to System.webServer > security > RequestFiltering.
Note: On older versions of IIS, it’s under ‘System.webServer > security > authentication > RequestFiltering.’
14. Change allowDoubleEscaping to ‘True’ > Apply.
Windows Folder Permission Requirements for CRL
15. Navigate to the folder you just created (i.e C:CRLDist) > Right Click > Properties > Sharing > Advanced Sharing > Select ‘Share this folder’ > Add a dollar symbol to the end of its name i.e. CRLDist$.
Note: This simply creates a ‘hidden’ share, that cannot be seen when browsing the server shares.
Note: In Addition, Set the Windows NTFS Permissions for the Server(s) to Full Control also.
16. Permissions > Object Types > Add in Computers > OK > Enter the name of the server(s) that need to write to the CRL > OK.
17. Grant the Full Control permission to the sever(s) you just added > Apply > OK.
18. Back at the Certificate Services server > Launch the Certification Authority management console > Revoked Certificates > Right click > All Tasks > Publish > New CRL > OK.
19. If you check the folder you created earlier, you will see it now contains the CRL files.
Related Articles, References, Credits, or External Links
SHA CERTIFICATE WARNING: Note This article was written some time ago, ensure your CA environment does NOT use SHA1 for your certificates, if it does, Please visit the following link for migration instructions;
I need to setup wireless authentication based on computer certificates, I’ve done similar jobs before by manually issuing certificates for Cisco AnyConnect, but this will be for NAP/RADIUS authentication to MSM. I’ll be working with Server 2008 R2 and Windows 7 clients. So task one was getting my head round ‘auto enrollment’. As stated I’m deploying Computer certificates but the process is practically the same for issuing User certificates (I’ll point out the differences where applicable).
Solution
Prerequisites: A Windows domain environment, with working DNS.
Setup a Certification Authority
1. Launch Server Manager (Servermanager.msc) Roles > Add Roles > Active Directory Certificate Services > Next > I’m going to accept all the defaults.
2. The only thing I’m going to change is the lifetime, I usually change that from 5 to 10 years (force of habit, after 5 years it will probably still be my problem, in 10 years it will be replaced, or in a skip!)
Create a Computer Certificate Template and Issue it.
4. Locate and make a copy of the Workstation Authentication template. If you were using User certificates the you would copy the User template.
Note: I got an email a few months ago form someone who had an argument about whether to make copies or edit the originals, and was asking what I thought was best practice. Well I would ALWAYS copy a template and edit that copy. Then if you ‘stuff it up’ you still have the original. It’s always best practice to avoid looking like a cretin!
5. If you still have Server 2003 servers choose the default, if not pick 2008 > OK.
6. General Tab > Give the template a sensible name.
7. Subject Name Tab: Tick User principle name (UPN).
8. Security Tab: Ensure Domain Computers have the rights to Read and Autoenroll > OK > Close the template console.
9. Certificate templates > New > Certificate Template to Issue.
10. Pick the one you just created > OK.
11. Make sure it’s listed > Close the Certificate Authority management console.
Deploy Auto-enrolled Certificates via Group Policy
Note: You could just add this to the to the default domain group policy, and all computers would get a certificate, but for this exercise I’ve created an OU, and I’m going to create a new policy and link it there.
12. Select an OU or container that contains the computer objects you want to send certificates to.
Note: Obviously if you are sending out User certificates then link it to a user OU, (you would be surprised!)
13. Navigate to;
[box]
Computer Certificate Auto-Enrollment
Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment
User Certificate Auto-Enrollment
User Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrolment
[/box]
WARNING: If deploying user certificates read this article.
14. Enable the policy > Select the two options available > Apply > OK > Close the GPO management editor.
Test Windows Certificate Auto-Enrollment
15. Before we do anything else, you can see there are no certificates on the Windows 7 client machine, and there are no certificates ‘issued’ from the server.
Note: To see a computers certificates, you need to be logged in with administrative rights, run mmc and add in the certificates snap-in for ‘local computer’.
16. Now if I move this machine into the OU that I’ve linked the GPO to.
17. And then force that client to refresh its group policies, (or reboot it).
18. Now when you check, you can see it has received a certificate, and the server is now showing one certificate issued.
Now I’ve got to work out NAP and RADIUS and force them to use the certificates, but I’ve got a headache and I need a brew, watch this space….
Related Articles, References, Credits, or External Links
