してみるテストロゴ
Apache 2.4系でHTTP/2サーバを構築してみるテスト。

Let's Encrypt ベストプラクティス

Let's Encryptもサービス開始から3年目に入りました。

当初は、ACMEエージェント(サーバ証明書を取得するクライアントアプリ)の種類が限られるなど、導入も大変でしたが、いまや多数のACMEエージェントがリリースされており、選択の幅が広がりました。逆に選ぶのが大変です。

また、2018年1月10日には、Let's Encryptのドメイン認証方法のひとつである、TLS-SNIチャレンジに脆弱性が発見されました。IP共有型ホスティングサイトで同居しているユーザーが他人のドメインの証明書を取得できる問題のようです。

一見、通信の乗っ取りが難しいTLSを使った方が、安全に証明書の更新が行えると思っていたのですが、意外な落し穴です。

そこで、独断と偏見になりますが、現時点での、Let's Encryptのベストプラクティスを紹介したいと思います。

ACMEエージェントはacme.shがおススメ

まず、証明書を取ってくるソフトウエアである、ACMEエージェントですが、これは、acme.shがオススメです。

理由は、3つあります。

一つ目は、unix系で,OpenSSLがインストールされていれば、FreeBSDやSolarisなど、Linux以外の環境でも動作します。

OSにデフォルトインストールされているソフトウエアだけで動作するので、依存する言語、ライブラリが少ないのもメリットです。

二つ目は、国際化ドメイン名に対応しています。

三つ目は、一つのドメイン名に、RSA暗号方式の証明書と、ECDSA暗号方式の証明書の2つを取得しても、ファイル名が衝突しないため、acme.shだけで、マルチアルゴリズム証明書を利用できます。

acme.shは、国際化ドメイン名に対応

acme.shのインストールと、国際化ドメイン名の取得は以下を参考にしてみてください。

ACMEエージェントによっては、国際化ドメイン名に対応していないので、対応しているのは安心です。

国際化ドメイン名の証明書取得についていは、上記リンクをご覧ください。

acme.shは、RSAの証明書と、ECDSAの証明書を共存して取得できる

Apache HTTP Webサーバは、認証アルゴリズムが異なる、複数のサーバ証明書を同時に使用できます。

これをマルチアルゴリズム証明書と言います。

上記ページでは、letsencrypt-auto(現:certbot)と、letsencrypt.shの2つのACMEエージェントを使っています。

一般的なACMEエージェントは、証明書アルゴリズムが異なったとしても、証明書を保存するフォルダや、ファイル名が同一になってしまいます。

そこで、上記ページでは、ファイル名が衝突しないように、RSA証明書と、ECDSA証明書を、それぞれ別のACMEエージェントを使って取得しています。

ところが、acme.shは、 RSA証明書を

~/.acme.sh/example.net/

ECDSA証明書は(-k ec-256のオプションを付けて実行した場合)、

~/.acme.sh/example.net_ecc/

と、「_ecc」が付いたフォルダに格納してくれます。

そのため、異なる認証アルゴリズムの証明書を取得しても、上書きされることなく、証明書を保持できます。

詳しくは、以下をご覧ください。

acme.shを使って、RSA証明書と、ECDSA証明書をそれぞれ取得しています。

この機能は意外に重宝します。

acmeのドメイン認証チャレンジは、HTTP-01(http/1.1)の方が無難?

これは、acme.shとは関係ないのですが、冒頭で述べたとおり、2018年1月10日に、TLS-SNIチャレンジに脆弱性が発見されました。

問題は、証明書の更新をTLS経由で行っていると、巻き込まれてしまうところにあります。

そこで、この問題が落ち着くまでは、HTTP-01とよばれるドメイン認証の方式を使った方が安定しそうです。

これは、非暗号のHTTP/1.1通信を使って、ドメイン所有者であることの認証を行います。

HTTP Strict Transport Security(HSTS)など、HTTP->HTTPSのリダイレクトを行っている場合は単純なリダイレクトでは設定の変更が必要になります。

まず、ACMEエージェントが使用するWebrootを、非暗号のHTTP/1.1のhtdocsのパスにします。

そして、HTTP-01がドメイン認証につかうディレクトリだけは、リダイレクトの対象外にしなければなりません。これは、以下のリンクを参考に設定してください。

TLS通信は、サーバ証明書を前提としていますが、サーバ証明書を持っていないから、Let's Encryptのようなサービスを利用することになります。

サーバ証明書が無いため、非暗号通信であるHTTP-01を使わざるを得ないのは仕方ないですし、それによって問題は起きにくいと思います。

強いて言えば、有象無象に、非暗号通信であるHTTP/1.1のURLへのアクセスをブロックしておくと良いかもしれません。

つまり、HTTP-01がアクセスしてくるディレクトリにホストのアクセス制限をかけて、acme-v01.api.letsencrypt.orgのホスト(ステージングも含めておくと良いかも)以外からのアクセスを拒否しておきます。

acme.shは、dns-01認証チャレンジを利用して証明を取得できる

acme.shは、dns-01による認証チャレンジにも対応しています。

しかも、bind形式のゾーンファイルを使うデーモン(たとえばnsd)を使っていても、大丈夫です。

将来的には、dns-01認証チャレンジを使って、ワイルドカード証明書の発行も計画されていますので、是非お試しください。

TOP >> Let's Encryptの機能のまとめ

©Copyrights 2015-2018, non-standard programmer

このサイトは、あくまでも私の個人的体験を、綴ったものです。 軽く参考程度にご利用ください。