Liquidware posts hotfixes for console components in the ProfileUnity Hot Fix List. These include:
- MongoDB version updates
- .NET Core updates
- ProfileUnity core console-side updates
đ Contents
Issue
Running the MongoDB upgrade tool produces one of the following prompts depending on the environment configuration:
- Clustered environment â the upgrade tool detects active cluster membership and blocks the upgrade.
- Standalone or previously-clustered node â the upgrade tool detects a certificate that does not meet the new mutual TLS requirements.
Screenshots of the specific prompts are shown in the Zendesk article. The root cause in both cases is described in the section below.
MongoDB 7.0.26 â Mutual TLS Certificate Requirement
đ Breaking Change in MongoDB 7.0.26
Starting with MongoDB 7.0.26, mutual TLS (mTLS) is enforced for all node-to-node communication. This requires every certificate used by MongoDB to contain both of the following Enhanced Key Usage (EKU) values:
â Required: Server Authentication
â Required: Client Authentication
Most certificates â including the self-signed MongoDB certificates created during the initial ProfileUnity installation â contain only Server Authentication. These certificates are no longer sufficient as of 7.0.26 and will cause the upgrade to fail.
If your environment uses a custom certificate, a new certificate containing both Client Authentication and Server Authentication EKU must be created and available before beginning the cluster teardown. It will be required when rebuilding the cluster.
Limitations
- The existing certificate(s) already contain both Server Authentication and Client Authentication EKU values
- All nodes are on the same major version of MongoDB prior to upgrading
Resolution â Cluster Teardown and Rebuild
When an in-place upgrade is not possible, the cluster must be torn down, each node returned to standalone, upgraded individually, and the cluster then rebuilt. This will cause an interruption to user license validation and result in a notification box on any end-user machine that logs in during the operation.
Perform the following steps on each node, one at a time:
Step 1 â Back up the database
Log in to the ProfileUnity console and click Backup Databases under the Database section of the Administration page.
Step 2 â Snapshot all nodes before proceeding
Shut down each ProfileUnity cluster node and take a VM snapshot. Once all snapshots are complete, power all nodes back on before continuing.
Step 3 â Return each node to standalone
Log in to a node, navigate to the Clustering section of the Administration page, and click Go to Standalone. Wait for the operation to complete, then log back in and confirm the node has successfully reverted to standalone mode.
Step 4 â Repeat for all remaining nodes
Repeat Step 3 for every node in the cluster before proceeding to Step 5.
If using a custom certificate, import the new certificate (containing both Client Authentication and Server Authentication EKU) into each node under the Web Services section of the Administration page before proceeding.
Step 5 â Run the MongoDB upgrade utility on each node
With all nodes in standalone mode, run the MongoDB upgrade utility on each node individually.
When using the default Mongo certificates, they are automatically recreated during the upgrade. The thumbprints in
mongod.cfg and ProfileUnity.LicenseServer.exe.xml are updated automatically with the new values.
Step 6 â Rebuild the cluster
Once all nodes have been upgraded, re-enable HA mode and add the nodes back into the cluster. Refer to the Liquidware High Availability KB for the rebuild procedure: Enabling High Availability mode in 6.8.x for redundant processing of license requests
| Product | Liquidware ProfileUnity |
| Component | MongoDB / ProfileUnity Console |
| Applies To | MongoDB 7.0.26 and later |
| Updated | July 13, 2026 |