Everything Monopam can do with a VMware vCenter appliance: read the certificate it serves today, put the issuing chain into its trusted roots, replace its machine SSL certificate, and confirm the result from the appliance itself rather than from the API's answer. Over the vSphere Automation REST API. No agent, no SSH, nothing installed on the appliance.
| How it connects | HTTPS to the management address, vSphere Automation REST API (/api/vcenter/certificate-management/...) |
|---|---|
| What it writes | The appliance's one machine SSL certificate, plus the issuing chain in its trusted roots |
| What it costs | A restart of vCenter's services. Plan a maintenance window |
| How success is decided | By the certificate the appliance serves afterwards, compared by thumbprint |
| Undo | Restore the previous certificate from the deployment's history |
Before you start
A vCenter appliance has exactly one machine SSL certificate. It is what the vSphere Client presents in a browser, what the API presents to scripts, and what ESXi hosts and integrations check. There is nothing to name on the target: no profile, no keyring, no virtual server. The address, the credential and the trust anchor are the whole configuration.
You need four things:
| What | Detail |
|---|---|
| A vCenter account | It needs the CertificateManagement.Administer privilege. [email protected] has it. Store it in the Monopam vault and pick it on the target |
| Network reach | Monopam's web process reaches the appliance directly on 443. Not through a gateway. The firewall rule belongs to Monopam's address |
| Name resolution | The address on the target must resolve from the Monopam host to the appliance. Where public DNS for that name points somewhere else, split DNS or a hosts entry has to cover it |
| A trust anchor | The self-signed root of whoever issued the certificate, in the Monopam inventory. Read the next section before you skip this one |
And one thing to schedule: replacing the certificate restarts vCenter's services. VMware's guidance is ten to twenty minutes out of service. Everything that talks to the appliance reconnects afterwards.
The trust anchor, and why a valid certificate is refused without it
This is the one step that catches people, and the appliance is no help at all when it does.
vCenter validates the chain you hand it with Java's PKIX, which will not start without a trust anchor: a certificate that signed itself. A certificate from a public authority never carries one, and that is not a mistake. The ACME protocol deliberately does not send the root, because the client is expected to trust it already. So the chain stops at an intermediate.
It gets one step worse while an authority is rotating its roots. The last certificate in the chain is then a cross-signed copy of the new root: it is a certificate authority, and its subject is its own name, so it looks exactly like a root. It is not one. It was issued by the old root, so PKIX cannot anchor on it either.
A worked example. A Let's Encrypt certificate issued in late 2026 arrives with the chain leaf → YR2 → Root YR. Root YR is an ISRG root, and it is a certificate authority that names itself, so the chain looks complete. It is signed by ISRG Root X1, which is not in the chain, so there is no anchor. vCenter refuses the certificate and says only the trustAnchors parameter must be non-empty.
The fix is to tell the target which root to send. Import the authority's self-signed root into the Monopam inventory once (Certificates → Import), then pick it in the target's Trust anchor field. Monopam appends it to the chain, puts it in the appliance's trusted roots with the rest, and sends it with the certificate.
The picker offers only certificates that can actually do the job: certificate authorities in the inventory whose subject and issuer are the same. A cross-signed intermediate is deliberately not offered, because picking one would land you back on the same unexplained error.
If the chain has no anchor and none is picked, Monopam refuses before touching the appliance and names the certificate that is missing:
The issuing chain ends at "Root YR", which is itself issued by "ISRG Root X1", so the chain carries no self-signed root. vCenter cannot validate a chain without one. Import that root into Monopam and pick it as the target's trust anchor.
A certificate from your own internal authority usually needs nothing here: an internal chain normally does carry its self-signed root. Leave the field on None and Monopam will tell you if it was wrong.
Create the deployment target
Open the certificate in Certificates, go to its Deployments tab and choose Add Target. Set Server Type to VMware vCenter.
| Field | What to put in it |
|---|---|
| Management host, or Appliance Resource | The appliance address, for example vcenter.monofor.com. Picking a registered Appliance resource instead means its address is the one source of truth and changing it there moves every target that points at it |
| Management credential | The vCenter account. A vault credential is preferred over typing it on the target |
| Management port | 443 unless your appliance is somewhere else |
| Add the issuing chain to vCenter's trusted roots first | Leave it on. vCenter refuses a certificate whose chain it does not trust, and adding a chain that is already there changes nothing |
| Trust anchor (root certificate) | The authority's self-signed root. See the section above |
| This vCenter is 7.0 | Leave it off for vCenter 8.0, which takes the request body flat. Turn it on only if a deployment is refused with a body error: 7.0 expects the body wrapped |
| Automatically deploy when the certificate renews | Leave it off. See Renewal |
Deploy
Press Deploy on the target. Where a certificate approval policy covers the operation, the request goes to its approvers first and Monopam carries it out when they approve.
What then happens, in order:
- Monopam signs in to the appliance and reads the certificate it serves today, both for the record and so the deployment can be undone.
- If the appliance already serves this exact certificate, the run stops there and reports success. Nothing is changed and nothing restarts, so a re-run is always safe.
- Each certificate in the chain, including your trust anchor, goes into the appliance's trusted roots. One already there is not an error.
- The certificate and its private key are installed. vCenter restarts its services while answering this call, so the call often does not answer at all.
- Monopam then asks the appliance, over and over for up to twenty-five minutes, what certificate it serves on its TLS port, and reports success only once that is the thumbprint it deployed.
The appliance is believed, not the API. vCenter installs the certificate first and tells its other services about it afterwards, so a call that reports a failure may describe a change that is already live. Monopam therefore checks what the appliance serves before reporting any error from that step. This is also why the run can take much longer than the call did.
After the deployment: check port 5480
The appliance management interface on port 5480 is a separate service, and vCenter is the one that tells it about the new certificate. That internal notification can fail, usually because the service is itself restarting at that moment. The machine SSL certificate is replaced either way, and the deployment says so:
Installed on vCenter at vcenter.monofor.com and confirmed (...), but vCenter reported a problem while telling its other services about the change. Ports other than 443 (the appliance management interface on 5480) can still be serving the old certificate. vCenter said: ... Failed to notify APPLMGMT ...
Check both ports:
echo | openssl s_client -connect vcenter.monofor.com:443 -servername vcenter.monofor.com 2>/dev/null | openssl x509 -noout -subject -issuer -fingerprint echo | openssl s_client -connect vcenter.monofor.com:5480 -servername vcenter.monofor.com 2>/dev/null | openssl x509 -noout -fingerprint
If 5480 still shows the old thumbprint, restart the appliance management service on vCenter:
POST https://vcenter.monofor.com/api/vcenter/services/applmgmt?action=restart
That call answers with a gateway error, which is expected rather than a failure: the service handling the request is the one being restarted. Give it a minute and check 5480 again.
With a publicly issued certificate you can also check that it validates against the system trust store, with no -k anywhere:
curl -sS -o /dev/null -w "%{http_code} ssl_verify=%{ssl_verify_result}
" https://vcenter.monofor.com/ui/
200 ssl_verify=0 means the chain you deployed is complete and trusted as it stands.
Renewal
Automatically deploy when the certificate renews is off by default on this target type, and we recommend leaving it off.
Every deployment restarts the appliance's services. A certificate from a public authority is short-lived, ninety days for Let's Encrypt, so switching automatic deployment on commits the appliance to an unattended service restart four times a year, at whatever hour the renewal happens to land. Let the expiry alert tell you the renewal has happened, and run the deployment in a window you chose.
An internal certificate with a one or two year life is a different trade, and automatic deployment is more reasonable there. It is still a restart.
Undo
Each deployment records the certificate the appliance served before it. In Certificates → Deployments, open the run and choose Restore previous certificate. Monopam deploys that certificate back, which costs a second service restart.
There is no "remove what was deployed" for this type. An appliance has to serve something on 443, so the only meaningful undo is putting the previous certificate back.
If something goes wrong
| What you see | What it means | What to do |
|---|---|---|
the trustAnchors parameter must be non-empty | The chain reaches no self-signed root. vCenter names nothing else | Import the authority's root and pick it as the target's trust anchor |
The issuing chain ends at "..." which is itself issued by "..." | Monopam caught the same thing before touching the appliance | Import the named certificate and pick it as the trust anchor |
Failed to notify APPLMGMT ... | The certificate is installed. The appliance management service did not hear about it | Restart applmgmt on the appliance, then check 5480 |
vCenter refused the management credential | The account lacks CertificateManagement.Administer | Use an account that has it |
This certificate has no private key | The inventory holds the certificate but not its key | Import it again with its key file |
vCenter config could not be read | The target's stored settings will not decrypt or parse | Open the target, check the fields and save it again |
| Refused with a body error on vCenter 7.0 | 7.0 expects the request body wrapped | Turn on This vCenter is 7.0 and deploy again |
| The run waits and then says the appliance has not come back | vCenter is still restarting, or it is not serving the new certificate | Check the appliance. A restart can take longer on a busy system and the certificate may still land; check the thumbprint on 443 before deploying again |
What Monopam does not do here
- Replace the VMCA root, solution-user certificates or ESXi host certificates. Only the appliance's machine SSL certificate.
- Push the certificate to port 5480. vCenter does that itself, and the section above covers it when that fails.
- Offer Test connection. That test opens a session on a host, which an appliance target does not have. A vCenter target is verified by deploying.
- Reach the appliance through a gateway. Appliance targets are called from the Monopam web process.