稼働中のサイトに自動更新のSSL証明書を導入する方法

WebサーバにSSL証明書を導入すると、だいたいの場合年1回の更新作業が必要になります。
サイトが1つならそれも良いのですが、10サイトあれば月1回、50サイトあれば毎週の作業になってしまいます。できれば自動更新にしてメンテナンスフリーな状態にしたいものです。

マネージドではなく自前でSSL証明書を更新しなければならない場合に、自動更新できるSSL証明書の導入方法とメリット・デメリットについて整理します。

自動更新が可能なSSL証明書

自分でSSL証明書を導入する場合、自動更新してくれるSSL証明書として次の手段があります。

  • Let’s Encryptを導入して更新を自動化する
  • AWS Certificate Manager (ACM) を利用する

ACMはAWSにしかSSL証明書を発行しませんが、CloudFrontを使うことにより外部のサーバに対しても実質的にSSL証明書を導入することができます。

Let’s Encryptを使う

単に「SSL証明書を自動更新する」という場合、Let’s Encryptを使うのが現時点で一番の正攻法です。WordPress.comの独自ドメインのSSL証明書にも使われていて、シェアも大きいです。

Let’s Encryptの証明書は有効期限が90日しかありません。もとから自動更新を前提としています。ですので、標準的な手順を取れば自動更新になるでしょう。

  • メリット
    • SSL証明書が無料で手に入る
  • デメリット
    • Linuxコマンドに詳しくないと導入が難しい
    • 証明書発行元の名前が「Let’s Encrypt」で知名度が低い

AWS Certificate Manager (ACM) を使う

ACMによる証明書はCloudFrontとELB (Elastic Load Balancing) で使えます。
稼働中のサーバでELBを使用していれば、ACMを使用するのが王道です。なんといっても専用として提供されているのです。

  • メリット
    • SSL証明書が無料で手に入る
    • Web管理画面での操作なので簡単
    • 証明書発行元が「Amazon」で知名度が高い
  • デメリット
    • ELBとCloudFrontでしか使えない

サーバ管理を受託している場合、証明書発行元がAmazonであるのはLet’s Encryptに比べクライアントに説明しやすいです。Webサイトを管理していてAmazonを知らない人はいないでしょうから。

SSL証明書のためにCloudFrontを利用する

AWS以外のサーバの場合、CDNであるCloudFrontをWebサーバの前段に置くことでSSL証明書を利用します。ただし、キャッシュ期間は30秒程度にしてキャッシュ機能を実質的に殺します。そうすることでオリジンサーバの変更をすぐにCloudFrontに反映し、コンテンツ更新の使い勝手をほとんどそのままにできます。

CDNというよりはSSLアクセラレータに近い使い方です。しかし、あくまでもCloudFrontはCDNですので、次の場合にしか使えません。

  • ログイン操作などの動的要素がないサイトであること
  • サーバサイドでのアクセスカウントやログ解析をしていないこと

WordPressなどのCMS管理画面は別ドメインでないとおそらく事故を起こします。同じドメインの場合はこの方法はあきらめです。

注意したいのが、「WordPress Popular Posts」やコメント機能も動作影響がある点です。
CloudFrontでキャッシュを持っている場合はオリジンサーバにはリクエストが行われないため、アクセスそのものがなくなります。そのため、WordPress Popular Postsを使っていると「妙にPVが少ない」ということになります。また、apacheなどのログも発生しません。
コメント機能も「コメントありがとうございました」の表示がキャッシュされるなど意図しない動きになる可能性があります。

一方で、CDNを導入することによるメリットも発生します。一石二鳥です。責任者を説得しやすくなる場合もあるでしょう。もちろん手間も発生します。

  • メリット
    • 証明書発行元が「Amazon」で知名度が高い
    • CDNの導入なのでアクセス急増に強くなる
    • CDNの導入なので表示速度が速くなる場合が多い
  • デメリット
    • 動的要素のあるサイトでは適用できない
    • CloudFrontの利用料が発生する
    • オリジンサーバのドメインを変更する必要がある
    • ネイキッドドメインの場合(サブドメインを使っていない場合)はDNSをroute53に移設する必要がある
    • アクセス元がCloudFrontになるのでアプリケーション/サーバの設定が必要になることがある

SSL証明書の手間というよりCDN導入の課題にすり替わっています。良し悪しです。

comments powered by Disqus