Hi Hiron,
Please find below the content for that PDF:
NSX OpenSSL Upgrade – NSX LB Impact & Remediation Guide
1. Overview & OpenSSL 3.0 Compliance Requirements
Starting with NSX 4.2, the underlying OpenSSL library upgrades to version 3.0 (with default security level 1 and FIPS enabled). This change introduces strict requirements for SSL certificates, cipher suites, and protocols. Non-compliant configurations block upgrades (Errors) or require validation (Warnings).
OpenSSL 3.0 Validation Criteria:
- Certificates: Minimum 2048-bit key size. SHA-1 and MD5 signatures are strictly forbidden.
- Cipher Suites: 3DES and ECDH- cipher suites are completely unsupported.
- SSL Protocols: SSLv3, TLS 1.0, and TLS 1.1 are unsupported. Only TLS 1.2 is supported for load balancing starting in NSX 4.2.
2. Pre-Check Results Analysis
Before running remediation commands, look up your pre-check logs on the NSX Manager where you initiated the process:
- File Path:
/var/log/upgrade-coordinator/lb-precheck-output.txt
Difference Between Error and Warning Cases:
- Error Case: The object contains ONLY unsupported configurations. The upgrade is BLOCKED until manually fixed.
- Warning Case: The object contains a mix of supported and unsupported configurations. The upgrade will NOT be blocked. The upgrade engine will automatically purge the non-compliant ciphers/protocols during migration.
3. Remediation Steps by Category
Categories 1 & 3: Policy / MP Cipher Suite & SSL Protocol Errors (Upgrade Blocked)
Scenario: Profiles or rules containing exclusively legacy protocols (TLS 1.0/1.1) or legacy ciphers (3DES).
- Step 1: Identify Impacted Profiles
Locate the profiles under the Category 1 or 3 headings in your lb-precheck-output.txt file.
- Step 2: Update via NSX Manager UI
- Navigate to Networking > Load Balancing > Profiles > Application Profiles (or SSL Profiles).
- Edit the failing Client/Server SSL Profile.
- Deselect non-compliant elements and enable TLS 1.2 and approved ciphers (e.g., AES-GCM).
- Step 3: Update via API (Alternative)
For Management Plane (MP) objects, issue a PUT request to /api/v1/loadbalancer/client-ssl-profiles/<profile-id> or /api/v1/loadbalancer/server-ssl-profiles/<profile-id> with an updated payload omitting the bad ciphers.
- Step 4: Client/Backend Validation
Ensure your physical clients and backend pool servers natively support TLS 1.2 before enforcing this change.
Categories 2 & 4: Policy / MP Cipher Suite & SSL Protocol Warnings (Informational)
Scenario: Profiles like default-balanced-client-ssl-profile that have both TLS 1.1 and TLS 1.2 active.
- Automatic Action: You do not have to change anything manually. The migration coordinator automatically strips TLS 1.1 out of the profile post-upgrade.
- Manual Verification:
- Confirm that your backend servers are ready to accept connections solely over TLS 1.2.
- Acknowledge the warning banner inside the Upgrade Coordinator interface to clear the prompt and click Proceed.
Special Case: default-https-lb-monitor
- By default, this system profile uses both TLS 1.1 and TLS 1.2.
- Action: No manual intervention is needed. The upgrade system automatically migrates it to TLS 1.2. However, verify your backend pool members do not rely strictly on TLS 1.1 to avoid traffic interruption.
Categories 5 & 6: Policy / MP SSL Certificate Errors (Upgrade Blocked)
Scenario: Virtual Servers or Monitors utilizing certificates with 1024-bit RSA keys or MD5/SHA-1 signatures.
- Step 1: Inspect the Certificate
If you need to verify why a certificate is flagged, run this command via SSH on the file:
openssl x509 -noout -text -in <certificate_pem_file>
Look closely at the Public-Key length (must be ≥ 2048) and the Signature Algorithm
- Step 2: Generate/Import a Compliant Certificate
Request a new certificate from your CA using a minimum of RSA 2048-bit (or 4096-bit) or ECDSA, signed via SHA-256 or higher.
- Step 3: Replace the Association
- Go to System > Certificates and import your new valid certificate.
- Navigate to Networking > Load Balancing > Virtual Servers.
- Edit the virtual server flagged in your pre-check report (
PolicyVSWithErrCert, etc.).
- Swop out the old
InvalidCert for your newly uploaded compliant certificate.
- Repeat this process for any flagged health monitors.
4. Post-Remediation Verification
- Do not make any further load balancer configuration adjustments once you re-initiate the final upgrade sequence.
- Return to the Upgrade Coordinator wizard in the NSX UI.
- Click Run Pre-Check again.
- Confirm that all Errors are completely cleared. Warnings can be acknowledged.
Regards,
------------------------------
Madalin Bejinaru
------------------------------