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.
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:
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 1.2 (ECDHE only):
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.
VERIFICATION
After saving the TLS context changes, re-run the SSL Labs test (allow a few minutes for propagation). Expected results after the fix:
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>
005385528

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.