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

ERR_CERT_COMMON_NAME_INVALID

ERR_CERT_COMMON_NAME_INVALID KB ID 0001844

Problem

Error seen when attempting to open a web page that’s been secured by https with a certificate.

Your Connection isn’t private
Attackers might be trying to steal your information from  {host-name} (for example, passwords , messages or credit cards).

Solution : ERR_CERT_COMMON_NAME_INVALID

This error confused me GREATLY because I generated that certificate, and I was pretty certain the common name was correct, so I double checked.

The truth is this error is VERY  MISLEADING, the problem has nothing to do with the certificates Common Name (for the uninitiated, the Common Name or CN is a value within a certificate, that usually holds the ‘resolvable name’ of the website you are visiting i.e. on my certificate (above) you can see that’s www.petenetlive.com).

The certificate giving me the error in the picture above THERE NOTHING WRONG WITH THE COMMON NAME. The real reason that you are seeing this error is because there’s no entry in the Subject Alternative Name (SAN) value in the certificate.  So I created a new certificate and copied that same value into both the common name and subject alternative name fields – like so.

If your certificate is publicly signed, then you will need to go back to the certificate vendor and have the certificate reissued with a subject alternative name. However, I issue these certificates internally from my own Certificate Services, so I just needed to add that like so.

 

Related Articles, References, Credits, or External Links

Microsoft PKI Planning and Deploying Certificate Services

0x800094801 Certificate Issue Error

VMware: Server Certificate Subject Name Does Not Match

KB ID 0001504

Problem

If you replace the self signed certificate on your Horizon Connection servers, (so that they have a certificate with your ‘public’ address), you will see this error;

Status: Servers’s certificate subject name does not match the server’s External URL.
Server’s certificates is not trusted.

SSL Certificate: Invalid

Solution

At first I thought this was simply a DNS problem, and I needed to setup split DNS. But that’s not the case, you need to change the the connection servers name(s) to the public name(s) in the connection server properties in Horizon Administrator.

After a few minutes the error will disappear.

Related Articles, References, Credits, or External Links

NA

Using LDP to Find an Objects ‘Distinguished Name’ in Active Directory

KB ID 0001337 

Problem

There are a few occasions when you need to know an objects ‘Distinguished Name’ (DN). For me it’s usually when I’ve got a device that needs to do LDAP/LDAPS lookups, (RSA Appliance, Netscaler, Cisco FirePOWER, etc). Today someone needed to ‘bind’ a Checkpoint firewall to Active Directory, and asked me to create user, and give them the DN and password.

I’ve mentioned ldp.exe many times, but never dedicated a post to it, it’s a tiny executable, that was first seen in the server 2003 support tools.  With 2008 you needed to add the Active Directory Lightweight Directory Service Role to get it. With server 2012 and 2016 you will get it on any Domain Controller.

For a member server, (or non domain joined server) you can add LDP.exe by simply adding the following feature from server manager.

LDP Usage

Windows Key+R > ldp {Enter} > Connection > Connect > select localhost, (if you are on the DC, or the FQDN of a DC if you are not). Normally port 389 is fine, but if you have enabled LDAPS, you might want to use port 636, and tick SSL also > OK.

Now you need to bind to LDAP, I’m using my logged on account, but if you want to test a user account can bind to Active Directory, then you can specify a username/password and domain > OK.

Note: To bind to, and read all objects in Active Directory, only  domain user is required.

Now to view anything > View > Tree > Select the root DN to view all of AD, (in my case DC=pnl,DC=com) > OK.

You can now browse your AD, and get the DN for any object.

Related Articles, References, Credits, or External Links

Windows Server 2012 – Enable LDAPS

Cisco FirePOWER Management Center Appliance – Allowing Domain Authentication

Exchange 2007 & 2010 – Setup and Deploy Outlook Anywhere

KB ID 0000519 

Problem

What used to be a fiddly job, is now very simple to do, setting up Outlook Anywhere (formally known at RPC over HTTP) takes about 10 minutes.

What is Outlook Anywhere?

This is a system that lets you connect Microsoft Outlook to to your Exchange server over the web, this means you can connect to to your email, calendaring and tasks etc, without the need for a VPN connection.

Solution

Outlook Anywhere with Exchange 2007 (Exchange 2010 Skip to Step1)

If you plan to deploy Outlook Anywhere with Exchange 2007 there is an additional step you need to carry out before you start. From server manager > Feature > Add Features > Add in the ‘RPC over HTTP Proxy’ feature before you start. (Note: you DONT need to do this if you are running SBS 2008).

Step 1 Configure Exchange

1. First we need to turn it on: from within the Exchange Management, expand Server configuration > Client Access > Select the server in the central pane > Select “Enable Outlook anywhere” in the action pane.

2. Enter the publicly addressable name of your Exchange server, for this example I’m using NTLM authentication > Enable.

Note: The external host name is the address that you would type into a browser to contact the Exchange server i.e. for Outlook Web Access http://mail.domaina.com/owa. This would mean the public name is mail.domaina.com. This name must be the Common Name (CN) on the Exchange server’s digital certificate.

Exchange 2010 – Working with Certificates

3. Take heed of the information, nothing’s going to work for 15 minutes (Even Exchange is telling you to apply the cup of coffee rule) > Go and have a hot milky beverage.

4. Look at the timestamps and the clocks, this one took 14 minutes (for once the dialog had it spot on!) You should see Event ID 3007, 3003, 3004,(all these are normal) and finally,

5. Event ID 3006 > Outlook Anywhere is up and running on the server. (Note: you will NOT see this on an Exchange 2007 Server, see the second screenshot).

Note: To Access from Outside your network the public name of the Exchange server (in this case mail.domain.com), needs TCP port 443 (HTTPS) open to it, or “Port Forwarded” to the Exchange server.

Note2: To work internally make sure that mail.domaina.com resolves to the INTERNAL IP address of the Exchange server.

6. You may also want to execute the following command. Particularly if you use SBS, which has a habit of setting remote.publicdomain.com as the default outside name.

[box] Set-WebServicesVirtualDirectory –Identity ‘EXCHANGE-MAILEWS (Default Web Site)’ –ExternalUrl https://mail.domain.co.uk/ews/exchange.asmx[/box]  

Step 2 Configure Outlook for Outlook Anywhere

1. In this example I’m using Outlook 2010 and the mail profile/account has NOT been setup, if you already have an account edit it, select “More Settings” and jump to number 4.

Note: To support Outlook Anywhere you need a minimum of Outlook 2003 SP2

2. If you are setting up your Outlook client internally, the autodiscover service should fill in the details for you.

3. If it auto configures the settings for you, tick the box to manually configure server settings.

4. More Settings.

5. Connection Tab > Tick “Connect to Microsoft Exchange Server using HTTP” > Click “Exchange Proxy Settings”.

6. Put on the URL (Public name of Exchange – see step 1 number 2) > I’m using NTLM authentication you may be using basic, if you don’t know, check with your IT department, or try each one.

7. Security Tab > Ensure “Encrypt data between Microsoft Outlook and Microsoft Exchange” is selected.

8. Restart Outlook – you may be asked for your username and password again this is normal.

 

Related Articles, References, Credits, or External Links

Original article written: 04/10/11

Exchange 2010 – Working with Certificates

Buy Your Exchange Certificates Here!

Cisco ASA 5500 – Using a Third Party Digital Certificate

(For Identification, AnyConnect, and SSL VPN)

KB ID 0000694

Problem

A client asked me how to do this, so off I went to the test bench to work it out.

Note: I’m this example In going to submit the request to, and issue the certificate from, my own windows domain certificate authority, you would send your request to a third party certificate authority, here’s a direct link to the certificate type you require. To use your own CA every client connecting to the ASA would need to trust this CA.

Solution

Certificates are date specific, so we need to make sure your firewall knows the correct date and time.

1. Connect to the ASA via ASDM > Configuration > Device Setup > System Time > Set the time and time zone correctly.

Note: As shown, from command line simply enter “show clock”.

2. Configuration > Device Management > Certificate Management > Identity Certificates > Add > New > Supply a key pair name > Generate Now.

Note: If using Digicert change the Key Size to 2048 or you will see this error, when you attempt to get your certificate.

Something is wrong
The CSR uses an unsupported key size, please generate a new CSR with a key size of at least 2048 bits
.

3. Select > Set each attribute, and add it one by one (as shown) > OK.

4. Advanced > Set the FQDN to the SAME name you entered for the CN in step 3 > OK > Add Certificate.

5. Choose a location to save the certificate request.

6. Locate and open the certificate request and it should look something like this.

Note: This is the information your certificate vendor will require.

7. Once your request had been processed the certification authority should send you a certificate. (Note: some vendors may send you a text file that you need to rename from filename.txt to filename.cer before it will look like this).

8. With the certificate open (as above) > Certificate path > Select the the Issuing Certificate Authority > Copy to File.

Note: You need to import the root certificates, and depending on the vendor, any intermediate certificates, I’ve shown an example from two major vendors to illustrate.

9. Select “Base-64 encoded…” > Next.

10. Save the cert somewhere you can find it.

11. Open it with notepad, and it should look like this > Select ALL the text.

12. Back at the ASDM > Configuration > Device Management > Certificate Management > CA Certificates > Add > Paste certificate in PEM format > Paste in the text > Install Certificate.

13. Repeat the process for any other RootCA or Intermediate Certificates. Then you will need to go back to step 8 and export the web certificate itself, (i.e. in this case select vpn.petenetlive.net and export that to file, and copy that from notepad to the clipboard).

14. Back in the ASDM this time you will need to install the Identity Certificate, (this is the one you paid for!) > Select the pending request from earlier > Install > Paste in the text > Install Certificate > Apply.

15. To enable the certificate on the outside interface > Configuration > Device Management > Advanced > SSL Settings > outside > Edit > Select the new one from the list > OK > Apply.

16. Note: If you were configuring your AnyConnect VPN’s later this is the point in the setup, where you would select the new certificate.

17. Make sure you can resolve the name that’s on the CN of your certificate and you can reach it from a client machine.

18. Now you should be able to connect without certificate warnings.

19. Don’t forget to save the settings on your ASA (File > Save Running Configuration to Flash).

Related Articles, References, Credits, or External Links

Securing Cisco SSL VPN’s with Certificates

Cisco ASA – Cannot Enable Third Party Certificate (9.4 and later)