前からやりたかった、SSL証明書の楕円曲線暗号化をついにやりました。ついでに、Qualys SSL Labsの評価も「A+」まで対応したです。
SSL設定の改善
元々、このブログサイトのSSL設定は結構やりこんでます。
考えられるすべてのSSL設定に対応したnginxにしてありますが、これまでのところ、Qualys SSL LabsのSSLテストでの評価は「A」でした。最後、HSTS（HTTP Strict Transport Security）対応を行い、無事「A+」になりました。
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
こんな感じ。
意識高い、楕円曲線暗号
と、ここまでは既にやりかけだったものを対応したという話で、本題は楕円曲線暗号のほうです。
楕円曲線暗号とは・・・良く分からないけど、凄いらしい（苦笑）。Elliptic Curve Cryptography: ECCと略されますが、ビットコインでも使われている、イケてる暗号化方式で、ビット長短くて暗号・複合の計算量少なくても、RSAより強力（同じ暗号長であれば、RSAより解読困難）なんだそうです。凄いのは使いたいよね。
私がこの楕円曲線暗号を知ったのは、SSHの公開鍵についてちょっとしたトラブルを踏んだのがきっかけです。
そこからいろいろ調べてみたら、GoogleのWebのSSL証明書が、楕円曲線公開鍵だったんです。Facebookも採用していますね。これは真似してみたい。という訳で、SSL証明書で楕円曲線暗号を使う方法をいろいろ調べてみたところ、どうやらStartSSLでも出来そうなので、思い切って証明書作り直してみました。
まずは、暗号鍵を作ります。従来RSAで作っていたものを、ecparamというopensslのオプションを指定して、ECC鍵を作るんですが、その前に。RSAの場合、鍵長がパラメータになるんですが、ECCの場合、楕円曲線に幾つかの種類と鍵長があるので、これを選択しなければなりません。
% openssl ecparam -list_curves secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field
今ブログサーバーが動いているのがCentOS6ということもあり、選択肢が思いの外少ない（苦笑）。もっといろいろあるかと思ったんですが、肩透かしを喰らいました。おそらくnginxは個別にダウンロードした最新のopensslを使ってコンパイルしているので、もっといろいろ対応できそうですが、運用性を考えて、この中から選ぶことにします。とりあえずGoogleの公開鍵を見ると、「secp256r1」というものが指定されています。一方で、secp521r1については、対応しないブラウザがあるとの情報があり、ちょっと不安です。加えて、StartSSLで、secp384r1を指定して証明書作ったよ、っていう海外の情報もあったので、「secp384r1」を使うことにしました。
作業用ディレクトリを作って証明書を作っていきます。ちなみに・・・秘密鍵ってどうやってバックアップ取ったら安全なんだろう、っていつも悩む。
% mkdir ssl % cd ssl % openssl ecparam -out ayurina-ecc.key -name secp384r1 -genkey
これでayurina-ecc.keyに秘密鍵ができました。RSAの鍵との違いとして、ファイルが2ブロック構成になっていて、最初のブロックにECのスペックがあり、その後に鍵のブロックが記載された形になっています。
続いてCSRを作ります。このサイトはSNIでマルチドメイン化していますので、その対応も行います。実はStartSSLの場合、Certificate Wizardの画面でドメイン追加することになるので、あまり意味は無いのですが、折角なので正攻法で対応してみました。
マルチドメインっていうか、subjectAltNameに対応したCSRを作るには、opensslの設定をコピーして、パラメータを個別に設定してあげる必要があります。
% cp /etc/pki/tls/openssl.cnf . % vi openssl.cnf 106c106,107 < default_bits = 2048 --- > req_extensions = v3_req > default_bit = 2048 225a227,232 > subjectAltName = @alt_names > > [alt_names] > DNS.1 = blog.ayurina.net > DNS.2 = techblog.ayurina.net
編集箇所は、reqセクションでreq_extensionsを指定するのと、v3_reqセクションにsubjectAltNameと対象となるFQDNを指定するところです。あとは、ここで用意したopenssl.cnfと上記のECC秘密鍵を使って、通常の手順でCSRを作ってあげればOKです。Common Nameだけ、変なの指定しなければ良いかと思います。
% openssl req -new -sha256 -config ./openssl.cnf -key ayurina-ecc.key -nodes -out ayurina.net-ecc.csr ... Common Name (eg, your name or your server's hostname) []:ayurina.net ...
一応、できたCSRの中身を確認して、ちゃんとsubjectAltNameが入っていることを確認します
% openssl req -in ayurina.net-ecc.csr -text
...
X509v3 Subject Alternative Name:
DNS:blog.ayurina.net, DNS:techblog.ayurina.net
...
ここからはStartSSLの画面での署名作業になります。久々にアクセスしたらなんだか有料メニューが幅を利かせていて、Freeメニューが分かりづらくなっていましたが、表組みの右上の方にある「DV SSL Certificate」を選べばOKです。ってゆっか、これ、StartSSL完全有料化への布石か？dyndnsが有料化されたときの流れを思い出しますが。
CSRの提出フォームで、上で作ったCSRを貼り付けます。この時、CSRの形式のバリデーションが行われ、ちゃんとEC鍵として認識される確認できます（ここで、StartSSLが対応しているか否か判断が付くと）。
ちゃんとECCの384bitと認識されていますので、問題ありません。
あとは普通に、署名が行われ、証明書がダウンロード可能になりますので、今まで使っていた証明書ファイルと差し替えてnginxを再起動すれば適応完了です。
無事、「アルゴリズム：楕円曲線公開鍵」の「パラメータ：楕円曲線secp384r1」になりました。素晴らしい。
実用上、何が変わったということは無いですが、やっぱり暗号が強いってそれだけで素敵だなぁという感じです。楕円曲線公開鍵にHTTP/2対応という、なんて意識高いSSLサイトなんでしょう、と勝手に思ってます（苦笑）。そんなに難しい対応でも無いので、SSL等のセキュリティに興味のある方は勉強ついでに適応してみると良いかなぁとおもいます。
コメント