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.
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.
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 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.
If you are on vCenter version 7, click on VM Options, then expand Advanced, and click on Edit Configuration.
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.
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
New-Item -Type Directory -Path "C:\HWID"
Set-Location -Path "C:\HWID"
C:\Program Files\WindowsPowerShell\Scripts to the path environment variable by running the following command $env:Path += ";C:\Program Files\WindowsPowerShell\Scripts"
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.
…
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.
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.
If my certificate chain for my website, thedxt.ca, was configured in the following order:
This order would cause a broken certificate chain as the certificate chain would be out of order and considered malformed, which can cause issues.
The image above is an example of a malformed certificate chain, as each item is not issued by the previous one.
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.
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.
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?
…
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 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.
…
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.
C:\SSL as my working directory.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.
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.
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.
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.
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.
