Latest posts

SSL Inspection

Inspecting TLS/SSL traffic on corporate networks is very common, as over 80% of all web traffic is encrypted. If you aren’t performing TLS/SSL traffic inspection, you are potentially leaving your network exposed.

The simple act of inspecting SSL connections helps reduce your attack surface. SSL inspection can make it harder to establish malicious outbound connections, such as malware trying to communicate with the C2 (Command and Control) server.

To reduce the attack surface further, I like to deploy a block on common file types that could be malicious, such as EXEs. If SSL inspection isn’t performed, any EXE downloaded via SSL won’t be blocked.

In this post, I will go over the basics of SSL inspection. I won’t go into details about certificate chains. If you want to understand more about certificate chains, my post Certificate Chain goes into more detail.

An SSL inspector sits in the middle of all SSL traffic, inspecting everything by decrypting and re-encrypting encrypted traffic on the fly. At its core, SSL inspection is like a MitM (man-in-the-middle) attack you control.

To inspect SSL traffic, the SSL inspector needs to decrypt it first. It can do this by tricking clients into communicating with it instead of the actual website, and the SSL inspector will communicate with the website on the client’s behalf. An SSL inspector is also a proxy.

To keep everything secure even when decrypting SSL traffic, the SSL inspector needs to be its own intermediate CA to resign and re-encrypt everything to send back to the client. All public-facing websites or web applications have certificates issued by a public root CA.

The SSL inspector can’t just issue certificates on behalf of a public root CA, as that would break the chain of trust. Even if you reach out to an intermediate CA, they will not sell you a certificate that could allow you to issue certificates on their behalf, even if it’s just for your internal network, as that also breaks the chain of trust.

To deploy an SSL inspector, you have two options. The first option is to deploy the certificate from your SSL inspector to all devices, making it and the certificates it issues trusted. The second option is to deploy your own internal root CA and allow your SSL inspector to be a subordinate CA (also known as an intermediate CA) and issue certificates on behalf of your internal root CA.

Broken Certificate Chain

Certificate chain issues are extremely widespread and more common than you think. You start to see how many websites have broken certificate chains when you start performing SSL inspection on a network.

If you want to read more about certificate chains, my post Certificate Chain goes into more detail.

My website, thedxt.ca, has a server certificate for thedxt.ca, issued by the intermediate CA GTS CA 1P5. The intermediate CA GTS CA 1P5 certificate is issued by the public root CA GTS Root R1.

Correct certificate chain for thedxt.ca

The image above is an example of a correctly formed certificate chain. Each item is issued by the previous one, and because the root CA is trusted, the entire chain is trusted.

In this post, I will go over what can cause a broken certificate chain and how to verify your certificate chain properly.

There are two main types of broken certificate chains. First is the malformed certificate chain or the out of order certificate chain. The second is an incomplete certificate chain.

Malformed Certificate Chain

If my certificate chain for my website, thedxt.ca, was configured in the following order:

  • A server certificate for thedxt.ca.
  • The public root CA GTS Root R1 certificate.
  • The intermediate CA GTS CA 1P5 certificate.

This order would cause a broken certificate chain as the certificate chain would be out of order and considered malformed, which can cause issues.

Out of order certificate chain for thedxt.ca

The image above is an example of a malformed certificate chain, as each item is not issued by the previous one.

Incomplete Certificate Chain

Another common issue that causes broken certificate chains is an incomplete certificate chain. An incomplete certificate chain means a certificate is missing in the certificate chain. Usually, this is when one or more intermediate CA certificates are missing. It’s an issue because the path to the root CA can’t be completed.

Incomplete Certificate Chain for thedxt.ca

The image above is an example of an incomplete certificate chain, as there are no links to follow for the path to the root CA.

The Why

Many people don’t realize they have a broken certificate chain, as most things will just work even when the certificate chain is broken. Web browsers try to fix broken certificate chains for websites so users don’t run into issues.

A very common practice for checking if your SSL/TLS certificate is working on a public-facing item is to use a web browser to browse to the item and see if you get any certificate issues. Because web browsers auto-fix broken certificate chains, you end up with a false sense that everything is working correctly.

If you can’t trust a web browser to check if your certificate chain is correct, how do you check it?

Certificate Chain

This post will explain the main components of a certificate and how they contribute to a certificate chain.

A certificate chain consists of three main components:

  • A root CA (Certificate Authority) certificate.
  • One or more intermediate CA (Certificate Authority) certificates.
  • A server certificate.

Root CA

A root CA is the most trusted source of authority for certificates. It is the first link in a certificate chain, and all certificates are issued by it in one way or another.

There are two main types of root CAs. The first is an internal root CA, which is common on corporate networks, and the second is a public root CA.

Technically speaking, a root CA is just a CA with a self-signed certificate. What sets a public root CA apart is that their self-signed certificates are widely pre-loaded by operating systems and web browsers, making them trusted by default.

This is the list of the public root CAs trusted by Chromium based web browsers, and this is the list of the public root CAs trusted by Microsoft Windows.

Because public root CAs are widely pre-trusted, when you install a TLS/SSL certificate issued by a public root CA on a web server or web application, you don’t need to do anything else to make your certificate trusted.

Convert PFX Certificate

While having your SSL/TLS certificate in a PFX file is great, as most applications support the PFX file, there are still some cases where a PFX file is not supported, and you need the certificate in the PEM format as a CRT file (also called a CER file) with a key file (also called a PEM file).

In this post, I will show you step-by-step how to convert a PFX file into a single file or individual files with and without passwords each method supports the PEM format.

Prerequisites

  • OpenSSL binary installed. You can find the OpenSSL binaries on the OpenSSL wiki.
  • Exported certificate as a PFX file. If you need to learn how my post on Exporting a Certificate with MMC details all the steps.
  • Password for the PFX file.

The Process

  • Place your PFX file in a working directory. I will be using C:\SSL as my working directory.
  • Open command line. You can use Linux or Windows. The commands are all the same regardless of which OS you are using. I will be using Microsoft Windows with Windows Terminal and PowerShell.

Depending on your needs, you may need to convert your PFX file in several different ways. Here are the methods that I will cover.

All of the commands below will use the following options.

  • pkcs12 tells OpenSSL that the file it is being fed is a PKCS#12 file. PKCS#12 is another name for a PFX file.
  • in tells OpenSSL where the source file is.
  • out tells OpenSSL where to store the converted file.

Install VMware Horizon Connection Server Certificate

Installing an SSL/TLS certificate on the VMware Horizon Connection Server is a common task. The whole process may feel daunting if you’ve never installed a certificate on the Horizon Connection Server.

VMware Horizon has had a few names, and some of those old names are still present at its core. VMware Horizon was originally called VMware VDM (Virtual Desktop Manager), later renamed VMware Horizon View, and today, it is called Horizon.

In this post, I will show you step-by-step how to install a certificate on the Horizon Connection Server and update the VMware Unified Access Gateway appliance to reflect the changes.

Prerequisites

The Process

The process is broken up into two sections. The first section details the steps needed on the VMware Horizon Connection Server, and the second section details the steps needed on the VMware Unified Access Gateway appliance.

VMware Horizon Connection Server

  • Connect to your Horizon Connection Server
  • Open MMC.
  • Add the Certificates Snap-in.
  • Select Computer account and click Next.
  • Select Local computer and click Finish.
  • Click OK to close the Add or Remove Snap-ins window.
  • Expand out Certificates (Local Computer) > Personal > Certificates.
  • You will see that one of the certificates has the friendly name vdm.

Install VMware vCenter Certificate in Windows

The VMware vCenter root certificate is an essential part of vCenter. When you install vCenter, it also installs the VMCA (VMware Certificate Authority) in your vCenter. The VMCA is a barebones CA for vCenter that issues certificates to the various elements of vCenter as needed.

You should install the VMCA root certificate on your system because not all web browsers trust it. After installing the root certificate, your web browsers will trust the certificates on your ESXi hosts in your vCenter, as they use certificates issued by the VMCA on your vCenter.

Installing the VMware vCenter certificate will help prevent errors. Such as the invalid certificate error NET::ERR_CERT_AUTHORITY_INVALID.

The operation failed error is another one that can present itself when uploading files to a datastore.

Another error is the invalid server certificate error in PowerCLI.

Connect-VIServer

Error: Invalid server certificate.

Use Set-PowerCLIConfiguration to set the value for the InvalidCertificateAction option to Prompt if you'd like to connect once or to add a permanent exception for this server.

Additional Information: Could not establish trust relationship for the SSL/TLS secure channel with authority 'vcenter'.

At line:1 char:1
+ Connect-VIServer -Server "vcenter"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : SecurityError: (:) [Connect-VIServer], ViSecurityNegotiationException
+ FullyQualifiedErrorId :
Client20_ConnectivityServiceImpl_Reconnect_CertificateError, VMware.VimAutomation.ViCore.Cmdlets.Commands.ConnectVIServerCode language: plaintext (plaintext)

In this post, I will show you step-by-step how to install the VMware vCenter root certificate in Microsoft Windows.

The Process

  • Go to the URL of your vCenter.
  • Off to the right, there’s a link that says Download trusted root CA certificates.

Install PFX Certificate in Windows

Once you have exported your certificate, the next step is installing the certificate PFX on other servers as needed.

In this post, I will show you step-by-step how to install an exported PFX certificate file on a Microsoft Windows system.

Prerequisites

The Process

  • Copy the exported certificate PFX file to the server on which you need to install the certificate.
  • Right-click on the PFX file and select Install PFX.
  • Select Local Machine and click Next.

VMware Unified Access Gateway Certificate Install

Installing your own certificate is one of the first things you’ll need to do when setting up the VMware Unified Access Gateway appliance.

In this post, I will detail step-by-step how to install a certificate on the VMware UAG.

Prerequisites

The Process

  • Login to the UAG
  • Select Configure Manually.
  • Under Advanced Settings, click on TLS Server Certificate Settings.

Export a Certificate with MMC

If you work with wild card certificates, it’s common to need to deploy them to more than one server. You will need to export the certificate to install it on other systems.

In this post, I will show you step-by-step how to export a certificate using MMC (Microsoft Management Console).

The Process

  • Connect to the system that has the certificate you want to export.
  • Open MMC.
  • Add the Certificates Snap-in.
  • Select Computer account and click Next.
  • Select Local computer and click Finish.
  • Click OK to close the Add or Remove Snap-ins window.
  • Right-click on the Certificate you want to export and click Export.

Complete a CSR

When you create a CSR and provide it to your certificate vendor or CA (Certificate Authority), you must complete the CSR (Certificate Signing Request).

In this post, I will show you step-by-step how to complete a CSR.

Prerequisites

  • CSR generated on a system that you want to complete the CSR on. If you don’t know how my post Generate CSR with MMC details all the steps.

You can check which system has the pending certificate by checking the Certificate Enrollment Requests in MMC (Microsoft Management Console).

Certificate Pending completion of CSR

The Process

  • Connect to the system you used to generate the CSR.
  • Download the certificate files from your certificate vendor or CA.
  • Right-click on the certificate file and select Install Certificate.