Latest posts

UniFi Network Application MongoDB Upgrade

If you have been using the UniFi controller for a very long time, there’s a chance you are running an older version of MongoDB. When Ubiquiti released version 8.1 of the UniFi network application server, they finally bumped up the supported MongoDB version from 4.4 to 7.0.

The MongoDB upgrade path only supports jumping one major version at a time, and some manual steps are needed. Yes, you could take a settings-only backup and reroll the whole setup, but where’s the fun in that?

In this post, I will show you step-by-step how to upgrade the Mongo database version from 4.4 to 7.0 for the Unifi network application server running on docker.

Prerequisites

  • Backup your UniFi config. My blog post, UniFi Network Server Settings Backup and Export, covers how to do this.
  • Running UniFi network application version 8.1 or newer.
  • The service name of the MongoDB for UniFi from your docker compose file.
  • The container name of your MongoDB for UniFi.

The Process

The entire process revolves around docker exec as we will execute commands directly into the Mongo database container.

You can follow this process on other UniFi controller setups that aren’t done with docker. However, I’ve only validated the process with on a docker setup, but the command structure would be similar.

To be extra safe during this process, I will bring down my UniFi docker stack and only bring up my UniFi database container.

I will run the command docker compose down to bring the UniFi controller offline. This helps ensure the UniFi network application doesn’t try to write to the database while the database is upgrading.

  • Bring up the MonogoDB container for UniFi with the following command. Replace Mongo_Service_Name with the service name for MongoDB from your docker compose file. sudo docker compose up Mongo_Service_Name -d

If you are using my docker compose setup from my blog post, UniFi Network Server with Docker, the MongoDB service name will be unifi-net-app-db

For me, the command will be sudo docker compose up unifi-net-app-db -d

Before starting any upgrades, let’s double-check which version of MongoDB is installed and what the compatibility level is currently set to. We will do that by using the MongoDB shell with the command mongo. We will tell Mongo that we will provide some commands from which we want the output by using the argument eval followed by our commands.

The command to check which version of MongoDB we are running and what our compatibility level is set to is the following command db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

To run this against our Mongo docker container, we will use docker exec with a shell command followed by the mongo shell commands we want to run.

  • Run the following command to check what MongoDB version is running. Replace Mongo_Container_Name with the name of the MongoDB container that you are using with UniFi. sudo docker exec Mongo_Container_Name sh -c 'mongo --eval "db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )"'

For me, the command looks like

sudo docker exec unifi-net_DB sh -c 'mongo --eval "db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )"'

Your output should be something like this

MongoDB server version: 4.4.29
{ "featureCompatibilityVersion" : { "version" : "4.4" }, "ok" : 1 }

The output above confirms that we are running MongoDB 4.4, and our feature compatibility is set to the same version.

If you get an error that mongo is not found, this is due to running a newer version of MongoDB that no longer supports the mongo command as that command has been deprecated in newer versions.

The replacement command for mongo is mongosh. However, the output differs from the old mongo command when gathering the compatibility levels.

UniFi Network Server Settings Backup and Export

When you self-host the UniFi Controller or the UniFi Network Application server, it’s a good idea to take a backup before making major changes. Backups are always a good thing to have.

In this post, I will show you step-by-step how to take a settings only backup of the UniFi Network Application server.

The Process

  • Login to the UniFi Network Server.
  • Click on Settings.
  • Click on System.

Omnissa Horizon Unmanaged VDI Black Screen Issue

I recently encountered a strange issue with Omnissa Horizon (formerly VMware Horizon) that resulted in a black screen presenting to the VDI users when they logged in. When you search for this issue, you will find a lot of information about various solutions to the blank screen issue. However, none of them solved the problem I was running into.

VMware Horizon black screen on login

In a traditional VMware Horizon setup, there can be several causes for the black screen issue. If your setup is VDI VMs managed by VMware Horizon, then the black screen issue you may have is likely covered in my friend Stephen’s blog post, VMware Horizon Blank Screen.

His post did not cover my black screen issue. To replicate the problem I encountered, you need to have VDI VMs in VMware vCenter, and VMware Horizon configured not to use the VMware vCenter integration.

While having your VMware VDI VMs unmanaged by VMware vCenter in VMware Horizon is still a supported configuration, it is rare. However, there can be some edge cases where, even though your VDI VM exists in vCenter, you don’t want to let Omnissa Horizon access vCenter. My blog post, Omnissa Horizon Desktop Pool without vCenter, covers how to configure this.

The Why

The black screen issue presents itself when Omnissa Horizon does not have the integration to VMware vCenter to manage the VMware VDI VM. Due to this, a required setting in vCenter for the VDI VM is not configured when adding the VM to a desktop pool, as Horizon has no access to vCenter to make the change. That setting is called screen DMA (Direct Memory Access).

In version 6 of VMware vCenter, the default setting for screen DMA was changed to disabled by default. Screen DMA is required to enable proper streaming of the VDI desktop to the end users.

In this post, I will show you step-by-step how to enable the screen DMA setting to fix the black screen issue on a VMware Horizon VDI VM in VMware vCenter when the Omnissa Horizon integration to VMware vCenter is not used.

The Fix

Confirm The Issue

  • Login to VMware vCenter and select the VDI VM experiencing the black screen issue.
  • Click on Edit Settings.
  • Click on Advanced Parameters.

If you are on vCenter version 7, click on VM Options, then expand Advanced, and click on Edit Configuration.

Windows Autopilot Hardware ID

Windows Autopilot uses several mechanisms to function. A common one is the device’s hardware hash, also called the hardware ID. There are several ways to gather the hardware ID from a device to use in Windows Autopilot.

In this post, I will show step-by-step how to get the hardware ID from a system with PowerShell and how to import it into Windows Autopilot. The process is the same regardless of whether the system is a virtual machine or a physical machine, and it doesn’t matter if the system is running Windows 10 or Windows 11.

Get Hardware ID

  • Open PowerShell as Admin.
  • Run the following command to enable TLS 1.2 [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
  • The following command will create a folder named HWID on the root of C for the hardware ID file New-Item -Type Directory -Path "C:\HWID"
  • Switch into that directory with the following command Set-Location -Path "C:\HWID"
  • Add C:\Program Files\WindowsPowerShell\Scripts to the path environment variable by running the following command $env:Path += ";C:\Program Files\WindowsPowerShell\Scripts"

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 Omnissa Horizon Connection Server Certificate

Installing an SSL/TLS certificate on the Omnissa Horizon Connection Server (formerly 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.

Omnissa Horizon has had a few names, and some of those old names are still present at its core. Most recently it was called VMware Horizon. The original name of Horizon was VMware VDM (Virtual Desktop Manager), later renamed VMware Horizon View, and today, it is called Horizon or Omnissa 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 Omnissa Horizon Connection Server, and the second section details the steps needed on the Omnissa Unified Access Gateway appliance.

Omnissa 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.