サーバー証明書

お金払って買ってる場合は知らないですけど、うちは Let's Encrypt さん (日本語サイト: Let's Encrypt JP )なので比較的ラクチンに好き放題できます。

細かい説明は本家サイトに任せて置いておくとして、うちには既に certbot が導入されているので……

# emerge -pv certbot

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ~] app-crypt/certbot-0.11.1::gentoo  USE="{-test}" PYTHON_TARGETS="python2_7" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

ステータスが testing なのはご愛敬、gentoo ならよくあることなのでこのままいきますｗ

この作業は、サーバー証明書を取得しようとしているホスト名…… FQDN に紐付く IP を持っている本番サーバーで実施します。

まず動いているWebサーバーを停止します。

# systemctl stop nginx

これは certbot が tcp:443 ¹⁾にバインドして Let's Encrypt サーバーと通信するからです。Let's Encrypt サーバーが manimani.cc:443 にアクセスした時に certbot がちゃんと期待した応答を返すことでドメインの所有者であることを確認するみたいです。

1. certbot が tcp:443 を開けて、Let's Encrypt サーバーに確認要求を出す
2. Let's Encrypt が manimani.cc:443 に何かを要求する
3. certbot が tcp:443 でリクエストを受けて、要求されている何かを適切に返す
4. ここまでのハンドシェイク的な動作が正常であれば、ドメインの所有者からのリクエストだと認定して csr なりの証明書発行手順に移る

みたいな通信が行われているんだろうなぁとざっくり想像してます。

で。

# certbot certonly --standalone -d manimani.cc -d www.manimani.cc

これだけで²⁾ /etc/letsencrypt/ 下に csr, 秘密鍵, サーバー証明書, 中間サーバー証明書, FullChain証明書なんかが保存されます。³⁾ /etc/letsencrypt/ 下にいくつかディレクトリができてますが、基本的には live/manimani.cc/ 下の symlink が “最新” の扱いなんだと思います。証明書の期限が近づいて certbot で証明書の更新をかけた場合でも、この symlink は常に最新を指すんだろうなぁ……と。

というわけなので、うちの環境ではこの “最新” symlink にさらに symlink を張って運用してます。

# ln -sf /etc/letsencrypt/live/manimani.cc/privkey.pem /path/to/config/nginx/privkey.pem
# ln -sf /etc/letsencrypt/live/manimani.cc/fullchain.pem /path/to/config/nginx/fullchain.pem

こんな感じで symlink 張ったら nginx.conf に追記。

server {
    server_name                     manimani.cc;
     :
    ssl on;
    ssl_protocols                   TLSv1 TLSv1.1 TLSv1.2;
    ssl_certificate                 /path/to/config/nginx/fullchain.pem;
    ssl_certificate_key             /path/to/config/nginx/privkey.pem;

ざっくり抜粋ですがこんな感じで。

Webサーバー用証明書 とまったく同じ手順で作成できます。ただし通常は開けていないであろうメールサーバー向けの TPC:443 を開ける必要があることには注意が必要ですけどね。