Replace NSX-T 3 SSL/TLS Certificates – Common errors

• Tweet it
• Pin it
• Share it
• Email

This is the fourth post out of a small series about replacing NSX-T SSL / TLS Certificates:

1. Replace NSX-T 3 SSL / TLS Certificates – GUI MethodReplace
2. Replace NSX-T 3 SSL / TLS Certificates – Manual Method
3. Replace NSX-T 3 SSL / TLS Certificates – Cluster Certificate
4. –> Replace NSX-T 3 SSL / TLS Certificates – Common errors

While describing how to replace the NSX-T Manager and Cluster Certs both, through the GUI and manually, I’ve faced a few of errors. Since those error messages are not always entirely clear, I wanted to share some of my findings with you.

1. Certificate validation failed. Reason : Certificate is not compliant as certificate of type SERVER: Basic constraints Extension is not present in the certificate

After running the command to actually change the certificate, you get a message, similar to:

{
  "error_code": 36432,
  "error_message": "Certificate validation failed. Reason : Certificate is not compliant as certificate of type SERVER: Basic constraints Extension is not present in the certificate",
  "module_name": "node-services"
}

This means, that your Certificate does not have the Extension “Basic constraints” available / enabled.
In case of a Windows based Certificate Authority, check your Certificate Template Settings. Make sure you have the extension “Basic Constraints” available and Enabled. In order to have this extension available, your compatibility settings must be Windows Server 2008 R2 (or newer).

• 

  https://vraccoon.com/2020/05/replace-nsx-t-3-ssl-tls-certificates-common-errors/#MS1iYXNpYy1jb25

2. Certificate validation failed. Reason : Certificate <certificate attributes>: certificate does not verify with supplied key

After running the command to actually change the certificate, you get a message, similar to:

{
  "error_code": 36432,
  "error_message": "Certificate validation failed. Reason : Certificate CN=nsxt-3.vraccoon.lab,OU=Lab,O=vRaccoon Corp,L=Germany,ST=BER,C=DE was not verifiably signed by CN=nsxt-3.vraccoon.lab,OU=Lab,O=vRaccoon Corp,L=Germany,ST=BER,C=DE: certificate does not verify with supplied key",
  "module_name": "node-services"
}

This is a good example of a non-intuitive error description. When you upload the Certificate (not matter whether through the GUI-Method or the Manual-Method) it already checks if the certificate and the key fit together.
If you get this error message after trying to activate the already uploaded certificate, it most likely means, that you haven’t uploaded the complete certificate chain as part of your NSX-T Certificate.
If you upload your certificate file, it must look similar to

—–BEGIN CERTIFICATE—–
NSX-T Manager cert
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
Intermediate CA Cert
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
Root CA Cert
—–END CERTIFICATE—–

3. Certificate validation failed. Reason : Certificate was rejected: CRL check failed: Couldn’t get LDAP context from URI ldap:///<CRL path>”

After running the command to actually change the certificate, you get a message, similar to:

{
  "error_code": 36432,
  "error_message": "Certificate validation failed. Reason : Certificate was rejected: CRL check failed: Couldn't get LDAP context from URI ldap:///CN=vraccoon-DC-CA,CN=dc,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=vraccoon,DC=lab?certificateRevocationList?base?objectClass=cRLDistributionPoint",
  "module_name": "node-services"
}

This is a tricky one. And a known Issue too – check KB78794
With NSX-T 3, VMware has added a check for Certificate Revocation List (CRL). From a security perspective, it’s quite a good move.

To fix this, VMware recommends the use of HTTP CDP based Certificates.
Alternatively, as a workaround, you can also disable the CRL check – run the following command (fill the <> with your information:

curl –insecure -u <user>:<password> -X GET “https://<manager-fqdn>/api/v1/global-configs/SecurityGlobalConfig”

You will get an response, similar to this:

{
  "crl_checking_enabled" : true,
  "ca_signed_only" : false,
  "resource_type" : "SecurityGlobalConfig",
  "id" : "750efc5c-42d4-455e-b167-3497ba3ce879",
  "display_name" : "750efc5c-42d4-455e-b167-3497ba3ce879",
  "_create_user" : "system",
  "_create_time" : 1590267915849,
  "_last_modified_user" : "system",
  "_last_modified_time" : 1590330655250,
  "_system_owned" : false,
  "_protection" : "NOT_PROTECTED",
  "_revision" : 7
}

You will need lines 2, 3 and 13. Then run the following command (again, customized to your environment):

curl –insecure -u <user>:<password> -X PUT “https://<manager-fqdn>/api/v1/global-configs/SecurityGlobalConfig” -H “Content-Type: application/json” -d ‘{“crl_checking_enabled”:false, “resource_type” : “SecurityGlobalConfig”,”_revision” : <revision number>}’

If it succeeds, you will get the previous output again, but with an incremented revision number and crl_checking_enabled set to false.

4. error, no objects specified in config file

When trying to create the key and csr file with openssl, you’ll get an error similar to:

vraccoon@ubu:/tmp$ openssl req -nodes -newkey rsa:2048 -keyout nsxt-3.key -config nsxt-3.cnf -out nsxt-3.csr
Generating a RSA private key
...................................................................+++++
.............................................................................................................................................................+++++
writing new private key to 'nsxt-3.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
DE []:
Germany []:
BER []:
vRaccoon Corp []:
LAB []:
nsxt-3.vraccoon.lab []:
error, no objects specified in config file
problems making Certificate Request

I’m not sure where this exactly comes from, it appears to me like an issue in openssl.
But you can easyly fix this by adding “prompt = no” to the section [req] in your certificate conf file. Of course, you need to specify the desired values in the conf file too, since its not asking for it anymore.