VMware Cloud Community
Mark_Z900
Contributor
Contributor

How to change the SSL Cert on vCenter Server Appliance Manager portal (https://fqdn:5480)?

I implemented the "Replacing vSphere 6.0 certificates using VMCA as a Subordinate CA" procedure, and most all of the certificates now reflect "valid" with our Windows CA chain, except the web portal to the Appliance Manager (ala- https://fqdn:5480). This certificate remains self-signed, and IE/Chrome don't allow exceptions (Firefox does).

So how does one get this certificate replaced with VMCA (or a Windows CA) issued certificate?

Tags (2)
8 Replies
vijayrana968
Virtuoso
Virtuoso

This is known issue. Since you have replaced SSL certificates at vSphere level, you have to restart VAMI service to reflect changes on VCSA itself. Log in to the vCenter Server Appliance through SSH and then execute /etc/init.d/vami-lighttp restart

login to VCSA management interface with fresh browser session and check if it works.

Reply
0 Kudos
Mark_Z900
Contributor
Contributor

Thanks for the tip. Restarting the vami-lighttp service did allow the  new VMCA  issued certificate to become active. But the new certificate fails IE/Chrome test (on :5480). The "same" certificate tests fine via https:// or https://fqdn/psc I say same certificate because both web portals show the same thumbprint for the certificate. Pretty interesting situation......

vijayrana968
Virtuoso
Virtuoso

You mean this still displaying warning ⚠️ or error on https://VCSA:5480 ? Has this certificate been trusted on client certificates Store !

Reply
0 Kudos
Mark_Z900
Contributor
Contributor

Yes, the certificate is a accepted Windows CA "chained" certificate. By that I mean when the IE or Chrome browser accesses http://fqdn or https://fqdn/psc, there is no reported issues. Examining the certificate from the browser shows a "valid" certificate, and the certificate path extends up to my domain CA root certificate.

When I access the https://fqdn:5480 portal, IE/Chrome refuses, Firefox allows an exception. IE reports:

The security certificate presented by this website was not issued by a trusted certificate authority.


Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.

The certificate thumprint matches, so this is the same certificate used on all 3 web portals....

Reply
0 Kudos
JeffreyRusso
Contributor
Contributor

I had the same issue and this fixed it for me.  I am running 6.5.

VMware Knowledge Base

vCenter Server Appliance 6.5:

  1. Log in to the vCenter Server Appliance through SSH.
  2. Type shell and press Enter.
  3. Copy CA cert chain to:

    /etc/applmgmt/appliance/ca.crt
  4. Open the /opt/vmware/etc/lighttpd/lighttpd.conf file using a text editor:
  5. Add the entry:

    ssl.ca-file="/etc/applmgmt/appliance/ca.crt"
  6. Restart the VAMI service:

    /etc/init.d/vami-lighttp restart
joebb1017
Contributor
Contributor

Sorry to bump. Where do you find the CA Cert chain? I am having the same issue, and my cert is a .cer

Reply
0 Kudos
vijayrana968
Virtuoso
Virtuoso

Yes, this is known issue. If certificate is reflecting on web client for vCenter and PSC but not on vami interface, port 5480. Restart vami service

/etc/init.d/vami-lighttp restart

Reply
0 Kudos
danquist
Contributor
Contributor

Oh my god I've been banging my head trying to figure out what I was doing wrong for two days.

Just like the OP I had reconfigured the vSphere CA to be an intermediate of my internal root CA and regenerated the SSL certificates. Everything was working *except* for the Appliance Manager portal on port 5480. What made it most confusing is that the correct certificate was being sent, but the browsers wouldn't verify it.

The reason the browser won't trust the certificate is that the full certificate chain isn't being sent from the server, only the end certificate is being sent. Unless you've manually installed the vSphere intermediate certificate as a trusted root, your browser has no knowledge of the intermediate certificate and fails to verify.

JeffreyRusso​'s answer hit the nail on the head. The fix is to configure the http-light server to send the full certificate chain, specifically the intermediate certificate. ca.crt should contain the base-64 encoded vSphere intermediate certificate, and once http-light is reconfigured then the browser can finally verify the full certificate chain.

Reply
0 Kudos