The server accepts an obsolete cipher suite
In the reportServer accepts obsolete cipher suites (RC4 / 3DES / EXPORT / NULL)
tls_obsolete_cipher_accepted · Review item
This appears when your server completes a verified handshake that offers a fixed set of four obsolete cipher suites and negotiates one of them: an export-grade RC4 suite, an RC4 suite, a 3DES suite or a suite with no encryption. RFC 10015 lists all four among the cipher suites it deprecates. Remove obsolete suites from the server's cipher configuration.
Severity: Low.
Why it matters
RFC 10015 deprecates RSA key exchange in TLS 1.2 and lists the cipher suites it deprecates; the four suites tested here are in that list. A server that still accepts one of them can be made to use it by a client that offers nothing else.
What to do
- Look at the finding: it names the suite that was negotiated.
- Remove RC4, 3DES, export-grade and NULL suites from the cipher list of your server or CDN. Many hosts offer a modern TLS profile that does this.
- If an old client still needs one of these suites, plan its upgrade before you remove the suite.
When to leave it as it is: if the address is an internal or legacy endpoint that must stay compatible with an old client you control, you can leave it for now.
What we read
We resolve your site's HTTPS address once and make a small, fixed number of TLS handshakes to that one server address, six at most for all TLS checks together. No page is requested over them. An ordinary, certificate-verified handshake is made before and after, and both must succeed and agree.
One diagnostic handshake offers the complete fixed set: TLS_RSA_EXPORT_WITH_RC4_40_MD5, TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA and TLS_RSA_WITH_NULL_SHA256. A finding requires actual verified negotiation of a suite in this set. A qualified clean result requires refusal of this exact offer with the insufficient_security alert and matching verified controls. Separate local calibration checks whether the audit's TLS library can offer all four suites; those calibration handshakes are not extra requests to your site.
Example & evidence
Illustrative example — one audit, not a live result.
An audit makes its test handshakes to the server of bakery.example:
ordinary handshake TLS 1.2 negotiated, certificate verified
offer the complete four-suite set once TLS_RSA_WITH_3DES_EDE_CBC_SHA negotiated, certificate verified
ordinary handshake TLS 1.2 negotiated, certificate verifiedThe verified diagnostic handshake negotiated the 3DES suite, so the site is reported. A possible correction: the server refuses the same complete offer with the insufficient_security alert, between matching verified controls. An unspecified refusal does not prove the fix.
Confirm & check again
Check for yourself: read the cipher list in your server or CDN configuration and look for names containing RC4, 3DES, EXPORT or NULL.
Check again: Full audit — run a new audit of the site. Closure requires the same complete four-suite set to be offered in one diagnostic handshake and refused with the insufficient_security alert, with matching verified ordinary controls before and after. Missing calibration for any suite, a changed offer, any other alert or an incomplete control leaves the result unconfirmed.
Limits & sources
Only these four suites are offered. The check is a small sample, not a survey: a pass does not show that every weak suite is disabled.
A refusal with any other alert, including a general handshake failure, a timeout and a reset connection are left unconfirmed. If the audit's own TLS library cannot offer one of the suites, the check is recorded as not checked and is not run with a smaller list.
One server address is tested at one time from one location. A site served from several addresses, or through a CDN that answers differently elsewhere, can behave differently there.
Confidence: High because the finding rests on a handshake that was actually negotiated with the named suite, between two ordinary verified handshakes to the same server.
Sources
- IETF, RFC 10015: Deprecating Obsolete Key Exchange Methods in TLS 1.2 and DTLS 1.2 — deprecates RSA and finite-field Diffie-Hellman key exchange in TLS 1.2 and DTLS 1.2. Checked 14 October 2026.
- IETF, RFC 10015, section 5.4: RSA Cipher Suites Deprecated by This Document — lists the RSA cipher suites marked as deprecated in the IANA registry; the list includes
TLS_RSA_EXPORT_WITH_RC4_40_MD5,TLS_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHAandTLS_RSA_WITH_NULL_SHA256. Checked 14 October 2026. - IETF, The Transport Layer Security (TLS) Protocol Version 1.2, section 7.2.2 — defines the
protocol_versionalert as sent when the version the client tried to negotiate is recognized but not supported, andinsufficient_securityas returned when a negotiation fails specifically because the server requires ciphers more secure than those the client supports. Checked 14 October 2026.
Editorial review: 15 October 2026