Fusicきばんブログ

Fusic基盤ユニットの非公式技術ブログ

CentOS5/RHEL5系でSHA-2/TLS1.2のアウトバウンドのhttps通信を行う方法を検討してみる

CentOS Java TLS SSL RHEL OpenSSL

基盤ユニットの貞方（@sadapon2008）です。

今回は刺さる人には刺さるCentOS5/RHEL5系でSHA-2/TLS1.2のアウトバウンドのhttps通信の実現方法を検討してみたいと思います。

背景

CentOS5/RHEL5系はすでにサポートが切れていますが、諸事情でまだ稼働しているシステムがあったりします。 CentOS5/RHEL5に含まれるOpenSSLは0.9.8eのため、curlなどOpenSSLをベースにアウトバウンドのhttps通信を行う場合、SHA-2やTLS1.2には未対応です（SHA-2はOpenSSL 0.9.8o以降、TLS1.2はOpenSSL 1.0.1以降が必要）。 しかし、世の中の流れでhttps通信で使うサーバ証明書の署名アルゴリズムはSHA-1からSHA-2への移行が進んでいて、 TLSのバージョンもAPIサービスによっては1.2でしか受け付けないものも出てきています。 そこで、CentOS5/RHEL5系で外部とSHA-2/TLS1.2のhttps通信を行う方法を検討してみました。

案1. 最新のOpenSSLをソースコードからコンパイルしてインストールする

最初に思いつくのは、最新のOpenSSLをソースコードからコンパイルしてインストールすることです。 ただし、ディストリビューションの標準パッケージのOpenSSLを上書きするようなことをするとOSがぶっ壊れる可能性が高いため、 標準パッケージと競合しないようにインストールしないと危険です。 その場合、コンパイルしてインストールしたOpenSSLでhttps通信するためには、curlなどOpenSSLを利用するプログラムも ソースコードからコンパイルしてインストールする必要があります。

また、PHPなどサーバサイドのアプリケーションなどでそれらを利用するには、アプリケーションのソースコードの大幅な変更も必要になります。

案2. 別途リバースプロキシサーバを用意する

CentOS5/RHEL5より新しいOpenSSLを利用できるCentOS7/RHEL7などでリバースプロキシサーバを用意して、そちら経由でhttps通信を行うことも考えられます。 例えば、「https://api.hoge.com」のURLでアクセスしていたものが、「http://(リーバスプロキシサーバのIPアドレス)」のURLでアクセスするように構成することが可能です。

この方法の場合、PHPなどサーバサイドのアプリケーションはアクセスするURLの修正だけで済むため、案1.に比べたら変更量を抑えられます。

ただし、別途サーバを準備する必要があります。

案3. CentOS5/RHEL5上でJava 1.7のリバースプロキシサーバを動作させる

CentOS5/RHEL5のディストリビューンの標準パッケージにはJava 1.7が含まれています。 Java 1.7自体もすでにサポートは切れていますが、実はJava 1.7はSHA-2/TLS1.2に対応していますので、Javaで動くリバースプロキシサーバを動かせば、別途サーバを用意する必要がありません。

Javaはずぶの素人なのですが、下記のGithubのコードを参考にJettyの組み込みプロキシを使うプログラムを作成してみました。

github.com

作成したものがこちらになります。

github.com

gradlewを使っていますので、以下のようすればビルドできると思います。

$ sudo yum install java-1.7.0-openjdk-devel
$ chmod a+x gradlew
$ ./gradlew fatJar

ビルドに成功したら、以下のようにコマンドを実行すると「http://127.0.0.1:8080」で待ち受けするリバースプロキシとして動作します。

$ java -jar ./build/libs/simple_reverse_proxy.jar https://api.hoge.com 8080

この状態で下記のようにするとSHA-2/TLS1.2のサーバに対してhttps通信を行うことができます。

$ curl http://127.0.0.1:8080/

正直Jettyの中身はまだよくわかっていないところもあるのですが、superviosrなどと組み合わせればデーモン化したりもできそうです。