Adding Chained Certificates to VMware NSX for vSphere 6.x Edge

Products

• VMware NSX

Issue/Introduction

This article provides steps for adding server certificates as chained certs.

Symptoms:

The certificate presented to the client has a broken certificate chain.

Environment

VMware NSX for vSphere 6.4.x
VMware NSX for vSphere 6.2.x
VMware NSX for vSphere 6.1.x
VMware NSX for vSphere 6.3.x
VMware NSX for vSphere 6.0.x

Resolution

When a certificate is presented to the client with its intermediary certificate, you need to take these precautions to import the server certificate as a chained cert.

If you import the certificate one by one as separate certs, the server cert is not chained. Only the Server cert by itself is presented to the client.

 

For example, if you have a server cert that is referencing an intermediary cert instead of a root/CA cert: If you import the Server and intermediary certs by themselves, to use the load balancer service on the NSX Edge, the client is presented with the Server cert alone, even though intermediate CA is configured as one of load balancer Virtual Server CA certificates.

The client is only able to verify the validity of the certificate if it has the intermediary certificate in its trusted cert store. If it does not have the intermediary certificate in its cert store, it may either have to be added, or the Server certificate should be chained with the intermediary certificate so that when the chained certificate is presented to the client, it is then able to verify the authenticity of the intermediary certificate using the root/CA certificate.

 

To import the server certificate as a certificate that is chained with the intermediary certificate on the NSX Edge:

1. Go to the Manage tab.
2. Navigate to Certificates.
3. Click the + icon.
4. Select Certificate.
5. In the Add Certificate window > Certificate Contents panel, paste the content of the server cert.pem file and then append the content of the .pem file of the intermediary certificate.
6. Both certificates should show up as in individual certificates in the User Interface (UI). However, the certificate details panel shows how the server cert is chained with its intermediary certificate.
7. If the server and intermediary certs were added one by one, the server cert does not show that it is chained.
   
   Notes:

• Once a certificate is imported for a CSR that was generated on an NSX Edge, it cannot be edited or replaced afterwards, and a new CSR will need to be generated and signed by the CA.
• The certificate field can contain multiple certificates if necessary to complete a chain back to a trusted CA certificate. Only the signed certificate matching the original CSR is required. Any other intermediate or CA certificates are optional. If a certificate chain is being added, the order must be:
  • First: the signed certificate for the CSR
  • Second: any intermediate CA certificates, in order of the chain from the CSR’s signed certificate to the root CA.
  • Each certificate should include the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines.
• A private key should NEVER be included in the certificate field. The only time a private key is ever pasted into the UI is when a complete certificate that was generated externally from the NSX Edge is being imported. In this case, the Add Certificate option is used. The private key is pasted into the Private Key field, and the Certificate contents, which will use the same format as importing a signed certificate for a CSR that was generated on the NSX Edge, including any intermediate and root CA certificates are pasted into the Certificate contents box. If the private key is encrypted, then the password to access it should be pasted in the password fields.

For example:

-----BEGIN CERTIFICATE-----
MIIFJjCCAw4CAQEwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMCRlIxEzARBgNV
BAgMClNvbWUtU3RhdGUxITAfBgNVBAoMGEludGVybmV0IFdpZGdpdHMgUHR5IEx0
[...]
LXCXtAo+3sEpo9cRpSNp/TeKplXr1DzyPnGgglOb8mLYD3XysDcQx1KmumcodyUH
I2Djr5KQtZfa7mxFuDPJgGdR+wSIv1MNkvPZG+o+F50PbFoHgU0eYcoDq6okwxss
zR23WrqkIYRxnOXYVHywy6Rw3yPQas9dpj4=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFgTCCA2mgAwIBAgIJAP0MXOQV1tJnMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNV
BAYTAkZSMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
[...]
cb9hsu6yNoUNCWw2uJErxVK1xqLIevA/CVLqiF3rBrJJrwKPiiRSn27ddVOJdjkQ
3rCRtHcMO+axQOB0dB/Vg3DX48X8
-----END CERTIFICATE-----

 

Key Points:

• Certificates used for SSL always contain 2 main components: a private key, which is never revealed and must be carefully protected, as its privacy is what ensure the security of the communication, and a public key. The public key is typically signed by a 3rd party, which ensure that the name on the key matches the key’s owner.
• The signed certificate contains the public key, plus additional metadata, such as the authorized names the key is used for, dates it is valid for, and the type of use the key is used for.
• The signed certificate is traceable to the signer of the certificate. This is normally a 3rd party CA.
  In order to be trusted, the CA’s root certificate must be pre-stored as a trusted key in the client’s key store. By default, browsers include the most common CAs.
• In some cases, the CA signs a public key with a sub-CA, or intermediate CA key. In these cases, there is a missing link between the signed key and the trusted key in the client’s key store. This is where an intermediate key must be provided to complete that chain. The 3rd party CA who signs the key should provide any intermediate keys required to complete the chain back to the majority of client endpoints to ensure end-to-end trust can be established.