nginxユーザー必見！CertbotでSSLを自動化・無料化しよう

By /

nginxユーザー必見！CertbotでSSLを自動化・無料化しよう

はじめに：なぜSSLが必要なのか、そしてCertbotが解決すること

インターネット上のセキュリティが叫ばれる現代において、WebサイトのSSL/TLS化（HTTPS化）はもはや必須と言えます。SSL/TLS証明書を導入することで、ユーザーのブラウザとWebサーバー間の通信が暗号化され、第三者によるデータの盗聴や改ざんを防ぐことができます。これは、個人情報やクレジットカード情報といった機密情報を扱うECサイトや会員サイトだけでなく、ブログや企業サイトなど、あらゆるWebサイトにとって不可欠なセキュリティ対策です。

HTTPS化の重要性はセキュリティだけにとどまりません。

  1. セキュリティ: 最も重要な理由です。通信の暗号化により、ユーザーは安心してサイトを利用できます。特にログイン情報やフォーム送信などを行うサイトでは必須です。
  2. 信頼性: ブラウザのアドレスバーに表示される鍵マークや「保護された通信」の表示は、サイトが安全であることをユーザーに伝え、信頼性を高めます。SSL化されていないサイトには「安全ではありません」という警告が表示され、訪問者に不安を与えてしまいます。
  3. SEO (検索エンジン最適化): GoogleはHTTPS化を検索ランキングの要因の一つとしています。HTTPS化されたサイトは、検索結果で有利になる可能性があります。
  4. 新しいWeb技術の利用: HTTP/2などの最新のプロトコルや、一部のWeb API（Geolocation API, Service Workersなど）は、HTTPS接続でしか利用できません。

このように、SSL化は今日のWebサイト運用において避けられない課題です。しかし、これまでのSSL証明書の導入には、いくつかのハードルがありました。

  • コスト: 信頼できる認証局から証明書を取得するには、年間数千円から数十万円といった費用がかかることが一般的でした。
  • 取得と設定の煩雑さ: 証明書署名要求(CSR)の作成、認証局への申請、証明書のインストール、Webサーバー設定ファイルの編集など、専門的な知識が必要で手順も煩雑でした。
  • 更新作業: 証明書には有効期限があり、通常1年間や2年間で失効します。失効前に忘れずに更新手続きを行い、再度インストール作業を行う必要があり、この作業を怠るとサイトが一時的にアクセスできなくなるリスクがありました。

これらの課題に対し、画期的な解決策を提供したのが、非営利団体であるISRG (Internet Security Research Group) によって運営されている認証局 Let’s Encrypt と、その証明書取得・設定ツールである Certbot です。

Let’s Encryptは、ドメイン認証型のSSL/TLS証明書を無料で提供しています。そして、Certbotは、このLet’s Encrypt証明書の取得、Webサーバーへの設定、そして自動更新を簡単に行うことができるツールです。特にnginxユーザーにとって、Certbotはnginxの設定ファイルを自動的に編集してくれる機能を持っており、SSL化の手間を大幅に削減できます。

この記事では、nginxを利用しているサーバーで、Certbotを使って無料でSSL証明書を取得し、自動更新まで行うための具体的な手順を、初心者の方にも分かりやすく詳細に解説します。この記事を読めば、あなたのWebサイトも安全で信頼性の高いHTTPS接続に対応できるようになるでしょう。

1. SSL/TLSの基礎知識：なぜ必要なのか？

CertbotやLet’s Encryptの話に入る前に、まずはSSL/TLSに関する基本的な仕組みを理解しておきましょう。

1.1. SSL/TLSとは？

SSL (Secure Sockets Layer) およびその後継であるTLS (Transport Layer Security) は、インターネット上でデータを安全に送受信するためのプロトコルです。これらのプロトコルは、クライアント（Webブラウザなど）とサーバー（Webサーバーなど）間の通信を暗号化し、データの盗聴や改ざんを防ぐ役割を担います。現在、広く使われているのはTLSプロトコルであり、SSLという名称は古いバージョンを指すことが多くなりましたが、「SSL化」という言葉は暗号化通信の一般名称として使われ続けています。

1.2. 暗号化の仕組み

SSL/TLSによる暗号化通信は、主に以下の2つの暗号化方式を組み合わせて実現されます。

  • 公開鍵暗号方式: 通信を開始する際に使用されます。この方式では、「公開鍵」と「秘密鍵」というペアの鍵を使います。公開鍵で暗号化されたデータは、対応する秘密鍵でしか復号できません。逆に、秘密鍵で暗号化されたデータは、対応する公開鍵で復号できます（これはデジタル署名に使われます）。公開鍵は誰でも入手できますが、秘密鍵は所有者だけが厳重に保管します。通信相手にデータを送る際は、相手の公開鍵でデータを暗号化して送ります。相手は自分の秘密鍵で復号します。これにより、鍵を知らない第三者には内容が漏れません。ただし、公開鍵暗号は計算コストが高いため、大量のデータ通信には向きません。
  • 共通鍵暗号方式: 実際のデータ通信（Webサイトのコンテンツなど）に使われます。この方式では、暗号化と復号に同じ「共通鍵」を使います。公開鍵暗号に比べて計算コストが低く、高速に処理できます。しかし、通信相手と安全に共通鍵を共有する必要があります。

SSL/TLS通信では、まず公開鍵暗号を使って、共通鍵を安全に交換します（この鍵交換のプロセスは「ハンドシェイク」と呼ばれます）。共通鍵の交換が完了したら、以降の実際のデータ通信は、その共通鍵を使った共通鍵暗号方式で行われます。

1.3. SSL/TLS証明書とは？

「公開鍵」は誰でも入手できますが、その公開鍵が「本当に目的のWebサイトの公開鍵なのか」をどうやって確認するのでしょうか？ もし悪意のある第三者が偽の公開鍵を配布し、ユーザーになりすましていたら、ユーザーはその偽の公開鍵でデータを暗号化して送ってしまい、情報が漏洩してしまいます。

この「公開鍵が正当なものであるか」を保証するのがSSL/TLS証明書です。SSL/TLS証明書は、信頼できる第三者機関である「認証局 (CA: Certificate Authority)」が発行します。証明書には、サイトの運営者情報（ドメイン名、組織名など）と公開鍵が含まれており、CAがこれらの情報が正しいことを確認し、CAの秘密鍵で署名（デジタル署名）しています。

Webブラウザは、証明書を受け取ると、内蔵している信頼できるCAの公開鍵を使ってその署名を検証します。署名が正しければ、「この証明書は信頼できるCAによって発行されたものであり、含まれている情報（ドメイン名など）はCAが確認済みである」と判断できます。これにより、ブラウザは受け取った公開鍵が正規のものであると信頼し、安全な通信を開始できます。

Let’s Encryptも、ISRGという組織によって運営される認証局の一つです。

1.4. HTTPSとは？

HTTPS (Hypertext Transfer Protocol Secure) は、私たちが普段Webサイトを閲覧する際に使われるHTTPプロトコルに、SSL/TLSによる暗号化を追加したものです。URLが http:// ではなく https:// で始まるサイトがHTTPS化されています。標準では、HTTPはポート80、HTTPSはポート443を使用します。

1.5. なぜLet’s Encryptは無料なのか？

従来の認証局は、証明書の発行・管理プロセスに多くの人手やコストがかかり、その費用を証明書価格に転嫁していました。 Let’s Encryptは、証明書の発行とドメイン名の検証プロセスを可能な限り自動化することで、これらのコストを削減し、証明書を無料で提供することを可能にしました。

Let’s Encryptが提供するのはドメイン認証型の証明書です。これは、申請者がそのドメイン名の所有者であることを自動化されたプロセスで検証するものです（例えば、ドメインに対応するWebサイトに特定のファイルを置かせる、DNSレコードに特定の値を設定させるなど）。組織の法的実在性を確認する組織認証型(OV)やEV認証型(EV)の証明書に比べると、検証レベルはシンプルですが、個人のブログや中小企業のWebサイトなど、多くの用途には十分です。

2. Certbotとは何か？

Certbotは、Let’s EncryptからSSL/TLS証明書を取得し、Webサーバー（Apacheやnginxなど）にインストールして、自動更新するためのクライアントソフトウェアです。Let’s Encryptの利用を劇的に簡単にしました。

2.1. Certbotの概要

Certbotは、EFF (Electronic Frontier Foundation) という非営利団体によって開発・管理されています。Let’s Encryptは認証局、Certbotはその認証局とやり取りするためのツール、という関係です。

2.2. Certbotができること

  • 証明書の取得: Let’s EncryptのACMEプロトコルを使用して、指定したドメイン名の証明書をリクエスト・取得します。
  • ドメイン認証: Let’s Encryptが行うドメイン認証（例えば、HTTP-01チャレンジやDNS-01チャレンジ）をCertbotが自動的に処理します。
  • Webサーバー設定: Apacheやnginxなど、主要なWebサーバーの設定ファイルを自動的に書き換えて、取得した証明書が使えるように設定します（対応プラグインがある場合）。HTTP接続へのアクセスを自動的にHTTPSへリダイレクトする設定も可能です。
  • 証明書の更新: 証明書の有効期限が近づくと、Certbotが自動的に証明書を更新し、Webサーバーの設定を再読み込みします。
  • 証明書の管理: 取得した証明書の一覧表示、削除などができます。

2.3. 対応OS、Webサーバー

Certbotは様々なOS (Linuxディストリビューション、BSDなど) で動作し、Apacheやnginxといった主要なWebサーバーに対応するプラグインを提供しています。この記事では、nginxに特化して解説を進めます。

3. Certbot導入前の準備

Certbotを使ってLet’s Encrypt証明書を取得し、nginxに設定する前に、以下の準備が必要です。

3.1. ドメイン名の取得とDNS設定

Certbotはあなたがそのドメイン名の所有者であることを確認します。そのため、証明書を取得したいドメイン名（例: example.com, www.example.com）を事前に取得し、そのドメイン名がサーバーのIPアドレスを指すようにDNS設定（AレコードまたはAAAAレコード）が完了している必要があります。

  • ドメイン名: example.com
  • Aレコード: example.com -> サーバーのIPv4アドレス
  • Aレコード (または CNAME): www.example.com -> サーバーのIPv4アドレス (または example.com)
  • AAAAレコード: example.com -> サーバーのIPv6アドレス (IPv6を利用している場合)
  • AAAAレコード (または CNAME): www.example.com -> サーバーのIPv6アドレス (または example.com)

Certbotがドメイン認証を行う際、Let’s Encryptのサーバーからあなたのドメイン名にアクセスします。このアクセスがあなたのサーバーに到達しなければ、認証は成功しません。DNS設定の反映には時間がかかる場合がありますので、設定後はしばらく待ってからCertbotを実行してください。ping コマンドなどでドメイン名が正しいIPアドレスを指しているか確認できます。

3.2. サーバーへのSSHアクセス

Certbotのインストールや実行はサーバー上で行います。SSHクライアント（Tera Term, PuTTY, OpenSSHなど）を使ってサーバーにログインできる権限が必要です。通常は sudo を実行できる非rootユーザー、またはrootユーザーで作業します。

3.3. ファイアウォールの設定

Certbotがドメイン認証を行う際、Let’s Encryptのサーバーがあなたのサーバーの特定のポートにアクセスします。最も一般的な認証方法であるHTTP-01チャレンジでは、ポート80 (HTTP) を使用します。また、HTTPS通信のためには ポート443 (HTTPS) の開放が必要です。

サーバーにファイアウォールを設定している場合は、以下のポートへの外部からのアクセスを許可してください。

  • TCPポート 80: CertbotのHTTP-01チャレンジ、およびHTTPからHTTPSへのリダイレクトのために必要です。
  • TCPポート 443: HTTPS通信のために必要です。

よく使われるファイアウォール管理ツール（ufw, firewalldなど）での設定例を参考にしてください。

  • ufwの場合 (Ubuntu/Debian系):
    bash
    sudo ufw allow http
    sudo ufw allow https
    sudo ufw enable # ufwが有効になっていなければ
  • firewalldの場合 (CentOS/RHEL系):
    bash
    sudo firewall-cmd --permanent --add-service=http
    sudo firewall-cmd --permanent --add-service=https
    sudo firewall-cmd --reload

3.4. Nginxが稼働していること

Certbotのnginxプラグインを利用するには、サーバーにnginxがインストールされており、稼働している必要があります。また、証明書を取得したいドメイン名に対応するnginxのサーバーブロック（server ディレクティブ）が設定されており、ポート80でHTTPリクエストに応答できる状態であることが望ましいです。Certbotは既存のnginx設定ファイルを読み込んで、証明書の設定やリダイレクト設定を自動的に書き込みます。

Certbotがnginxの設定ファイルを自動で書き換えるためには、Certbot実行時にnginxが起動している必要があります。

3.5. OSとNginxのバージョン確認

Certbotは特定のバージョンのOSやNginxに対応しています。一般的には最新または比較的新しいバージョンのOSやNginxであれば問題ありませんが、古い環境の場合はCertbotの公式サイトで対応状況を確認してください。

  • OSバージョンの確認例 (Ubuntu): lsb_release -a
  • OSバージョンの確認例 (CentOS/RHEL): cat /etc/redhat-release
  • Nginxバージョンの確認例: nginx -v または sudo nginx -V

4. Certbotのインストール方法（Nginx向け）

Certbotのインストール方法はいくつかありますが、公式では snapd を利用したインストールを推奨しています。これは、依存関係の問題を避け、常に最新バージョンのCertbotを利用できるためです。ただし、環境によっては apt や yum といったOSのパッケージマネージャーを利用する方法や、Python仮想環境を利用する方法もあります。ここでは、推奨されるsnapdによる方法と、一般的なパッケージマネージャーによる方法を中心に解説します。

4.1. snapdを使ったインストール (推奨)

Snapは、Canonical（Ubuntuの開発元）が開発したパッケージ管理システムです。アプリケーションとその依存関係をまとめてパッケージ化し、システムから隔離された安全な環境で実行できます。多くの主要なLinuxディストリビューションで利用可能です。

ステップ1: snapdのインストール

多くのLinuxディストリビューションではデフォルトでインストールされていますが、もしインストールされていなければ以下のコマンドでインストールします。

  • Ubuntu 16.04 LTS (Xenial Xerus) 以降: snapd は標準で含まれています。必要に応じて sudo apt update && sudo apt install snapd で最新化します。
  • Debian:
    bash
    sudo apt update
    sudo apt install snapd
  • CentOS/RHEL 7以降, Fedora:
    bash
    sudo yum install epel-release # EPELリポジトリが必要な場合
    sudo yum install snapd
    sudo systemctl enable --now snapd.socket
    sudo ln -s /var/lib/snapd/snap /snap # /snapへのシンボリックリンクを作成
  • Amazon Linux 2:
    bash
    sudo yum update -y
    sudo yum install -y snapd
    sudo systemctl enable --now snapd.socket
    sudo ln -s /var/lib/snapd/snap /snap
  • その他のディストリビューションについては、snapcraft.ioの公式ドキュメントを参照してください。

snapdのインストール後、一度シェルを再起動するか、以下のコマンドを実行して snap コマンドがパスに含まれていることを確認します。

bash
sudo snap install core; sudo snap refresh core

ステップ2: Certbotのインストール

snapdを使ってCertbotをインストールします。--classic オプションは、Certbotがシステムファイルを操作するために必要です。

bash
sudo snap install --classic certbot

ステップ3: Certbotコマンドへのシンボリックリンク作成

Certbotコマンドが /usr/bin/certbot から実行できるように、シンボリックリンクを作成します。これは、certbot と入力するだけでコマンドを実行できるようにするためです。

bash
sudo ln -s /snap/bin/certbot /usr/bin/certbot

これでsnapdを使ったCertbotのインストールは完了です。

4.2. パッケージマネージャーを使ったインストール (apt, yumなど)

snapdが利用できない環境や、特定の理由でsnapdを使いたくない場合は、OSのパッケージマネージャーを使ってCertbotをインストールすることも可能です。ただし、パッケージによってはCertbotのバージョンが古かったり、nginxプラグインが別のパッケージとして提供されていたりする場合があります。

  • Ubuntu/Debian系:
    bash
    sudo apt update
    sudo apt install certbot python3-certbot-nginx
    python3-certbot-nginx がnginxプラグインのパッケージです。

  • CentOS/RHEL系 (EPELリポジトリが必要):
    CentOS/RHEL 7/8やAmazon Linux 2の場合、Certbotは通常EPEL (Extra Packages for Enterprise Linux) リポジトリで提供されています。
    “`bash
    # EPELリポジトリの追加 (すでに設定済みであれば不要)
    sudo yum install epel-release

    Certbotとnginxプラグインのインストール

    sudo yum install certbot python3-certbot-nginx
    ``
    CentOS Stream 8/9やRHEL 8/9の場合は、    dnf` コマンドを使用し、EPEL NextリポジトリやCodeReady Linux Builder (CRB) リポジトリが必要になる場合があります。

    “`bash

    EPEL Next リポジトリの追加 (RHEL 8/9, CentOS Stream 8/9)

    sudo dnf install epel-release epel-next-release

    Certbotとnginxプラグインのインストール

    sudo dnf install certbot python3-certbot-nginx
    “`

パッケージマネージャーでインストールした場合も、これでCertbotの準備は完了です。

4.3. Python仮想環境を使ったインストール (上級者向け)

システムのパッケージに依存せず、特定のバージョンのCertbotをインストールしたい場合や、依存関係の問題を避けたい場合は、Pythonの仮想環境(venv)を使ってCertbotをインストールすることも可能です。この方法はより柔軟ですが、手動での設定が少し増えます。

この方法は、Certbotの実行や更新スクリプトのパスなどがパッケージマネージャーの場合と異なるため、初心者向けではありません。本記事では詳細な手順は割愛しますが、公式ドキュメントを参考にしてください。

5. Certbotを使った証明書の取得とNginxの設定

Certbotをインストールしたら、いよいよ証明書を取得し、nginxを設定します。Certbotには、nginxプラグインを使って自動的に設定を行う方法と、証明書の取得だけを行い手動で設定する方法があります。ここでは、簡単で推奨される自動設定を中心に解説します。

5.1. 対話モードでの取得と自動設定 (certbot --nginx)

最も簡単で推奨される方法です。Certbotがあなたのnginx設定ファイルを読み込み、証明書を自動で取得・インストールし、必要に応じてHTTPSへのリダイレクト設定も行います。

以下のコマンドを実行します。

bash
sudo certbot --nginx

コマンドを実行すると、Certbotがnginxの設定ファイルを解析し、証明書を適用可能なドメイン名のリストを表示します。

“`
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Which names would you like to activate HTTPS for?

1: example.com
2: www.example.com

Select the appropriate numbers separated by commas and/or spaces, or leave blank to select all options shown (numbered 1 to 2):
“`

ステップ1: ドメイン名の選択

HTTPSを有効にしたいドメイン名の番号をカンマまたはスペース区切りで入力します。表示されているすべてのドメイン名を選択したい場合は、何も入力せずにEnterを押します。もしリストに表示されないドメイン名がある場合は、Certbotがそのドメイン名の設定をnginxで見つけられなかった可能性があります。nginx設定ファイルを確認してください。

Enterを押すと、CertbotはLet’s Encryptへの登録手続きに進みます。

ステップ2: メールアドレスの入力

Let’s Encryptからの重要な通知（証明書の失効が近い場合など）を受け取るためのメールアドレスを入力します。

Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): [email protected]

有効なメールアドレスを入力してください。

ステップ3: 利用規約への同意

Let’s Encryptの利用規約が表示されるので、内容を確認し、同意する場合は A を入力してEnterを押します。

“`

Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.3-September-21-2022.pdf. You must
agree in order to proceed. Pass the –agree-tos flag to acknowledge with
out being prompted.

(A)gree/(C)ancel: A
“`

ステップ4: EFFからのメール購読の選択 (任意)

EFFからのニュースや情報を受け取るかどうかを尋ねられます。任意なので、購読する場合は Y、しない場合は N を入力します。

“`

Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let’s Encrypt project and the non-profit
organization that develops Certbot? We’d like to send you emails about our work
encrypting the web,EFF news, campaigns, and ways to support digital freedom.

(Y)es/(N)o: N
“`

ステップ5: HTTPSへのリダイレクト設定の選択

HTTPでアクセスがあった場合に、自動的にHTTPSへリダイレクトするかどうかを選択します。通常はHTTPSを強制したいので、「2: Redirect」 を選択することを強く推奨します。これにより、http://example.com へのアクセスが自動的に https://example.com へ転送されるようになります。

“`
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP
access.

1: No redirect – Make no changes to the webserver configuration.
2: Redirect – Make all requests redirect to secure HTTPS access. Choose this for
most websites.

Select the appropriate number [1-2] then [enter]: 2
“`

ステップ6: 証明書の取得とNginx設定ファイルの書き換え

ここまでの入力が終わると、CertbotがLet’s Encryptと通信してドメイン認証を行い、証明書を取得します。認証が成功し証明書が発行されると、Certbotは自動的にあなたのnginx設定ファイル（通常は /etc/nginx/sites-available/ や /etc/nginx/conf.d/ ディレクトリ内のファイル）を編集し、取得した証明書のパスなどを追記します。

設定ファイルの書き換え後、Certbotは自動的にnginxをリロードして新しい設定を反映させます。

成功すると、以下のようなメッセージが表示されます。

“`
Deploying certificate for example.com to VirtualHost /etc/nginx/sites-enabled/default

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP
access.

1: No redirect – Make no changes to the webserver configuration.
2: Redirect – Make all requests redirect to secure HTTPS access. Choose this for
most websites.

Select the appropriate number [1-2] then [enter]: 2
Enhancement redirect was enabled for example.com

Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/example.com/privkey.pem
Your certificate will expire on 2023-XX-XX. To obtain a new or tweaked
version of this certificate in the future, simply run certbot again.
To non-interactively renew all of your certificates, run “certbot renew”

If you like Certbot, consider supporting our work:
* Donate: https://certbot.eff.org/donate
* Patreon: https://www.patreon.com/eff

“`

「Congratulations!」と表示されれば成功です。証明書のパスと有効期限が示されます。

ステップ7: 成功の確認

ブラウザであなたのドメイン名に https:// を付けてアクセスしてみてください。アドレスバーに鍵マークが表示され、「保護された通信」となっていることを確認します。また、http:// でアクセスした場合に自動的に https:// へリダイレクトされることも確認します。

さらに、SSLチェッカーサービス（例: Qualys SSL Labs’ SSL Server Test – https://www.ssllabs.com/ssltest/）を使って、サーバーのSSL設定をテストし、セキュリティ評価を確認することをお勧めします。Certbotのデフォルト設定は比較的良好な評価を得られるはずです。

5.2. CertbotによるNginx設定ファイルの変更内容

Certbotは通常、あなたのnginx設定ファイル（例えば /etc/nginx/sites-available/default や /etc/nginx/conf.d/your-site.conf など）をバックアップした上で、以下のような変更を行います。

  • HTTPS (ポート443) 用の server ブロックを追加、または既存のHTTPブロックに追記。
  • listen 443 ssl; ディレクティブを追加。
  • ssl_certificate および ssl_certificate_key ディレクティブに、Certbotが取得した証明書ファイルと秘密鍵ファイルのパスを指定（例: /etc/letsencrypt/live/example.com/fullchain.pem, /etc/letsencrypt/live/example.com/privkey.pem）。
  • Let’s Encrypt証明書で推奨されるSSL設定（ssl_protocols, ssl_ciphers など）を追加。
  • リダイレクトを選択した場合、ポート80の server ブロックに return 301 https://$host$request_uri; のようなリダイレクト設定を追加。

例：Certbotによって変更されたNginx設定の抜粋

“`nginx

HTTP to HTTPS redirect (if chosen)

server {
listen 80;
server_name example.com www.example.com;
# Redirect all HTTP requests to HTTPS
return 301 https://$host$request_uri;
}

HTTPS server block

server {
listen 443 ssl;
server_name example.com www.example.com;

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot

include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

# Your existing configuration for the site goes here
# root /var/www/html;
# index index.html index.htm;
# ...

}
“`

include /etc/letsencrypt/options-ssl-nginx.conf; と ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; は、Certbotがデフォルトで設定する推奨SSLパラメータを読み込むための行です。これらのファイルはCertbotのインストール時に生成されます。これには、安全なTLSプロトコルバージョンや暗号スイートの指定、Perfect Forward Secrecy (PFS) のためのDiffie-Hellmanパラメータなどが含まれます。

5.3. 証明書の取得だけを行う (certonly)

Certbotにnginxの設定を自動で編集させたくない場合や、手動で設定ファイルを編集したい場合は、certonly オプションを使います。この場合、Certbotは証明書を取得するだけで、nginxの設定は自分で行う必要があります。

--nginx プラグインを使って認証だけ行う例：

bash
sudo certbot certonly --nginx -d example.com -d www.example.com

-d オプションで証明書に含めたいドメイン名を指定します。対話モードの場合と同様に、メールアドレスの入力や利用規約への同意などが求められます。成功すると、証明書ファイルと秘密鍵ファイルのパスが表示されます。

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/example.com/fullchain.pem
Key is saved at: /etc/letsencrypt/live/example.com/privkey.pem
This certificate expires on 2023-XX-XX.

この場合、Nginx設定ファイル /etc/nginx/... に以下の内容を手動で追記または変更する必要があります。

“`nginx
server {
listen 80;
listen 443 ssl; # listen 80 と listen 443 ssl をまとめて書くことも可能

server_name example.com www.example.com;

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # Certbotが生成した証明書
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # Certbotが生成した秘密鍵

# 以下の推奨設定も手動で追加することを検討
# include /etc/letsencrypt/options-ssl-nginx.conf; # Certbotが生成したファイルを参照
# ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # Certbotが生成したファイルを参照

# ... 既存のサイト設定 ...

# HTTPからHTTPSへのリダイレクトを手動で設定する場合
if ($scheme != "https") {
    return 301 https://$host$request_uri;
}

}
“`

設定ファイル変更後は、nginxの設定テストと再起動が必要です。

bash
sudo nginx -t # 設定ファイルのテスト
sudo systemctl reload nginx # 設定の再読み込み (または restart nginx)

手動設定はCertbotの自動設定よりも手間がかかりますが、より細かくSSL設定を制御したい場合に有効です。

6. Certbot証明書の自動更新

Let’s Encrypt証明書の有効期間は90日間です。これは意図的に短く設定されており、自動化を促進し、鍵漏洩時のリスクを低減するためです。90日ごとに手動で更新するのは現実的ではないため、Certbotには自動更新機能が備わっています。

6.1. 自動更新の仕組み

Certbotをsnapdまたはパッケージマネージャーでインストールした場合、通常は自動更新のための設定がシステムに登録されます。これは主に cron ジョブまたは systemd タイマーとして実現されます。

登録された自動更新タスクは、定期的に (certbot renew) コマンドを実行します。このコマンドは、システムにインストールされているすべてのCertbot管理下の証明書を確認し、有効期限が30日以内である証明書を自動的に更新しようとします。

更新が成功すると、CertbotはWebサーバー（nginxなど）を再読み込みし、新しい証明書を反映させます。このプロセスは完全に自動で行われるため、一度設定すれば証明書の有効期限切れを心配する必要がなくなります。

6.2. 自動更新設定の確認

自動更新が正しく設定されているか確認しましょう。

  • systemdタイマーの場合 (多くのsystemd採用Linux):
    bash
    sudo systemctl list-timers | grep certbot
    以下のような出力が表示されれば、systemdタイマーで管理されています。

    NEXT LEFT LAST PASSED UNIT ACTIVATES
    Mon 2023-10-26 05:12:00 JST 12h left Sun 2023-10-25 05:12:00 JST 12h ago certbot.timer certbot.service
    この例では、毎日5時12分に certbot.service (実体は certbot renew を実行するユニット) が実行されるよう設定されています。

    certbot.timer の詳細を確認するには：
    bash
    sudo systemctl status certbot.timer

  • cronジョブの場合 (古いシステムや一部の環境):
    bash
    sudo crontab -l | grep certbot
    または /etc/cron.d/certbot ファイルの内容を確認します。
    bash
    sudo cat /etc/cron.d/certbot
    以下のような出力が表示されれば、cronで管理されています。

    “`cron

    /etc/cron.d/certbot: crontab entries for the certbot package

    Upstream recommends attempting renewal twice a day

    Eventually, this will be changed to a systemd timer dedicated to this

    task.

    0 */12 * * * root test -x /usr/bin/certbot -a ! -d /run/systemd/system && perl -e ‘sleep int(rand(3600))’ && certbot -q renew
    ``
    この例では、12時間ごとに    certbot -q renewコマンドが実行されるよう設定されています。-q` は静音モードでエラー以外は出力しません。

通常、Certbotパッケージをインストールすればこれらの設定は自動で行われるため、手動でcronやsystemdタイマーを設定する必要はありません。

6.3. 自動更新のテスト実行

実際に証明書が更新されるか心配な場合は、テスト実行が可能です。

bash
sudo certbot renew --dry-run

このコマンドは、実際の証明書の更新は行いませんが、更新プロセスを最後までシミュレーションします。設定に問題がなければ「The dry run was successful.」のようなメッセージが表示されます。

“`
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/example.com.conf

Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Simulating renewal of an existing certificate for example.com and www.example.com
Performing the following challenges:
http-01 challenge for example.com
http-01 challenge for www.example.com
Waiting for verification…
Cleaning up challenges

new certificate deployed with reread success

The dry run was successful.

“`

このテスト実行でエラーが発生する場合は、自動更新も失敗する可能性があります。エラーメッセージを確認し、原因を特定して対処してください（よくある原因は、ポート80へのアクセスがファイアウォールでブロックされているなど）。

6.4. 更新フックの利用

certbot renew コマンドは、証明書の更新に成功した場合、デフォルトでWebサーバーを再読み込みしようとします。これはnginxプラグインを使用している場合の標準的な動作です。

より高度な制御や、更新前後に特定のスクリプトを実行したい場合は、更新フックを利用できます。これは、Certbotの設定ファイル (/etc/letsencrypt/renewal/your-domain.conf) または certbot renew コマンドのオプションで指定します。

  • --pre-hook: 更新処理の前に実行されるコマンド。
  • --post-hook: 更新処理が成功した後に実行されるコマンド（更新が必要なかった場合は実行されない）。
  • --renew-hook: 証明書が実際に更新された場合に実行されるコマンド。

例えば、証明書更新後にnginxを特定のコマンドで再起動したい場合などに利用できますが、通常nginxプラグインが適切に再読み込みを行ってくれるため、必須ではありません。

例：更新が成功した場合にカスタムスクリプトを実行
bash
sudo certbot renew --renew-hook /path/to/your/script.sh

この設定を恒久的にしたい場合は、renewal設定ファイルに記述します。

7. トラブルシューティング

Certbotの導入や運用中に発生しうる一般的な問題とその対処法です。

7.1. certbot --nginx が失敗する場合

  • Nginx設定ファイルのエラー: CertbotはNginx設定ファイルを解析します。設定ファイルにシンタックスエラーがあると、Certbotが解析に失敗したり、意図しない動作をしたりします。sudo nginx -t で設定ファイルをテストし、エラーがないか確認してください。
  • ファイアウォール: ポート80または443が外部からアクセス可能か確認してください。curl http://your-domain.com/.well-known/acme-challenge/testfile のように、一時的にサーバーに置いたテストファイルに外部からHTTPでアクセスできるか試すのも有効です。
  • DNS設定: ドメイン名がサーバーのIPアドレスを正しく指しているか確認してください。DNSの変更は反映に時間がかかることがあります。
  • Nginxが起動していない/正しく設定されていない: Certbotのnginxプラグインは、nginxが稼働しており、設定ファイルが標準的な構造になっていることを前提とします。ドメイン名に対応する server_name ディレクティブが設定されているか確認してください。
  • 権限の問題: Certbotはシステムファイル（Nginx設定ファイル、証明書保存ディレクトリなど）にアクセス・書き込みを行うため、実行ユーザー（通常はrootまたはsudo権限を持つユーザー）に必要な権限があるか確認してください。

7.2. 証明書は取得できたが、ブラウザで安全な接続にならない/警告が出る

  • Nginx設定が反映されていない: CertbotがNginx設定を自動で変更した場合、通常は自動でリロードされますが、何らかの原因で失敗した可能性があります。手動で sudo systemctl reload nginx を実行してみてください。手動で設定を変更した場合は、設定ミスがないか再度確認し、リロードを忘れていないか確認してください。
  • ポート443がブロックされている: ファイアウォールでポート443が開放されているか確認してください。
  • Mixed Content: HTTPSページの中にHTTPで読み込まれているリソース（画像、CSS、JavaScriptなど）があると、「Mixed Content」としてブラウザが警告を表示したり、リソースの読み込みをブロックしたりします。サイトのコンテンツが全てHTTPSで読み込まれるように修正してください。開発者ツールのコンソールなどでMixed Contentのエラーが表示されます。
  • 古いプロトコルや暗号スイート: Certbotがデフォルトで設定する /etc/letsencrypt/options-ssl-nginx.conf は比較的新しい設定ですが、手動でSSL設定を行った場合、古いSSLプロトコル（SSLv3以下）や脆弱な暗号スイートを許可していると警告の原因になります。SSLチェッカーで設定を確認し、安全な設定に修正してください。OWASPのSSL Configuration Generator ( https://ssl-config.mozilla.org/ ) などを参考に、NginxのSSL設定を強化することをお勧めします。
  • 証明書のファイルパスが間違っている: Nginx設定ファイルで指定している ssl_certificate と ssl_certificate_key のパスが正しいか確認してください。通常は /etc/letsencrypt/live/your-domain-name/ ディレクトリ内のファイルを参照します。

7.3. 自動更新が失敗する

  • 自動更新タスクが登録されていない/実行されていない: cronジョブやsystemdタイマーが正しく登録されており、定期的に実行されているか確認してください (systemctl list-timers または crontab -l)。
  • 認証失敗: 自動更新時にもドメイン認証（通常はHTTP-01チャレンジ）が行われます。更新時にもポート80が外部からアクセス可能である必要があります。Webサイトがダウンしている、Nginxが停止している、ポート80がファイアウォールでブロックされているなどの原因が考えられます。sudo certbot renew --dry-run を実行して、エラー内容を確認してください。
  • Nginxの再読み込み失敗: 証明書は更新できたものの、Nginxの再読み込みに失敗している可能性があります。Certbotのログ (/var/log/letsencrypt/) を確認し、Nginxリロード関連のエラーがないか調べます。手動で sudo systemctl reload nginx が成功するか試してみてください。
  • レート制限: 短期間に何度も証明書の発行や更新に失敗すると、Let’s Encryptのレート制限に引っかかることがあります。レート制限情報は公式サイトで確認できます。テストには --dry-run オプションを利用するようにしてください。
  • 権限: 自動更新タスクが実行されるユーザー（通常はroot）が、Certbotの設定ファイルや証明書ファイル、Nginx設定ファイルにアクセス・書き込み・実行（Nginxリロード）する権限を持っているか確認してください。

7.4. Certbotのログファイル

Certbotの実行に関する詳細は、ログファイルに記録されています。問題発生時には必ずログファイルを確認しましょう。

“`bash
sudo tail /var/log/letsencrypt/letsencrypt.log

またはエディタで開く

sudo less /var/log/letsencrypt/letsencrypt.log
“`

ログファイルには、Certbotの実行内容、Let’s Encryptとの通信、エラーメッセージなどが詳細に記録されています。

8. さらに進んだ設定

CertbotとLet’s Encryptは、基本的なSSL化だけでなく、より高度な設定にも対応しています。

8.1. ワイルドカード証明書

*.example.com のように、特定のドメイン名の全てのサブドメインに有効なワイルドカード証明書もLet’s Encryptで取得できます。ただし、ワイルドカード証明書の取得には DNS-01チャレンジ という認証方法が必要です。これは、指定されたTXTレコードをドメインのDNS設定に追加することでドメイン所有権を確認する方法です。

DNS-01チャレンジは通常手動で行うか、利用しているDNSプロバイダのAPIに対応したCertbotプラグインや外部ツールを利用する必要があります。

例：ワイルドカード証明書 (*.example.com) とベースドメイン (example.com) の両方を取得

bash
sudo certbot certonly --manual --preferred-challenges dns -d *.example.com -d example.com

このコマンドを実行すると、CertbotはTXTレコードの追加を要求し、追加すべき内容とDNSレコードが反映されるまで待つように指示します。DNS設定を手動で変更し、反映されたことを確認してからCertbotの指示に従って進めます。

Certbotには、主要なDNSプロバイダ（Cloudflare, AWS Route 53など）に対応した公式または非公式のDNSプラグインがあり、これを利用するとTXTレコードの追加・削除プロセスを自動化できます。

8.2. ECC証明書

デフォルトでは、CertbotはRSA暗号方式の証明書を取得します。より高速で安全性が高いとされるECC (Elliptic Curve Cryptography) 暗号方式の証明書を取得することも可能です。

ECC証明書を取得するには、--key-type rsa オプションを省略するか、--key-type ec オプションを指定します（現在のCertbotのデフォルトはECかもしれません）。

bash
sudo certbot certonly --nginx -d example.com -d www.example.com --key-type ec

RSAとECCの両方の証明書を同じドメインで取得し、Nginxで両方を提供する（ブラウザが対応する方を選択する）設定も可能です。これにより、古いブラウザとの互換性を保ちつつ、最新のブラウザではより安全で高速なECCを利用させることができます。

8.3. 複数ドメインの管理

Certbotは複数のドメイン名や異なるWebサーバーの設定を持つサーバー上の証明書を一元管理できます。certbot renew コマンドは、システム内の全てのCertbot管理下の証明書に対して更新チェックを行います。

新しいドメイン名を追加して証明書を取得したい場合は、既に他のドメインでCertbotを利用していても、再度 sudo certbot --nginx または sudo certbot certonly --nginx -d new-domain.com のようにコマンドを実行すれば、既存の設定に追加する形で証明書を取得・設定できます。

8.4. テスト環境 (--staging) の利用

本番環境で証明書の発行に失敗を繰り返すと、Let’s Encryptのレート制限に引っかかる可能性があります。設定や手順を確認するためにテストしたい場合は、--staging オプションを付けて実行することで、本番の発行システムではなくテスト環境で証明書を取得できます。テスト環境で発行された証明書はブラウザでは信頼されませんが、Certbotの動作確認には十分です。

bash
sudo certbot --nginx --staging -d example.com

テストで成功したら、--staging オプションを外して本番の発行を行います。

9. まとめ：Certbotで手に入れるSSL化の未来

この記事では、nginxユーザーがCertbotとLet’s Encryptを使って、Webサイトを無料でSSL化し、その運用を自動化するための詳細な手順を解説しました。

なぜSSL/TLS化が必要なのかという基礎から始まり、無料認証局であるLet’s Encryptの仕組み、そしてその証明書を簡単に取得・設定・自動更新できるCertbotの導入と具体的な利用方法を見てきました。特にnginxプラグインを使った自動設定は、わずか数ステップの対話形式で安全なHTTPS環境を構築できる強力な機能です。

CertbotとLet’s Encryptを利用することで、あなたは以下のメリットを享受できます。

  • コストゼロ: SSL証明書の取得・更新費用が無料になります。
  • 運用の自動化: 証明書の取得、設定、そして最も面倒だった更新作業が自動化され、有効期限切れのリスクから解放されます。
  • セキュリティの向上: ユーザーとの通信が暗号化され、データの安全性が確保されます。
  • 信頼性の向上: ブラウザの警告表示がなくなり、サイト訪問者に安心感を与えます。
  • SEO効果: 検索エンジンの評価向上に繋がる可能性があります。
  • 最新技術への対応: HTTP/2など、HTTPSが前提となる新しいWeb技術を利用できるようになります。

Certbotの導入は、現代のWebサイト運用において非常に重要かつ効果的なステップです。この記事で解説した手順やトラブルシューティング情報を参考に、あなたのnginxサーバーでも安全で無料のHTTPS環境を構築・維持してください。一度自動更新が設定できれば、あとはCertbotが代わりに証明書管理を行ってくれるため、あなたはコンテンツ開発やサイト改善といった本来の業務に集中できるようになります。

WebサイトのSSL化は、もはや特別なことではありません。Certbotを使いこなし、安全で信頼性の高いインターネット環境の構築に貢献しましょう。

免責事項

本記事は、CertbotおよびLet’s Encryptを使ったNginxのSSL化に関する一般的な手順を解説したものです。サーバー環境（OS、Nginxバージョン、他の設定など）は多岐にわたるため、全ての場合に完全に適合するとは限りません。記載されたコマンドや設定は、実行前にあなたの環境に合わせて適切に判断・修正してください。作業は必ずご自身の責任において実施してください。設定ミスや予期せぬ問題によりサーバーの動作に影響が出る可能性もゼロではありませんので、重要な設定変更を行う前には必ずバックアップを取得することを強く推奨します。Let’s EncryptおよびCertbotの仕様や推奨事項は変更される可能性がありますので、最新情報は公式ドキュメントも併せて参照してください。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール