OpenSSL able to negotiate a cipher that isn’t supported

apache-2.2openssl

We have to be a little limited with out cipher selection for various reasons, and one of the ciphers we can't use is AES256-GCM-SHA384.

We can prove that that cipher is available with this command:

$ openssl s_client -cipher AES256-GCM-SHA384 -connect hostname:443

…which works fine on Centos 6.6, OpenSSL 1.0.1e-fips 11 Feb 2013. It connects and displays:

New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384

It doesn't work from my Mac (OpenSSL 0.9.8zd 8 Jan 2015) or from the server itself (OpenSSL 1.0.1m 19 Mar 2015 (Library: OpenSSL 1.0.0d 8 Feb 2011)), in both cases returning a message like:

38200:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher
match:/SourceCache/OpenSSL098/OpenSSL098-52.20.2/src/ssl/ssl_lib.c:1223

That the connection from Centos works is confusing to me, because running this on the (Solaris) server:

$ openssl ciphers | sed "s/:/\\n/g" | grep -i gcm

…produces an empty list, as though GCM ciphers don't exist. The same command on the Centos install lists a handful of selections.

The Apache instance is using the copy of OpenSSL that I'm looking at and not some other random one.

I suspect that I'm missing a key point. Does anyone have an idea of what might be going on?

Best Answer

You likely have two OpenSSL installations on your CentOS server.

Run the command ldd /usr/local/apache/modules/mod_ssl.so using the path to mod_ssl.so defined in your httpd.conf. This will return the libraries linked to mod_ssl.so. Are they using the same libraries as your system OpenSSL?

My guess is that your Apache is configured to use a different OpenSSL than the default system OpenSSL. This is why Apache can accept the AES256-GCM-SHA384 cipher, but your use of the system openssl command fails. Often times installations or upgrades of OpenSSL performed after the OS installation will get installed to /usr/local/ssl with the library folder at /usr/local/ssl/lib.

Related Topic