Self-Signed SSL, Secure RDPs, and Publishing CRLs

Homelab, Technology

Overview

This is my first blog post, so I’ll just keep this short. This is in regards to a home lab that I’m setting up just for fun. My goals:

  1. Create a self-signed SSL certificate and bind it to the website of my public webserver for valid SSL connections
  2. Have valid, secure RDPs using the SSL certificate

First, a bit about my homelab. My homelab is basically just a desktop PC hosting a Windows Server 2008 R2 Hypervisor, with 4 VMs. The host OS has the IIS and AD DC roles installed and running. I also have personal Windows 7, 2008R2 CA, 2008R2 MDM , and 2008R2 SQL DB VMs. The entire environment is behind a router which is able to forward traffic to the IPs that I set up.

The first thing I had to was make my host IIS website available to the public internet. I don’t have any real reason to choose my host over any other VM at this point, but if I decide to switch later on it won’t be too difficult. The forwarding is fairly simple. I routed all 80/443 traffic to my DC’s IIS page. I created some DNS A records so that certain URLs would direct traffic to my router, which would then forward that traffic to my DC. This all worked within 5 minutes. For RDP, I routed all 3389 traffic to my DC.

I realize that I’m doing a lot of things that regularly should not be done with a DC (internet facing web server, internet facing rdp, etc), but the fact of the matter is that this is a homelab made for learning. It will be much, much easier to keep the number of servers I have to rdp into to a minimum. On top of that, I try to keep my homelab turned “off” at all times because of the electricity costs. Ideally my DC would be internal only, with a separate VM just for internet-facing services, but that would mean that I would have to turn on multiple machines every time I wanted to work on my homelab (or work on some extra set up, which I might actually do later down the line). Currently I have a really neat set up where I can turn on/off my host box using my iPhone, and then RDP using the Microsoft Remote Desktop app. Setting up my homelab in this technically insecure way makes my life way easier because I can then mange all my other VMs from one initial RDP point, the host VM. Plus, it’s not like hackers will fine any valuable data in this box.

Create a self-signed SSL certificate and bind it to the website of my public website

I noticed that I didn’t have to create a new self-signed SSL certificate. My DC server (which I am now able to remote into) already had an identity certificate signed by my CA. This might have been created when I set up my CA a while back. Anyways, I binded that certificate to my DC’s https traffic and voila, my webserver websites are now SSL secure! As long as the device being used has my root CA certificate installed, of course.

Have valid, secure RDPs using the SSL certificate

You can still be unable to have valid, secure RDPs, even with a valid SSL certificate already binded to IIS and available in the certificate store. RDP has multiple forms of validation; you have to go into the Remote Desktop Session Host Configuration and make sure that the certificate being used for RDP connections is the same as your SSL certificate (do not choose automatically generated). Security type does not have to actually be set to SSL, because if there is no other form of security available it will default to SSL. More information: https://technet.microsoft.com/en-us/magazine/ff458357.aspx.

Now that the RDP connection is secure with the SSL certificate, you will need to make sure that your CRLs are available for verification. Based on the device configuration, CRLs are checked whenever a remote connection is being secured. I decided to publish my CRLs to the internet so that it would be easy for any client to access them. I created a shared folder on my DCs IIS folder and made sure that my CA had full read/write access to it. I basically just followed the steps here: http://social.technet.microsoft.com/wiki/contents/articles/485.how-to-publish-the-crl-on-a-separate-web-server.aspx. Important note: when publishing CRLs to separate web servers, it’s extremely important to type in the file address exactly like how Microsoft wants it. Even if the location is valid, if it is not typed in the correct format, you will get errors (app log ErrorID 66 and ErrorID 65). Here are the steps in case Microsoft takes down that KB:

 

To configure a separate Web server to publish the CRL

  1. On the Web server, load Internet Information Services (IIS) Manager
  2. Create a new virtual directory (or new Web site) with the following information:
    • Give it a name (alias) such as crl.
    • Select the local folder that will contain the CRL files – for example, C:\CRL.
    • Specify the directory access permissions of Read.

 

To manually publish the CRL on a separate server (I didn’t use this method)

  1. On the CA server, load Certification Authority, expand your CA, right-click Revoked Certificates, click All Tasks, and then click Publish.
  2. On the Publish CRL popup dialog box, ensure that New CRL is selected, and then click OK.
  3. Using Explorer, locate the folder that contains the CRL files. By default, these files are in %windir%\system32\certsrv\enroll but this location can be changed on the Extensions tab of the CA properties.
  4. Copy all the files with a .crl extension to removable media.
  5. On the Web server computer, create a new local folder to contain the CRL (for example, C:\CRL).
  6. Paste the files with the .crl extensions into this folder.

 

To automatically publish the CRL on a separate server

  1. Ensure that a trust relationship exists such that the Web Server trusts the CA Server.
  2. On the Web server computer, create a new local folder to contain the CRL files (for example, C:\CRL).
  3. Configure the folder with the following:
    • Share the folder, for example, with the share name of CRL.
    • Specify the share permissions of Read and Change to the CA server computer account.
    • Specify NTFS permissions of Read and Write to the CA server computer account.
  1. On the CA server, load Certification Authority, right-click your CA, select Properties, and then click theExtensions tab.
  2. Ensure that CRL Distribution Point (CDP) is selected, and then click Add.
  3. In the Add Location dialog box, type the following and then click OK: file://\\<servername>\<share>\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl  For example, if your Web server was called server2 and the folder share name you created for the CRL was called CRL, you would type file://\\server2\CRL\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
  4. Ensure that only the following options are selected for this new entry:
    • Publish CRLs to this location
    • Publish Delta CRLs to this location
  1. If you are prompted to restart Active Directory Certificate Services, click Yes.
  2. After the computer has restarted, load Certification Authority, expand your CA, right-click Revoked Certificates, click All Tasks, and then click Publish.
  3. On the Publish CRL popup dialog box, ensure that New CRL is selected, and then click OK.  If you do not see an error, check the folder on the Web server and confirm that it now contains one or more files with .crl extensions.  If you do see an error, it is likely that there is a syntax error or permissions error that must be corrected before the CRL can be published to the separate Web server.

 

To specify the separate Web server as a CDP

  1. On the CA server, load Certification Authority, right-click your CA, select Properties, and then click the Extensions tab.
  2. Ensure that CRL Distribution Point (CDP) is selected, and then click Add.
  3. In the Add Location dialog box, type the following and then click OK: http://<FQDN_of_Web_Server/<CRL_directory_name>/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
    • For example, if your Web server was called server2.contoso.com and the virtual directory you created in IIS was called CRL, you would type http:// server2.contoso.com/crl/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
  4. Ensure that the following options are selected for this new entry:
    • Include in CRLs. Clients use this to find Delta CRL locations.
    • Include in the CDP extension of issued certificates
  1. Click OK.  If you are prompted to restart Active Directory Certificate Services, click Yes.

 

To confirm CRL access

  1. From a computer on the same network as the separate Web server, load a browser and type in the same CRL path that you specified in step 3 for the procedure “To specify the CRL on a separate Web server”.
    • For example, if your Web server was called server2.contoso.com and the virtual directory you created in IIS was called crl, and your CA name was Contoso Root CA, you would type http:// server2.contoso.com/crl/contoso root ca.crl for the base CRL, and type http:// server2.contoso.com/crl/contoso root ca+.crl for the delta CRL.
  2. You should see a File Download dialog box, asking you whether you want to open or save this file.  Click Open.
  3. You should now see the Certificate Revocation List with a General tab and Revocation List tab.  On the General tab, the value for Issuer will be your CA server. On the Revocation List you will see any certificates that have been revoked by the CA.
    Click OK.

 

To confirm new certificates contain new CDP

  1. Request and issue a new certificate after you have completed the procedure “To specify the CRL on a separate Web server”.
  2. On the requesting computer, load the Certificates MMC and locate the newly installed certificate.
  3. Double-click the certificate to view its properties.
  4. Click the Details tab and click the field CRL Distribution Points.
  5. View the values in this field.  There will be multiple CRL distribution points listed so scroll down until you see the HTTP CRL distribution point that you added (for example:  URL=http://server2.contoso.com/crl/Contoso%20Root%20CA.crl )

http://social.technet.microsoft.com/wiki/contents/articles/485.how-to-publish-the-crl-on-a-separate-web-server.aspx

On top of the steps above, I made sure to make the root certificate available at a public location for AIA publication. Make sure that whenever you make any crl changes, you go to your CA and re-publish the CRLs. Make sure to open up certutil and verify that the crl and aia checks are able to complete without an issue. Here’s a helpful post: https://social.technet.microsoft.com/Forums/windowsserver/en-US/583d0135-ba71-4e30-bf25-87a3ce147c2f/rdp-ssl-failed-a-revocation-check-could-not-be-performed-on-this-certificate?forum=winserversecurity.

 

I made my delta crls available by allowing double spacing:

  1. On the Web server, open Server Manager.
  2. Double-click Roles, double-click Web Server (IIS), and then click IIS Manager.
  3. In the console tree, click the virtual directory that hosts the CRL.
  4. In the features view, double-click Request Filtering.
  5. In the actions view, click Edit Feature Settings.
  6. Select the Allow Double Escaping check box.

Source: https://technet.microsoft.com/en-us/library/dd379478(v=ws.10).aspx.

 

Verification

I ran certutil -url and found that my non-domain machine was definitely verifying the crl (and AIA) with no issue (Status Verified):

crl.verification.1crl.verification.2

I ran certutil -verify -urlfetch mydccertificate.cer and got these logs:

C:\Users\hb90797>certutil -verify -urlfetch C:\Users\hb90797\Desktop\junservmast
er.server.certificate.cer
Issuer:
CN=junservca
DC=corp
DC=junsungwong
DC=com
Subject:
CN=junservmaster.corp.junsungwong.com

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: 32 Minutes, 12 Seconds

SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwRevocationFreshnessTime: 32 Minutes, 12 Seconds

CertContext[0][0]: dwInfoStatus=102 dwErrorStatus=0
Issuer: CN=junservca, DC=corp, DC=junsungwong, DC=com
NotBefore: 7/29/2015 5:11 PM
NotAfter: 7/28/2016 5:11 PM
Subject: CN=junservmaster.corp.junsungwong.com
29 6c 1c 81 64 2b, DNS Name=junservmaster.corp.junsungwong.com
Template: DomainController
Element.dwInfoStatus = CERT_TRUST_HAS_KEY_MATCH_ISSUER (0x2)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
—————- Certificate AIA —————-
Failed “AIA” Time: 0
Error retrieving URL: More data is available. 0x800700ea (WIN32/HTTP: 234)
ldap:///CN=junservca,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Config
uration,DC=corp,DC=junsungwong,DC=com?cACertificate?base?objectClass=certificati
onAuthority

Verified “Certificate (0)” Time: 0
[1.0] http://junservmaster.corp.junsungwong.com/ca/junservca.corp.junsungwon
g.com_junservca.crt

—————- Certificate CDP —————-
Failed “CDP” Time: 0
Error retrieving URL: More data is available. 0x800700ea (WIN32/HTTP: 234)
ldap:///CN=junservca,CN=junservca,CN=CDP,CN=Public%20Key%20Services,CN=Servi
ces,CN=Configuration,DC=corp,DC=junsungwong,DC=com?certificateRevocationList?bas
e?objectClass=cRLDistributionPoint

Verified “Base CRL (3c)” Time: 0
[1.0] http://junservmaster.corp.junsungwong.com/ca/junservca.crl

Failed “CDP” Time: 0
Error retrieving URL: More data is available. 0x800700ea (WIN32/HTTP: 234)
[1.0.0] ldap:///CN=junservca,CN=junservca,CN=CDP,CN=Public%20Key%20Services,
CN=Services,CN=Configuration,DC=corp,DC=junsungwong,DC=com?deltaRevocationList?b
ase?objectClass=cRLDistributionPoint

Verified “Delta CRL (3c)” Time: 0
[1.0.1] http://junservmaster.corp.junsungwong.com/ca/junservca+.crl

Verified “Delta CRL (3c)” Time: 0
[1.0.2] http://junservmaster.corp.junsungwong.com/ca/junservca+.crl

—————- Base CRL CDP —————-
Failed “CDP” Time: 0
Error retrieving URL: More data is available. 0x800700ea (WIN32/HTTP: 234)
ldap:///CN=junservca,CN=junservca,CN=CDP,CN=Public%20Key%20Services,CN=Servi
ces,CN=Configuration,DC=corp,DC=junsungwong,DC=com?deltaRevocationList?base?obje
ctClass=cRLDistributionPoint

OK “Delta CRL (3c)” Time: 0
[1.0] http://junservmaster.corp.junsungwong.com/ca/junservca+.crl

OK “Delta CRL (3c)” Time: 0
[2.0] http://junservmaster.corp.junsungwong.com/ca/junservca+.crl

—————- Certificate OCSP —————-
No URLs “None” Time: 0
——————————–
CRL 3c:
Issuer: CN=junservca, DC=corp, DC=junsungwong, DC=com
49 16 93 fa ec f0 a3 1d d6 9a a2 7f 75 c9 b6 8c 3e a4 86 3a
Delta CRL 3c:
Issuer: CN=junservca, DC=corp, DC=junsungwong, DC=com
96 09 be 52 15 68 a8 be 8c 58 e6 df 05 e0 df f6 6d 4f e1 26
Application[0] = 1.3.6.1.5.5.7.3.2 Client Authentication
Application[1] = 1.3.6.1.5.5.7.3.1 Server Authentication

CertContext[0][1]: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=junservca, DC=corp, DC=junsungwong, DC=com
NotBefore: 9/18/2014 3:07 PM
NotAfter: 9/18/2016 3:17 PM
Subject: CN=junservca, DC=corp, DC=junsungwong, DC=com
40 87 dc 7f 2a 62 b2 dd ce 7d 49 de 55 54 08 09 01 f1 ba 61
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:
Full chain:
————————————
Verified Issuance Policies: None
Verified Application Policies:
1.3.6.1.5.5.7.3.2 Client Authentication
1.3.6.1.5.5.7.3.1 Server Authentication
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.

Awesome!

FYI, as a temporary alternative, you can also just turn off revocation checks by editing the registry (https://social.technet.microsoft.com/Forums/windowsserver/en-US/4d1c9289-7689-45ec-9e20-4d53b227e8f3/rds-ssl-certificate-issue?forum=winserverTS):

  1. Create the DWORD Value : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors and set it to 1. (For CredSSP Single Sign On)
  2. Create either of the following DWORD values and set them to 0 (for pure TLS).
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Terminal Server Client\CertChainRevocationCheck
    • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Terminal Server Client\CertChainRevocationCheck
Tweet
Share
Share

Leave a Reply

Your email address will not be published. Required fields are marked *