Digital Certificates Explained

Digital Certificates Explained KB ID 0001846

Problem

From setting up PKI environments, to migrating them, and a myriad of errors and problems in between, we have a lot of content on PNL referring to digital certificates and PKI. I’ve dealt with these technologies a lot over the past 20+ years and I’m always surprised how frightened of digital certificates people are. So in the space of a few minutes I’ll try and give you a basic understanding of what PKI is, how that relates to Digital certificates, then finish off with a few certificate ‘Golden rules‘.

Solution : Digital Certificates Explained

You will see I use the terms PKI environment, and Certificate Services  and interchange those two things a lot, Certificate Services is the name of the Microsoft ‘Role” that provides Certificate Services. If you simply want to setup certificate services, then use the following link.

Microsoft PKI Planning and Deploying Certificate Services

Before you understand certificates, you need to have a basic understanding of Public Keys, and Private Keys, how this key pair is used, and what Asymmetric Cryptography is (bear with me the maths might be mind boggling, but the concept is simple).

Public Key

The public key is shared openly and is used to encrypt messages or data. It is associated with a user (or entity) and can be freely distributed to anyone. Its primary function is to ensure confidentiality by allowing others to encrypt messages that only the owner of the corresponding private key can decrypt.

Private Key

The private key is kept secret and is known only to the owner. It is used for decrypting messages or data that have been encrypted with the corresponding public key. The private key is crucial for ensuring the authenticity and integrity of the data because only the person with the private key can decrypt and access the information.

Digital Certificates Explained: How These Keys are Used for Encryption

Encryption

1. Sender obtains the recipient’s public key and uses the recipient’s public key to encrypt the message.
2. Encrypted message is sent to the recipient.

Decryption

3. The recipient, (who possesses the corresponding private key), can then decrypt the message.

The strength of the security lies in the complexity of the key pair. Asymmetric cryptography is based on mathematical principles, making it computationally infeasible for someone to calculate the private key even if they have the corresponding public key. This makes it a secure method for tasks such as secure communication, digital signatures, and online transactions.

Digital Certificates Explained: Use of Keys and Certificates

Public Key Infrastructure (PKI) is a framework that manages digital keys and certificates. it requires the following:

Key Pair Generation: The process begins with the generation of a key pair (the public and private keys) for a user or entity. As shown above the public key is shared openly, and the private key is kept secret.

Certificate Authority (CA):A Certificate Authority is a trusted third party (public) or you own (private) system for authenticating digital certificates. in a PKI system.
The user’s public key is combined with other information (such as identity details and time stamps,) and then signed by the CA to create a digital certificate.

Digital Certificates: A digital certificate is a data structure that binds a public key to an individual, device, or service. It includes the public key, and information about the entity, the digital signature of the CA, and other metadata. So the digital certificate serves as a way for others to verify the authenticity of the associated public key and ultimately the identity of the entity.

Certificate Lifecycle: Certificates have a defined lifecycle, including issuance, and expiration. Note: They can also be revoked before expiration for example if compromised, or if the associated private key is lost.

Usage in Secure Communication

When parties want to communicate securely, they exchange their digital certificates. So just like the example above, the sender encrypts data with the recipient’s public key, which they get from the certificate that the receiver has published publicly, ensuring only the recipient, with the corresponding private key, can decrypt it.
Note: Digital signatures, created using the sender’s private key, can also be attached to messages to ensure authenticity and integrity. The recipient can verify the signature using the sender’s public key.

Digital Certificates Explained: Golden Rules Of Certificates

You must trust the CA that issued (authorised) the Certificate.

Every certificate has a CA that issued/approved it you NEED TO TRUST that CA, there are several trusted Certification Authorities that are built into your computer, and these are updated regularly with normal updates. this is why if you self-sign a certificate or build your own CA – then you may need to manually get people to trust your CA before they will be trusted. Also Certificate Authorities are hierarchical (they can have parent CAs) these form a CHAIN, and you need to be able to see that chain and trust ALL the CAs in that chain, (all the way back to the Root CA).

 

Above on my (current) site certificate you can see it was issued by a CA called RapidSSL, and that CA was authorised by a Root CA called Digicert Global Root G2. This means my certificate was signed by an intermediate CA (sometimes called and Sub CA).

The Certificate needs to be In Date

Certificates a have a date they were issued and a date when they will expire, If you are not at a point in time between these two dates, then you will not trust the certificate. (Note: this can happen if the internal clock/date on YOUR machine is incorrect).

 

 

Note: A Certificate that is in date can also be revoked. This is done by the CA, which publishes a list of certificates that have been revoked, (that your computer can check.)

The Common Name (CN) and/or Subject Alternative Name (SAN)  needs to be correct.

In times gone by, the certificate CN had to be correct, but more modern browsers will require BOTH Common Name and Subject Alternative Name to be correct. these are fields in the certificate that hold the name of the entity for example mine is www.petenetlive.com (that is the Common Name) This is the address (or FQDN) that is typed into the browser window to get to the site that presents this certificate.

 

Note: That means if you are putting a certificate on ‘something‘ be that a website, or a device, the NAME needs to be both correct, and resolvable by the person (or entity) that you want to trust it, e.g. if the common name was www.petes-site.com and you needed to type in https://www.petenetlive.com to get there, it would not be trusted (even if both names resolved to the correct IP address!)

You need to trust the ‘Algorithm‘ that signed the certificate.

This is a more recent development, I mentioned above that there’s some very complicated maths going on, as time moves on the mathematics needs to get more complicated, as computers get more powerful to maintain security. So older methods of signing have been depreciated, if a certificate is using technology that’s been depreciated it will also not be trusted.

 

Here’s an example of what happens when the signature algorithm is not trusted.

ERR_CERT_WEAK_SIGNATURE_ALGORITHM

Here’s an example of what happens if the CN or SAN values are wrong.

ERR_CERT_COMMON_NAME_INVALID

Related Articles, References, Credits, or External Links

NA

Windows Certificate Services ‘certsrv’ Website displays 403.14

KB ID 0001342 

Problem

I seem to get all the PKI/Certificate services problems! Yesterday I was trying to use the web enrolment portal on a certificate services server, and could not get in locally, (or remotely) via http, (or https) it simply showed me a 403.14 error.

HTTP Error 403.14 Forbidden

Solution

This was an odd one, in IIS Manager select the ‘Certsrv’ virtual directory > Advanced Options > And look at the ‘Path’.

Mine was missing the ‘en-us‘ folder from the end of the path!

Note: You will need to open an administrative command window, and then execute an iisreset command, before the change will take effect.

Related Articles, References, Credits, or External Links

NA

Certificate Services – Migrate from SHA1 to SHA256

SHA1 to SHA256 KB ID 0001243 

Problem

It’s time to start planning! Microsoft will stop their browsers displaying the ‘lock’ icon for services that are secured with a certificate that uses SHA1. This is going to happen in February 2017 so now’s the time to start thinking about testing your PKI environment, and making sure all your applications support SHA2.

Note: This includes code that has been signed using SHA1 as well!

Solution: SHA1 to SHA256

Below I’m just using an ‘offline root CA’ server, if you have multi tiered PKI deployments, then start at the root CA, fix that, then reissue your Sub CA certificates to your intermediate servers, fix them, then repeat the process for any issuing CA servers. Obviously if you only have a two tier PKI environment you will only need to do the root and Sub CA servers.

For your SubCA’s see PART TWO of this article.

Upgrade Your Microsoft PKI Environment to SHA2 (SHA256)

What about certificates that have already been issued? 

We are NOT going to revoke any CA certificates that have already been issued so existing certificates will remain unaffected.

Here we can see my CA server is using SHA1

Note: If your server says the provider is Microsoft Strong Cryptographic Provider and not Microsoft Software Key Storage Provider then skip down a bit.

You may have multiple Certificates (that is not unusual).

Open a PowerShell Window (run as administrator), issue the following command;

[box]

certutil -setreg ca\csp\CNGHashAlgorithm SHA256

[/box]

Restart Certificate Services.

[box]

net stop certsvc
net start certsvc

[/box]

 

Now you need to generate a new CA certificate.

Now you can see your new cert is using SHA256.

Mine Won’t Change From SHA1 to SHA256?

That’s because your cryptographic provider does not support higher than SHA1, for example ‘The command to change to SHA256 was successful, but the new certificate still says SHA1. If you look the Provider is set to ‘Microsoft Strong Cryptography Provider‘.

As you can see the strongest hash algorithm that supports is SHA1 that’s why it refuses to change.

How Do I Change the CA Cryptographic  Provider SHA1 to SHA256?

Make a backup of the CA Settings and the CA registry Settings.

[box]

Backup-CARoleService –path C:\CA-Backup -Password (Read-Host -Prompt "Enter Password" -AsSecureString) 
TYPE IN A PASSWORD
reg export HKLM\SYSTEM\CurrentControlSet\services\CertSvc c:\Reg-Backup\CAregistry.reg 

[/box]

Note: You might want to create the Reg-Backup folder first and grant some rights to it.

Now we need to delete the certificates this CA uses (don’t panic we’ve backed them up!) But first we need to find the certificate’s hashes to delete. Open an administrative command prompt, stop certificate services, and then issue the following command;

Note:  ROOT-CA is the name of YOUR CA.

[box]

Stop-service certsvc

Certutil –store my ROOT-CA >output.txt 

[/box]

Open output.txt then take a note of the hashes for the certificate(s)

Then Open an Administrative PowerShell window and delete them;

[box]

cd cert:\localmachine\my 
Del –deletekey <Certificate HASH>

[/box]

Now we need to import the p12 file we backed up earlier, then export that as a PFX file. Change ROOT-CA to the name of YOUR CA and the path to your backup folder and certificate as approriate.

[box]

Certutil –csp “Microsoft Software Key Storage Provider” –importpfx C:\CA-Backup\ROOT-CA.p12
Certutil –exportpfx my ROOT-CA C:\CA-Backup\Exported-ROOT-CA.pfx 
ENTER AND CONFIRM A PASSWORD

[/box]

 

Then restore the key from your PFX file.

[box]

Certutil –restorekey C:\CA-Backup\Exported-ROOT-CA.pfx 

[/box]

Now you need to import a couple of Registry files, in the examples below replace ROOT-CA with the name of your CA

Save the file as CA-Registry-Merge.reg (set the save as file type to All Files)

[box]

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\ROOT-CA\CSP] 
"ProviderType"=dword:00000000 
"Provider"="Microsoft Software Key Storage Provider" 
"CNGPublicKeyAlgorithm"="RSA" 
"CNGHashAlgorithm"="SHA1" 

[/box]

Merge the file into the registry.

Repeat the process with the following regisry file save this one as CA-Registry-Merge2.reg

[box]

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\ROOT-CA\EncryptionCSP] 
"ProviderType"=dword:00000000 
"Provider"="Microsoft Software Key Storage Provider" 
"CNGPublicKeyAlgorithm"="RSA" 
"CNGEncryptionAlgorithm"="3DES" 
"MachineKeyset"=dword:00000001 
"SymmetricKeySize"=dword:000000a8 

[/box]

Now change the hashing algorithm to SHA256, open an administrative command prompt and issue the following two commands;

[box]

certutil -setreg ca\csp\CNGHashAlgorithm SHA256
net start certsvc

[/box]

Renew the CA Cert.

You can now see the new cert is using SHA256.

 

 

Related Articles, References, Credits, or External Links

Moving Certificate Services To Another Server

Certificate Services – Create a ‘Wildcard Certificate’

KB ID 0001128

Problem

Now you may be thinking, “If you have your own CA/PKI solution why would you need to create a Wildcard Certificate”? If you can generate as many certificates as you want whats the point? Well today I need to setup ADFS, WAG (Web Application Gateway), and Remote Desktop Services Gateway Server. To make the whole thing wok on my test bench would be a lot less hassle if I could just use one certificate for everything!

Solution

Process carried out on Windows Server 2012 R2

Windows Key +R > MMC > {Enter} > File > Add/Remove Snap-in.

Certificates > Add.

Computer account > Next.

Local Computer > Finish.

OK.

Certificates > Personal > Right Click > All Tasks > Advanced Operations > Create Custom Request.

Proceed without enrolment policy > Next.

In nearly every case you can accept the default of ‘(No template) CNG Key’ However some applications (Particularly Active Directory Federation Services), need to user an older set of Cryptographic Service Providers (CSP’s). If that is the case change the option to ‘(No Template) Legacy Key’. > Next.

Details > Properties.

General Tab: Friendly Name > *.{your domain}.

Subject Tab: Ensure the Common Name (CN) is set to *.{your domain} > Enter the rest of your details as shown.

Extensions Tab: Add in Digital Signature and Key Encipherment.

Private Key: Key Size=4098 > Make private key exportable > Apply > OK.

Save the certificate request > Finish >Leave the Certificate console open, (you will need it later).

Locate the certificate request you just saved > Open it with Notepad > Select ALL the text and copy it to the clipboard.

Open the web enrolment portal of your certificate services server (https://server.domain.com/certsrv) > Request a certificate.

Advanced Certificate Request.

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.

Paste in the Text > Certificate Template = Web Server > Submit.

Base 64 encoded > Download certificate.

Save the certificate, and change its name from certnew > Save.

Back in the certificate console > Right Click ‘Persona’l > All Tasks > Import.

Next.

Navigate to the certificate you have just saved.

Next.

Finish.

Hopefully.

Now this may seem a little odd, but having just imported the certificate, to get it in PFX format you need to export it again. Right click the cert > All Tasks > Export.

Next

Yes, export the private key > Next.

Personal Information Exchange > Next.

Enter and re-type a password (You will need this to import the certificate so remember it) > Next.

Save it somewhere you can find it > Next.

Finish > OK.

Related Articles, References, Credits, or External Links

NA

Event ID 53 – ‘The public key does not meet the minimum size required by the specified certificate template’

KB ID 0000967 

Problem

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-TRUSTPOINT
NOTE 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

NA

VMware – Replace the ESXi Certificate

KB ID 0000974 

Problem

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.

[box]

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:PNL-ESX1, IP:10.254.254.12, DNS:PNL-ESX1.petenetlive.net

[ req_distinguished_name ]
countryName = GB
stateOrProvinceName = Teesside
localityName = Middlesbrough
0.organizationName = PeteNetLive
organizationalUnitName = Technical Services
commonName = PNL-ESX1.petenetlive.net

[/box]

3. Open a command window and execute the following three commands;

[box]

cd C:OpenSSL-Win32Bin
openssl req -new -nodes -out rui.csr -keyout rui-orig.key -config openssl.cfg
openssl rsa -in rui-orig.key -out rui.key

[/box]

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

[/box]

11. Enable SSH on your ESX Host.

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

NA

NDES – Fails to Issue Certificates (Signature Algorithm)

KB ID 0001021 

Problem

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 logg
crypto_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;

[box]

Certutil -setreg CAcspAlternateSignatureAlgorithm 1

[/box]

What this does is change a registry key, you can revert back by carrying out the following steps;

1. Open regedit and Navigate to;

[box]HKEY_LOCAL_MACHINE >SYSTEM > CurrentControlSet > Services > CertSvc > Configuration > {SERVER-NAME} > CSP[/box]

2. Locate the AlternateSignatureAlgorithm value and change it to 0 (zero).

3. Open a command windows as administrator > Restart certificate services.

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.

Then delete the RA certificates used for 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

NA

Windows Server 2012 ‘Direct Access with Windows 8’

KB ID 0000842

Problem

In the following procedure I’m using Window Server 2012, and Windows 8 Enterprise, I am NOT configuring for Windows 7 so I don’t need to worry about PKI and certificates. (Other than the one the direct access server uses for https identification).

I’m not adding in any Application or Infrastructure servers, this is just a basic run through on setting up Direct Access to get you up and running.

Solution

Step 1 Create Direct Access Group

You can of course accept the default of allowing access to the domain computers group, but I would like to tie things down a little further.

1. Server Manager> Tools > Active Directory Administrative Center > Select the OU (or create one) where you want to create the group.

2.Give the group a sensible name like DirectAccessComputers.

3. Remember when you try and ‘add’ members it will by default NOT have computers listed you will need to add them in.

4. Add in your computer objects as required.

Step 2 Install Direct Access

5. You can simply execute the following command;

[box]
Install-WindowsFeature RemoteAccess -IncludeManagementTools[/box]

6. Or from Server Manager > Tools > Add Roles and Features.

7. Simply add in ‘Remote Access’ and accept all the defaults.

Step 3 Configure Remote Access

8. Once installed launch Remote Access Management.

9. Run the getting stated wizard.

10. Deploy Remote Access Only (I’m not deploying VPNs).

11. Select how the server will be deployed, mine has a single NIC and I’m going to port forward TCP Port 443 (https) to it from the firewall. Enter its Publicly addressable name > Next > Finish.

Note: If you get an error see here.

12. Configure Remote Clients > Edit.

13. I want both options > Next

14. Remove the domain computers and add in the group we created above. Untick the ‘mobile only’ option.

Note: Force Tunnelling means that the remote clients will access the internet though YOUR corporate network. This is only a good idea if you have internet filtering, AV or NAP that you want to take advantage of. (It’s literally the exact opposite of split tunnelling).

15. Remote Access Server > Edit.

16. Select an existing Cert or create a new one > Next.

17. Remember I’m just using Windows 8, if you see the Windows 7 box and think “ooh I’ll tick that!” Then you need to start using certificates > Finish.

18. Finish.

19. Review the settings > Apply.

20. Operation Status.

21. Press Refresh until all the services are green.

Step 4 Configure Clients

The title is a misnomer and to be honest there is no configuration to be done, but they have to get the settings through group policy, so log then onto the domain.

22. A quick simple check is to run the following command;

[box]
Get-DaConnectionStatus[/box]

Note: If you get an error message make sure you are not using Windows 8 Pro see here.

23. The client knows it’s ‘inside’ the LAN, because it has a Name Resolution Policy Table and it can see your internal DNS, you can prove this with the following command;

[box] Get-DNSClientNrptPolicy[/box]

Step 5 Test Clients Externally

Note: Before you proceed your Direct access server needs to be publicly available via the name you specified on the certificate in step 11, and needs to have https open to it.

25. Whilst out on the internet you can test your remote client by first making sure it’s pointing to the correct place;

[box]netsh interface httpstunnel show interface[/box]

This should give the the URL that is on the certificate you specified in step 11, when you ping it by name you should expect a reply (unless ICMP has been blocked by your edge device).

26. And to prove that the client knows it’s NOT on the corporate LAN execute the following;

[box]netsh dnsclient show state[/box]

27. So If i try to ping the internal FQDN of my Direct Access server it should respond (Note its IPv6 address will respond this is normal).

Note: Here I’ve only setup the one server, you can add more Infrastructure and Application servers in the Remote Access Management Console.

28. Because I can resolve that, I can access resources on that server like UNC paths.

29. To access shared resources.

Step 6 Monitoring Remote Access Clients

30. Back on the Direct Access server, you can see the remote clients under ‘Remote Client Status’.

31. Right click each one for a more detailed view.

Related Articles, References, Credits, or External Links

NA

Windows Server – Secure RDP Access with Certificates

KB ID 0000944

Problem

This ensures that traffic that is sent over an RDP connection to a server is protected by TLS/SSL Encryption. IT DOES NOT stop clients connecting to an RDP server if they do not have a trusted certificate. If you need that level of security, that should already be done by 802.1x.

Solution

Create an RDP Certificate Template

1. On the domain CA Launch the Certification Authority Management Console > Certificates Templates > Right click > Manage.

2. Locate, and make a duplicate of, the Computer template.

3. General tab > Set the display and template name to RemoteDesktopSecure.

4. Extensions tab > Application Policies > Edit > Add.

5. New > Name=SSL Secured Remote Desktop > Object Identifier=1.3.6.1.4.1.311.54.1.2 > OK.

6. Select the policy you have just created > OK.

7. Remove the other policies, so only the one we have just created remains > OK.

8. Security tab > Ensure that the the computer groups you want to apply the template to, are selected for Read and Enroll. (Below I’ve put three examples, firstly I create a group for my servers, secondly I just apply it to my domain controllers, or lastly I allow all Domain Computers). How you want to apply this depends on you.

9. Issue/Publish the new certificate template.

Create a GPO to secure RDP access with Certificates.

10. From the Group Policy Management Console, create (or edit) a GPO and give it a sensible name.

11. Edit that policy and navigate to;

[box]

Computer Configuration> Policies >Administrative Templates > Windows > Components > Remote Desktop Services >Remote Desktop Session Host > Security.

[/box]

Locate the ‘Server authentication certificate template’ policy.

12. Enable it and set the template name to RemoteDesktopSecure > Apply > OK.

13. In the same location, locate the ‘Require use of specific security layer for remote (RDP) connections’ policy.

14. Enable the policy and set the security layer to SSL (TLS 1.0) > Apply > OK > Exit the policy editor.

15. Link the GPO to an OU that contains the servers you want to apply the policy to.

16. You may need to wait a short while, but eventually the servers will get their certificates.

Note: This view is simply ‘Microsoft Management Console’ with the ‘Certificates (Local Computer)’ snap-in added.

17. To prove it’s working, try connecting from a client that does not trust your Domain CA, and you should see an error something like this.

Check What Certificate RDP Is Using

You can check the thumbprint of the certificate the server is using. Windows Key+R > Regedit {Enter} > Navigate to;

[box]

HKEY_LOCAL_MACHINE
> SYSTEM > CurrentControlSet > Control > Terminal Server > WinStations > TemplateCertificate

[/box]

You can check this with the actual Certificate> Windows Key+R > mmc {enter} > File > Add/Remove Snap-in > Certificates > Local Computer > Open Certificates > Personal > Certificates > Locate the certificate you ‘Think’ RDP is using and you can compare its thumbprint with the registry key you found above.

Or you can execute the following PowerShell command to get the RDP certificates thumbprint;

[box]

Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices

[/box]

Related Articles, References, Credits, or External Links

NA