Cannot apply CA-signed certificate to NSX Manager

Products

• VMware NSX

Issue/Introduction

• You intend to replace an NSX certificate with a CA-signed certificate (for example, because the browser indicates the site is not secure).
• A non-expired CA-signed certificate has been uploaded to NSX and is listed as Valid.
  
• The certificate cannot be applied to an NSX Manager using the API.

  POST https://<manager-ip>/api/v1/trust-management/certificates/<cert-id>?action=apply_certificate&service_type=API&node_id=<node-id>

  Returns:

  {
  
      "httpStatus": "BAD_REQUEST",
      "error_code": 2078,
      "module_name": "internal-framework",
      "error_message": "Certificate validation failed. Please use /api/v1/trust-management/certificates/<cert-id>?action=validate&usage=SERVER API to check the validation errors."
  
  }

• The certificate cannot be validated using the API.

  GET https://<manager-ip>/api/v1/trust-management/certificates/<cert-id>?action=validate

  Returns:

  {
      "status": "REJECTED",
      "error_message": "Certificate was rejected: null"
  }

• Using the following API call to the NSX manager, we see CRL checking is enabled:
  

  GET https://<manager>/api/v1/global-configs/SecurityGlobalConfig

  Result:
  

  ...
  
  "crl_checking_enabled": true,
  
  ...

Environment

• VMware NSX-T Data Center 3.x
• VMware NSX 4.x

Cause

Certificate Revocation List (CRL) validation is enabled and the provided certificate has CRLs that cannot be validated.

Common Causes for CRL Validation Failure

• Inability to Access the CRL Distribution Point (CDP):
  • The system performing the validation (client, server, or application) cannot reach the URL specified in the certificate for the CRL. This is a common issue and can be caused by firewall settings, network connectivity problems, or incorrect proxy settings (e.g., WinHTTP proxy settings) that prevent access to the required CRL or Online Certificate Status Protocol (OCSP) URLs.
  • If a Certificate Authority (CA) lists multiple CDP entries, and the first one is unreachable, the system may not check the remaining distribution points.
    
     
• Expired or Unavailable CRL:
  • The downloaded CRL itself has an expired NextUpdate date, meaning it is no longer considered valid.
  • The server hosting the CRL Distribution Point might be down, making the CRL unavailable for download.
    
    
• CRL File Issues:
  • The CRL file is not signed by the issuing CA, which will lead to a cryptography error.
  • The CRL file size exceeds the maximum limit allowed by the validating system (e.g., for certain cloud services like Microsoft Entra ID).
  • In some cases, the CRL may be placed in a location the web server cannot read, leading the server to serve an old, expired version.
    
     
• Access/Permission Issues:
  • If the CRL is hosted in a directory service like Active Directory (using an LDAP CDP), the validating client may lack the necessary permissions to read the CRL from the domain.
    
     
• Configuration Errors:
  • The CRL Distribution Point is an invalid or inaccessible URL (e.g., not internet-facing when it needs to be).

Resolution

Workaround options:

1. Disable CRL checking.  NSX will no longer validate CRL Distribution Points if they are present in certificates.
   
   Capture the current configuration via API:
   

   GET https://{{ip}}/policy/api/v1/infra/security-global-config
   

   This will provide a JSON response like the following:
   

   {
       "crl_checking_enabled": true, 
       "ca_signed_only": false, 
       "eku_checking_enabled": true, 
       "id": "########-####-####-####-###########", 
       "_create_time": 1679339007871, 
       "_create_user": "system", 
       "_last_modified_time": 1679339007871, 
       "_last_modified_user": "system", 
       "_protection": "NOT_PROTECTED", 
       "_revision": 0 
   }

   Modify the JSON response, changing the value of crl_checking_enabled to false, e.g.:

   {
       "crl_checking_enabled": false
       ...
   }

   Use the API to submit the modified JSON response:
   

   PUT https://{{ip}}/policy/api/v1/infra/security-global-config

2. Deploy a new CA-signed certificate without X509v3 CRL Distribution Points enabled.  In this case, NSX will have no CRL URIs to verify.
3. Deploy a new CA-signed certificate with valid HTTP(S) addresses as the CRL Distribution Points.  This is the most correct workaround from a certificate compliance perspective. 

   crlDistributionPoints=URI:http://example.com/crl.pem

   The URLs will be validated by the NSX Manager.  
   To see if the URI is valid and reachable from the NSX Manager, login to the manager as the root user and execute:

   wget <cdp-link>