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 tomod_ssl.so
defined in yourhttpd.conf
. This will return the libraries linked tomod_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 systemopenssl
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
.