Let’s Encrypt でTLS証明書を更新する。

Let’s Encrypt のTLS証明書を更新してみました。試した環境は以下です。

CentOS 6.10 + Apache 2.2.15

有効期限を確認します。ブラウザのURL入力欄の鍵マークをクリックし、ウェブサイトの識別情報で確認します。Firefoxの例です。※他のブラウザでもURLの鍵マークをクリックして証明書の内容を確認できると思います。

有効期限は、10/17です。前回の記事「Let’s EncryptでTLS化する(前編)」で Let’s Encrypt のインストールのときに使用した certbot-auto を使用します。作業は root ユーザで行います。certbot-auto があるディレクトリまで移動して、以下のコマンドを実行します。

# ./certbot-auto renew

※Let’s Encrypt では有効期限が30日未満になると更新ができます。それ以上あると更新されません。強制的に更新するオプションもあるので、有効期限が30日以上残っている場合で更新したいときは「certbot-auto renew --force-renew」とすることで更新できます(これは試していませんけれども・・)。

このとき、Apacheは起動したままにしておいてください。僕はApacheを一旦停止して「certbot-auto renew」を実行したため、一度更新に失敗しました。。。

[広告]

気を取り直して、、Apacheを起動して実行すると、以下の結果が表示されます。

念の為、Apacheを再起動します。また、ブラウザの表示もリフレッシュさせます(再読込、もしくは、F5キー押下)。ブラウザのウェブサイトの識別情報で有効期限が延長されたことを確認します。

これで、無事、TLS証明書の更新ができました!

ちなみに、、TLS証明書の更新により何が変更されたのかサーバーの設定ファイルを確認してみました。certbot-auto でTLS証明書をインストールしたときにはコンフィグファイルの書き換えを行っていましたが、更新のときは書き換えは行われていないようです(以下のファイルはいづれも変更はなし)。

/etc/httpd/conf/httpd.conf
/etc/httpd/conf.d/ssl.conf
/etc/httpd/conf/httpd-le-ssl.conf
/etc/letsencrypt/options-ssl-apache.conf

TLS証明書が格納されているディレクトリは、confファイルに以下のように定義されています(僕の場合は ssl.conf に記載しています)。

SSLCertificateFile /etc/letsencrypt/live/(サイトのサーバ名)/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/(サイトのサーバ名)/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/(サイトのサーバ名)/chain.pem

/etc/letsencrypt/live/(サイトのサーバ名) 配下には証明書が配置されていますが、これはシンボリックリンクとなっており、このリンクが更新されていました。リンク先は「/etc/letsencrypt/archive/(サイトのサーバ名)」です。

リンク先のほうのファイルを確認すると、新たに証明書が新規作成されていました(2018/09/22に作成されているものが該当)。証明書ファイルを新規作成し、リンク先を古いものから新しいものに切り替えることでコンフィグファイルの修正はなしとしているようです。

あと、やってみて気づいたのですが、有効期限が「10/17」だったものを更新したので「10/17」から3ヶ月延長されると思ったのですが、そうではなくて、実施日「9/22」から3ヶ月延長されたようです。

その後だけれど、「Let’s Encrypt Expiry Bot」という差出人から「Let’s Encrypt certificate expiration notice for domain “(サイトのドメイン名)”」というタイトルでメールが届きました。内容は、Let’s Encrypt で取得したTLS証明書の有効期限が近づいたので更新してください、というもの。すでに更新したのですれ違いになったようです。更新期限が近づくとメールでも案内していたんですね。そういえば、TLS証明書をインストールするときに連絡先のメールアドレスを設定したのを思い出しました。こういう連絡のときにメールアドレスが使われるのですね。。

以上。

安全な通信を考える(電子証明書/PKI)

「安全な通信を考える(ハッシュ関数/電子署名)」の続きです。電子署名を使えば送信者の検証ができますが、それには相手の「本物の公開鍵」が自分の手元にあることが前提でした。

相手の公開鍵が本物かどうか?

これを解決するには、信頼できる第三者に証明してもらうことになります。その仕組みを書いてみます。

■電子証明書

まず、信頼できる第三者とは「公的な機関や組織」です。認証局(CA)と呼ばれます。認証局になるためには高い信頼性を確保するための運用や管理方法など厳しい審査をクリアする必要があります(※どのような審査があるのかは僕もわかりません)。この認証局(CA)が「この公開鍵はあなたのものです」と証明してくれるのですから、みんなもそれを信頼してくれることになります。

前回の例で、BさんがAさんに公開鍵を渡す場合、まずBさんはCAに「公開鍵が自分のものである」と証明してもらう申請を行います。CAではBさんの申請の審査を行い、問題ないようであれば電子証明書の発行を行います(図1)。

図1

この電子証明書ですが、その中身が重要です。電子証明書には以下のものが含まれています。

・公開鍵の証明書
・申請した公開鍵
・CAの電子署名

この中の「公開鍵の証明書」には、発行した認証局の名称、電子証明書の有効期間、証明書のシリアル番号(識別番号)と言った情報が記載されています。電子証明書はフォーマットが決まっていて、そのフォーマットにあわせた情報が記載されます(「X.509」といったフォーマットがあります)。

Bさんは、この電子証明書をAさんに送ることにより「この公開鍵はCAが認めた私のものです」とAさんに納得してもらうことができます。

とはいえ、、、Aさんは「この電子証明書は本当にCAが認めたものなのか?」という検証を行う必要があります。この検証を行う方法ですが、電子証明書に含まれる「CAの電子署名」を検証することでCAが発行したものなのかどうかを確認することができます。それにはCAの公開鍵が必要です(図2)。
※電子署名の検証については前回の「安全な通信を考える(ハッシュ関数/電子署名)」を参照してください。

図2

CAの公開鍵ですが、実は、AさんはすでにCAの公開鍵を持っています。信頼できる第三者であることから、OSやWEBブラウザーにあらかじめインストールされているのです。

改めて、AさんとBさんの通信を考えます。Bさんには、「本文」と「Bさんの電子署名」と「電子証明書」をあわせて送ってもらいます(図3)。

図3

Bさん(送信者)が行う作業、および、Aさん(受信者)が行う作業をそれぞれ記載してみます。

【Bさんの作業】

  1. 送りたい情報(本文)を作成する。※この本文はダミーで漏洩してもよいもの。
  2. 本文をハッシュ関数でハッシュ値にする(ダイジェストの作成)。
  3. 作成したダイジェストを秘密鍵で暗号化する。※この暗号化されたダイジェストが電子署名と呼ばれるものです。
  4. 「本文」と「Bさんの電子署名」、それに「電子証明書」を添付してAさんに送信する。

【Aさんの作業】

  1. Bさんから送られた情報を受け取る。
  2. 電子証明書からCAの電子署名を取り出し、インストールされているCAの公開鍵で復号する。
  3. 電子証明書から公開鍵の証明書を取り出し、ハッシュ化する。
  4. 2と3のハッシュ値を比較し、一致すれば電子証明書に含まれる公開鍵はBさんのものであるということが言える。
  5. 次に、そのBさんの公開鍵で「Bさんの電子署名」を復号する。
  6. 「本文」をハッシュ化する。
  7. 5と6のハッシュ値を比較し、一致すれば送られてきた情報は本当のBさんからのものであり、送信者が間違いないと言える。
  8. 受領したBさんの公開鍵で、本当に送りたい情報を暗号化してAさんからBさんに送る。

これでやっと、本当に安全な通信ができるようになったと言えます。

■公開鍵基盤(PKI)

この一連の仕組みは公開鍵基盤(Public Key Infrastructure)と呼ばれるもので、いまのインターネットが当たり前になっている現状では必要不可欠なものとなっています。信頼できる第三者を立てることで成り立っており、そこが「基盤」と言われるところなのでしょう。

IPAが実施する情報処理安全確保支援士やネットワークスペシャリスト試験でもセキュリティ分野に関わる問題がよく出ていて、電子証明書の理解ができていないと問題が解けないので、このブログの記載が理解の手助けとなれば幸いです。