There are three categories of self-signed certificates in NSX.
- Platform Certificates
- NSX Services Certificates
- Principal Identity Certificates
Platform Certificates
After installing NSX, navigate to to view the platform certificates created by the system. By default these are self-signed X.509 RSA 2048/SHA256 certificates for internal communication within NSX and for external authentication when NSX Manager is accessed using APIs or the UI.
The internal certificates are not viewable or editable.
If VMware Cloud Foundation™ (VCF) was used to deploy NSX, the default NSX API and Cluster certificates get replaced with CA certificates signed by the VMware Certificate Authority (VMCA) from vCenter. The API and Cluster certificates might still display in the certificate list, but are not used. Replace the CA-signed certificates using the procedure in the VCF Administration Guide. After you perform the replacement, your NSX Manager stores in the UI contain the API and Cluster certificates, the VMCA CA certificates, and the signed certificates by the third-party organization. From then on, the NSX Manager uses the signed certificate from your organization.
| Naming Convention in NSX Manager | Purpose | Replaceable? | Default Validity |
|---|---|---|---|
| tomcat | This is an API certificate used for external communication with individual NSX Manager nodes through UI/API. | Yes. See Replace Certificates | 825 days |
| mp-cluster | This is an API certificate used for external communication with the NSX Manager cluster using the cluster VIP, through UI/API. | Yes. See Replace Certificates | 825 days |
| Additional certificates | Certificates specifically for NSX Federation. If you are not using NSX Federation, these certificate are not used. | See Certificates for NSX Federation for details on self-signed certificates auto-configured for NSX Federation. |
|
| Not visible in the UI | Certificates used for internal communication between different system components. | No | 10 years |
NSX Service Certificates
NSX service certificates are user-facing for services such as load balancer, VPN, and TLS Inspection. The policy API manages service certificates. Non-service certificates are used by the platform for tasks such as cluster management. The management pane (MP) or truststore APIs managed non-service certificates.
When adding service certificates using the policy API, the certificate is sent to the MP/truststore API, but not vice versa.
NSX service certificates cannot be self signed. You must import them. See Importing and Replacing Certificates for instructions.
You can generate a root certificate authority (CA) certificate and a private key based on RSA. CA certificates are able to sign other certificates.
A certificate signing request (CSR) can be used as an NSX service certificate if it is signed by a CA (local CA or public CA like Verisign). Once the CSR is signed, you can import that signed certificate into NSX Manager. A CSR can be generated on NSX Manager or outside of NSX Manager. Note that the Service Certificate flag is disabled for CSRs generated on NSX Manager. Therefore, these signed CSRs cannot be used as service certificates, but only as platform certificates.
Platform and NSX service certificates are stored separately within the system and certificates imported as NSX service certificate cannot be used for platform or the reverse.
Principal Identity (PI) Certificates
PI certificates can be for services or for platform.
PI for Cloud Management Platforms (CMP), such as Openstack, uses X.509 certificates that are uploaded when onboarding a CMP as a client. For information on assigning roles to Principal Identity and replacing PI certificates, see Add a Role Assignment or Principal Identity
PI for NSX Federation uses X.509 platform certificates for the Local Manager and Global Manager appliances. See Certificates for NSX Federation for details on self-signed certificates auto-configured for NSX Federation.
