Loading

CloudHub 2.0 Private Space - SSL Labs Low Grade Due to Weak Cipher Suites and Root Certificate in Chain

Publish Date: May 26, 2026
Prerequisite(s)
CloudHub 2.0 Private Space, Public Certificate, Intermediate CA Path Certificate
Task

Customers may see that their CloudHub 2.0 Private Space domain receives a Grade B (or lower) on SSL Labs (ssllabs.com/ssltest) while expecting to receive Grade A. This article covers the two most common causes and how to resolve them.


Steps

There are two independent issues that can each cause a Grade B, and they often appear together.

CAUSE 1 - ROOT CA INCLUDED IN THE CERTIFICATE CHAIN

The root CA certificate is being sent by the server during the TLS handshake. Root CAs are already embedded in browser and OS trust stores. Including them in the served chain is unnecessary and triggers the "Contains anchor" warning in SSL Labs.

To confirm: Run the following command and check if depth=2 appears in the output:

openssl s_client -connect <your-domain>:443 -servername <your-domain> 2>/dev/null | grep depth

If depth=2 is present, the root CA is being served.

CAUSE 2 - WEAK CIPHER SUITE ENABLED

The TLS context has the cipher TLS_RSA_WITH_AES_128_GCM_SHA256 or other weak ciphers enabled. 
SSL Labs penalizes servers that expose non-FS ciphers to reference browsers (IE 11, older Edge) and caps the grade at B regardless of other settings.

Note: Different private spaces may have different cipher suites enabled depending on how the TLS context was originally created or migrated. This explains why the same certificate can produce different grades across regions.

To confirm: Run the following command. If the handshake succeeds, the weak cipher is active:

openssl s_client -connect <your-domain>:443 -servername <your-domain> -cipher AES128-GCM-SHA256 -tls1_2

If the result is "handshake failure", the weak cipher is already disabled.

RESOLUTION

STEP 1 - FIX THE CERTIFICATE CHAIN

In the Private Space TLS context (Anypoint > Runtime Manager > Private Spaces > Domain/TLS > Edit TLS Context), configure the fields as follows:

  • Public Certificate: upload the leaf/server certificate only (the certificate issued directly to the customer domain).
  • CA Path Certificate (Optional): upload the intermediate certificate only. Do NOT include the root CA certificate in this file.

Reference KB: How to fix "must not have more than 4096 characters" error when creating TLS Context: https://help.salesforce.com/s/articleView?id=001119621&type=1

STEP 2 - REMOVE WEAK CIPHER SUITES

In the TLS context configuration, review the list of enabled cipher suites and deselect any RSA key exchange ciphers (non-ECDHE). Retain only Forward Secrecy-capable suites. For modern deployments, one example suggestion would be:

TLS 1.3 (all three default suites support FS):

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256

TLS 1.2 (ECDHE only):

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

SIDE EFFECTS

Removing weak RSA ciphers will cause handshake failures for old clients that only support RSA key exchange with no Forward Secrecy (IE 11 on Windows 7/8.1, Safari 8, very old mobile browsers). Confirm with your users that they do not have a business requirement to support these clients before making the change.




Additional Resources

VERIFICATION

After saving the TLS context changes, re-run the SSL Labs test (allow a few minutes for propagation). Expected results after the fix:

  • Overall Rating: A
  • Chain issues: None
  • Forward Secrecy: Yes (with most browsers) - ROBUST
  • Certificates provided: 2 (leaf + intermediate only)

Also verify via CLI:

openssl s_client -connect <your-domain>:443 -servername <your-domain> 2>/dev/null | grep depth

Expected output (no depth=2): depth=1 <Intermediate CA> depth=0 <Leaf cert / customer domain>

Knowledge Article Number

005385528

 
Loading
Salesforce Help | Article