Issues Replacing Custom Certificate on 9443 on vCenter

[scjohnson]

I recently just replaced my vCenter server machine certificate, as well as the ESXi host certificates on each ESXi host with custom third-party signed CAs. However, for some reason, on the vCenter the 9443 certificate is showing as a self-signed certificate that was issued and expired on the same date. Is the certificate on 9443 different from those on 443, 5480, 636, etc? This is on a VCSA 6.7u3n.

Or alternatively, is there any way to simply disable the 9443 listening port? We do not use the flash client anymore, and I believe it is depreciated in 6.7. I'm not sure if there are any other relevant functionalities that require it listening though.

[Ank_S]

Hello,

1) Port 9443 is related to the deprecated flash client. Hence not used anymore.
2) Run the following command and verify the open ports on the VCSA :

    iptables -L port_filter -n –-line-numbers

If port 9443 is not open/listening , you can ignore the cert error , as it will not cause any issues.

PS: Mark kudos or correct answer as appropriate

[scjohnson]

This is more of a compliance exercise than an actual security exercise.  We're required to close all findings detected by Nessus, so I can't just ignore it. It's also definitely going to be listening, since I can hit https://url:9443 without any issues other than the new certificate warning.  It was previously flagging most of the ports like 443, 636, 5480, and 9443.  After I used the certificate manager to load in my certificate, I have it down to just 9443.  The problem is that it's both a self-signed certificate and it's also now "expired" since it is issued/expired on the same date. I basically either need to: 1) stop 9443 listening service, 2) block all traffic to 9443 on the device itself, or 3) install the certificate correctly for 9443.

I have no idea how that certificate got pushed to 9443.  I did attempt to install the certificates through the Web Client GUI, as that's how I created the CSR.  When that failed, I reverted to using the CLI Certificate Manager to replace the machine certificate.  Otherwise, I have no clue on what would have made this happen.

[scjohnson]

As an update to my own post, it appears that if I navigate to `https://hostname.com/vsphere-client/?csp`,  I will load the VMware vSphere Web Client page without any sort of certificate issues.  If I navigate to `https://hostname.com:9443/vsphere-client/?csp`,  I will get the same issue of a self-signed, expired certificate. Unfortunately, Nessus is still scanning 9443 explicility, so it's showing it as a finding even though it's not really normally going to be accessed.  I am perplexed and frustrated as to why it's pulling a random certificate when I specify the port.  I'm guessing it has to do with the reverse proxy, but I am not sure if I can go in there and just force it to somehow use the correct certificate.

My current workaround is to log into VAMI and disable the VMware vSphere Web Client service.  The issue is though that it's an automatic service, so it'll keep turning on.  It's also a bit of an ugly fix.