Based on the date displayed by your version of OpenSSL, it seems you are seeing the full version displayed there.
Open SSL 1.0.1 was released on March 14th, 2012. 1.0.1a was released on April 19th of 2012.
So, I'm going to go ahead and assert that openssl version -a is the proper, cross-distro way to display the full version of OpenSSL that's installed on the system. It seems to work for all the Linux distros I have access to, and is the method suggested in the help.ubuntu.com OpenSSL documentation, as well. Ubuntu LTS 12.04 shipped with vanilla OpenSSL v1.0.1, which is the version that looks like an abbreviated version, on account of not having a letter following it.
Having said that, it appears that there is a major bug in Ubuntu (or how they package OpenSSL), in that openssl version -a continues to return the original 1.0.1 version from March 14, 2012, regardless of whether or not OpenSSL has been upgraded to any of the newer versions. And, as with most things when it rains, it pours.
Ubuntu is not the only major distro in the habit of backporting updates into OpenSSL (or other packages), rater than relying on the upstream updates and version numbering that everyone recognizes. In the case of OpenSSL, where the letter version numbers represent only bug fix and security updates, this seems nearly incomprehensible, but I have been informed that this may be because of the FIPS-validated plugin major Linux distros ship packaged with OpenSSL. Because of requirements around revalidation that trigger due to any change, even changes that plug security holes, it is version-locked.
For example, on Debian, the fixed version displays a version number of 1.0.1e-2+deb7u5 instead of the upstream version of 1.0.1g.
As a result, at this time, there is no reliable, portable way to check SSL versions across Linux distributions, because they all use their own backported patches and updates with different version numbering schemes. You will have to look up the fixed version number for each different distribution of Linux you run, and check the installed OpenSSL version against that distribution's specific version numbering to determine if your servers are running a vulnerable version or not.
As per my answer on StackOverflow:
Will likely be one of two reasons:
You are using anti-virus software and it is MITM your traffic and so downgrading you to HTTP/1.1. Turn off https traffic monitoring on your AV to connect directly to the server.
You are using older TLS ciphers and specifically one that Chrome disallows for HTTP/2 (https://http2.github.io/http2-spec/#BadCipherSuites) as per Step 5 of above guide. Scan your site using https://www.ssllabs.com/ssltest/ to check your TLS config and improve it.
The third reason is lack of ALPN support in your SSL/TLS library (i.e. You are using openssl 1.0.1 and need to be one 1.0.2 or later, for example) but you have already confirmed you have ALPN support so skipping that for this answer.
Best Answer
Update 2016/08/08:
nginxinjessie-backports(version1.9.10-1~bpo8+3was built againstopenssl >= 1.0.2~. GettingALPNworking now if runningjessiejust requires the packages out ofjessie-backports, no need anymore to pull packages out ofstretch.--
Original answer: Well, here goes my answer, according to the comments: In my opinion, there aren't that many ways to solve this as of today, 2016/05/09. Basically you've to try somehow to get a modern
nginxinto your system, compiled against>= openssl 1.0.2~.The only two options I see currently: Either you compile for yourself, which you don't want to do, which is quite understandable, or you pull in modern packages out of
Debian stretchinto your system. This involves some risks, because you're mixing a stable environment with another one, but in my opinion these risks are quite low, because you're usingDebian.So, let's go and try out this:
Add the
Debian stretchrepository to yourapt sources. Don't use/etc/apt/sources.listfor this, but instead use a dedicated file inside/etc/apt/sources.list.d/to keep it clean, personally I'm usingstretch.list.Put these lines inside there:
Set up apt pinning to make sure you only pull in packages out of
Debian stretchwhich you're specifying. The file to use for this is/etc/apt/preferences, inside there, put:(You might have to alter the suites and priorities to fit your environment.)
Run
apt-get update(viasudo/ asroot) to update the package cache.Install
nginxfromDebian stretch:apt-get install -t stretch nginx(do this viasudo/ asroot). Profit!As I described in my comment(s), to even lower the risks involved, you could use something like a chroot or a container-solution like LXC. In case you want to go the
chrootway, you have to set up a network interface inside there: To do this, have a look at this blogpost for example, which gives an introduction tonetwork namespaces.Hope this helps; in case you've got more question, feel free to contact me. I would appreciate feedback and I'm interested in how it goes.