Why Your Apache Cipher Suite Probably Has RC4 in It

If your Apache SSL config is more than a few years old, there’s a good chance your Apache cipher suite has RC4 in it — still being advertised to every client that connects. Your site works fine — modern browsers just ignore RC4 and negotiate something better. But the cipher is still in your config, still being offered, and any security scanner will flag it. This is how to check and fix it.

What RC4 is and why it matters

RC4 is a stream cipher that was the backbone of SSL/TLS encryption for most of the internet through the 2000s. It was fast, simple to implement, and widely deployed. It was also quietly broken. By 2013 practical attacks against RC4 in TLS were documented. By 2015 IETF formally prohibited it in RFC 7465. Every major browser dropped support around the same time.

The problem is that Apache configs from that era look like this:

SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5

or worse, an explicit list:

SSLCipherSuite RC4-SHA:RC4-MD5:AES128-SHA:AES256-SHA

If you stood up your server before 2015 and never revisited SSL configuration, one of these is probably still in place. HIGH in OpenSSL’s cipher string notation includes RC4 unless you explicitly exclude it. MEDIUM includes it too.

How to check your Apache cipher suite for RC4

Find your active SSL cipher configuration:

grep -r "SSLCipherSuite|SSLProtocol" /etc/apache2/

You’re looking for any of these red flags:

RC4 appearing explicitly
HIGH:MEDIUM without !RC4
SSLProtocol all without disabling TLSv1 and TLSv1.1
SSLProtocol all -SSLv3 — this still allows TLS 1.0 and 1.1

You can also verify from outside using SSL Labs — run your domain through ssllabs.com/ssltest and look for RC4 in the cipher list, or anything below a B grade.

The fix

Replace your cipher suite with a modern allowlist. Put this in a shared include file that all your SSL virtual hosts reference:

SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder on
SSLSessionTickets off

This allows only TLS 1.2 and 1.3, only ECDHE and DHE key exchange (forward secrecy), and only AES-GCM and ChaCha20-Poly1305 symmetric ciphers. No RC4, no 3DES, no CBC-mode ciphers vulnerable to BEAST or Lucky13.

Test the config before reloading:

apache2ctl configtest && systemctl reload apache2

Why a shared include

If you have multiple SSL virtual hosts — one for the main site, one for a subdomain, one for an admin panel — you don’t want to maintain the cipher suite in each one. A single include file means you update it once:

# /etc/apache2/includes/options-ssl.conf
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:...
SSLHonorCipherOrder on
SSLSessionTickets off

Then in each virtual host:

<VirtualHost *:443>
    Include /etc/apache2/includes/options-ssl.conf
    # ... rest of vhost config
</VirtualHost>

Verify

After reloading, confirm RC4 is gone:

openssl s_client -connect yourdomain.com:443 -cipher RC4-SHA 2>&1 | grep -E "Cipher|alert"

You should see a handshake failure. If the connection succeeds, RC4 is still being accepted.

Run SSL Labs again — you should get an A or A+. If you’re still below that, the next things to check are HSTS headers and whether you have SSLUseStapling on configured.

The bigger point

SSL configuration is one of those things that was set up once, works forever, and never gets revisited. The web moved on from RC4 a decade ago. Your server config may not have. It takes ten minutes to check and another ten to fix — and it’s the kind of thing that shows up immediately if anyone ever runs a security audit on your infrastructure.