When you attempt to replace the NSX Manager certificate with a configured Microsoft CA Certificate from Fleet Management > Certificates > VCF Instances, select the SDDC Manager > click the ellipses > Replace With Configured CA Certificate) in VCF 9.0.2, you experience a significant delay. The task takes approximately 95 minutes to complete and the SDDC Manager certificate type properly shows as updated from VMCA to Microsoft CA
SDDC Manager and NSX Manager log bundles show the certificate successfully imports into the NSX database when triggered by SDDC Manager. However, SDDC Manager experiences a delay in receiving the success status while waiting for service restarts and background sync operations.
In the NSX syslog, you see the certificate imports successfully right away:
2026-03-17T19:58:51.621Z [NSX_FQDN] NSX 5908 SYSTEM [nsx@4413 comp="nsx-manager" level="INFO" reqId="[GUID]" subcomp="manager" username: "[SDDC_SERVICE_ACCT]" Successfully added certificate [GUID]
2026-03-17T19:58:51.633Z [NSX_FQDN] NSX 5908 SYSTEM [nsx@4413 audit="true" comp="nsx-manager" level="INFO" reqId="[GUID]" request="POST /api/v1/trust-management/csrs/[GUID]?action=import" subcomp="manager" update="true" username="[SDDC_SERVICE_ACCT]" UserName="[SDDC_SERVICE_ACCT]" , Src="##.##.##.##", ModuleName="CertificateManager", Operation="ImportCertificate", Operation status="success"...
In the SDDC Manager operationsmanager.log, you see the 95-minute gap between the operation starting and completing:
2026-03-17T19:58:51.191+0000 DEBUG [vcf_om,####-###-####-#####,####] [c.v.v.c.s.f.i.CertificateOperationsFacadeImpl,http-nio-###.#.#.#-7300-exec-1] DomainCertificateOperation: {"workflowId":"[GUID]","domainName":"[DOMAIN]","operationType":"REPLACE_CERTIFICATE","operationStatus":"*****","resourceCertificateOperations":[{"resource":{"hostName":"[NSX_HOSTNAME]","resourceType":"nsxt_manager","master":false},"result":{"status":"PENDING"}...
2026-03-17T21:34:41.399+0000 INFO [vcf_om,####-###-####-#####,####] [c.v.v.c.n.NsxTManagerCertificatePlugin,om-exec-15] Certificate replacement completed
You might also see the Certificate Replacement task in vSphere Client appear hung at 0% and also later show completed after a long delay.
VCF Operations 9.0.2
NSX 9.0.2
The delay is due to an unidentified process locking the NSX database for an extended period. These errors and database locks occur during the task window of the certificate replacement. This database lock causes multiple processes, including the upgrade-coordinator status check and certificate synchronization tasks, to hang in a waiting or parked state, delaying the completion of the certificate replacement.
Hanging threads and queue lock errors are visible when reviewing the NSX logs. Hundreds of these types of messages occur, indicating that threads are stuck waiting on conditions:
"Log4j2-TF-5-Scheduled-2" #23 daemon prio=5 os_prio=0 cpu=4179.55ms elapsed=2934828.54s tid=0x000015db0cc17ef0 nid=0xf00 waiting on condition [0x0000773161150000]
java.lang.Thread.State: TIMED_WAITING (parking)
at [HOSTNAME]([email protected]/Native Method)
- parking to wait for <0x00007731b0eebb70> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)"Wrapper-Control-Event-Monitor" #16 daemon prio=5 os_prio=0 cpu=517288.65ms elapsed=2934830.11s
tid=0x00007731d8507be0 nid=0xe6b waiting on condition [0x000077316215a000]
java.lang.Thread.State: TIMED_WAITING (sleeping)Allow the "Replace with Configured CA Certificate" task to run. The task may complete successfully after the background sync operations finish and the database locks clear
If this delay or similar database lock issues persist in the future, you must open a new support case with the NSX team to investigate the health and performance of the NSX Manager.
A dedicated NSX health check is required because the database lock is an underlying performance or race condition issue within the NSX appliance itself.