Certbot設定ガイド
1. はじめに（Certbotとは？）
Certbot は、EFF (Electronic Frontier Foundation) が提供する最も代表的で広く利用されているACMEクライアントです。多様なプラグインが用意されており、多くのLinuxディストリビューションで標準的にサポートされています。
本ガイドでは、Linux環境において管理者権限（root等）で作業することを想定しています。
事前に準備するもの
作業を開始する前に、以下を準備・確認してください。
- EAB Credential（MAC Key・Key ID）：所属機関の登録担当者に依頼して発行を受けてください
- 証明書を取得するドメイン名（例:
www.example.ac.jp） - 対象サーバーの管理者権限（root等）
- TCP 80番ポートへの外部からのアクセスが許可されていること（ファイアウォール設定の確認）
2. インストール手順
お使いのOSのパッケージマネージャ（apt, dnfなど）を利用してインストールします。本ガイドでは apt / dnf によるインストールを対象とします。
Ubuntu / Debian の場合：
CentOS / RHEL系 の場合（EPELリポジトリを利用）：
3. UPKI環境へのアカウント登録（EABの紐付け）
UPKI環境を利用するためには、「EAB（外部アカウントバインディング）」により、正当な権限があることを証明する必要があります。
実際にACMEクライアントを操作する方（利用管理者）は、設定を行う前に、所属機関の登録担当者に依頼して「EAB Credential（MAC Key および Key ID）」を発行してもらい、受け取っておく必要があります。
EAB Credentialの使い切りと、サーバー移転時の対処について
UPKI環境で発行された EAB Credential は一度のアカウント登録にのみ使用できます。登録完了後は再使用できません。
サーバーを移転・再構築する場合は、Certbotの設定ディレクトリ（/etc/letsencrypt/）ごとコピーするか、登録担当者に新しい EAB Credential の発行を依頼してください。
登録担当者から受領した EAB Credential を用いて、以下のコマンドを実行しアカウントを登録します。（メールアドレスはご自身の管理用アドレスに変更してください）
Credentialの取り扱いに注意
--eab-hmac-key に指定した値はシェルのコマンド履歴に残ります。
作業完了後は history -c 等でコマンド履歴を削除することを推奨します。
sudo certbot register \
--server https://secomtrust-acme.com/acme/ \
--email my@example.com --agree-tos --no-eff-email \
--eab-kid "【取得したKey ID】" \
--eab-hmac-key "【取得したMAC Key】"
登録に成功すると、以下のようなメッセージが表示されます。
4. 証明書の発行と自動更新の設定
アカウント登録が完了したら、証明書を発行します。
初学者の方には、すでに稼働しているWebサーバの公開フォルダ（ドキュメントルート）を利用する「Webrootモード」が安全で確実です。本ガイドで使用するWebrootモード（--webroot）は、certbot-nginx や certbot-apache などの追加プラグインを必要としません。
通信エラーになる場合（ポート80番と競合に注意）
発行処理では外部から TCP 80番ポート へ通信が行われます。ファイアウォールでブロックされていないか確認してください。 また、既存のWebサーバを稼働させたままCertbotの「Standaloneモード」を使用するとポート競合エラーになります。本ガイドで紹介している「Webrootモード」を利用することで、Webサーバを止めずに安全に取得できます。
手順1：証明書の発行
以下は、www.example.ac.jp の証明書を発行する場合の例です。
sudo certbot certonly --webroot \
--server https://secomtrust-acme.com/acme/ \
-w /var/www/html \
-d www.example.ac.jp \
--key-type rsa
鍵タイプ（--key-type）の指定について
Certbotはバージョン2.0以降、生成する鍵のデフォルトが ECDSA に変更されています。一方で、発行できる鍵タイプは EAB Credential 発行時に指定した証明書プロファイルに依存します。
UPKI環境では RSA プロファイルが選択されているケースが多いため、本ガイドでは --key-type rsa を明示しています。これを付けずに実行すると、ドメイン所有確認（チャレンジ）は成功するものの、証明書発行（finalize）の段階で次のようなエラーになる場合があります。
（サーバーからは "type":"urn:ietf:params:acme:error:malformed" / 異常終了 が返されます）
申請時に ECDSA プロファイルを指定した場合は、--key-type rsa は不要です。その場合はオプションを外すか、--key-type ecdsa を指定してください。ご自身がどちらのプロファイルで申請したか不明な場合は、所属機関の登録担当者にご確認ください。
成功すると、/etc/letsencrypt/live/www.example.ac.jp/ ディレクトリ内に証明書ファイルが生成されます。
| ファイル名 | 用途 |
|---|---|
fullchain.pem |
サーバー証明書＋中間証明書（Webサーバーの証明書設定に使用） |
privkey.pem |
秘密鍵 |
cert.pem |
サーバー証明書のみ（通常は fullchain.pem を使用） |
chain.pem |
中間証明書のみ |
実際にファイルが生成されたかを、以下のコマンドで確認できます。
証明書ファイルのパスについて
/etc/letsencrypt/live/<ドメイン名>/ 配下のファイルは、実体（/etc/letsencrypt/archive/ 配下）へのシンボリックリンクです。更新時にはリンク先が自動で最新の証明書に切り替わるため、Webサーバには必ず live 配下のパスを指定してください。archive 配下を直接指定すると、更新後に古い証明書を参照し続けてしまいます。
次に、Webサーバの設定ファイルに上記の証明書パスを指定します。設定する場所（HTTPS用のサーバーブロック／バーチャルホスト）の例を以下に示します。お使いの環境のドメイン名・ファイルパスに読み替えてください。
Nginx の場合
すでにHTTPS（443番）の server ブロックがある場合は、その中の ssl_certificate / ssl_certificate_key の行を書き換えます。まだ無い場合は、新しい .conf ファイル（例: /etc/nginx/conf.d/ssl.conf）を作成してください。conf.d/ 配下の .conf は nginx が自動的に読み込みます（Debian/Ubuntu系では /etc/nginx/sites-available/ に作成し sites-enabled/ へリンクする方式もあります）。
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name www.example.ac.jp;
# Certbotが発行した証明書（fullchain）と秘密鍵
ssl_certificate /etc/letsencrypt/live/www.example.ac.jp/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/www.example.ac.jp/privkey.pem;
# （以下、root や location など既存の設定を続けてください）
root /var/www/html;
index index.html;
}
設定を反映します（nginx -t で構文チェックしてからリロード）。
Apache の場合
設定ファイル例: /etc/httpd/conf.d/ssl.conf（RHEL系）、または /etc/apache2/sites-available/example-le-ssl.conf（Debian/Ubuntu系）
<VirtualHost *:443>
ServerName www.example.ac.jp
SSLEngine on
# Certbotが発行した証明書（fullchain）と秘密鍵
SSLCertificateFile /etc/letsencrypt/live/www.example.ac.jp/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.example.ac.jp/privkey.pem
# （以下、DocumentRoot など既存の設定を続けてください）
DocumentRoot /var/www/html
</VirtualHost>
fullchain.pem を使えば中間証明書の別指定は不要です
fullchain.pem にはサーバー証明書と中間証明書が含まれているため、Apache 2.4.8 以降では SSLCertificateChainFile（中間証明書の個別指定）は不要です。SSLCertificateFile に fullchain.pem を指定するだけで完結します。
設定を反映します（configtest で構文チェックしてからリロード）。Debian/Ubuntu系ではサービス名が httpd ではなく apache2 の場合があります。
手順2：更新後のWebサーバー自動再読み込みを設定する（必須）
Certbotをインストールすると、OSの自動実行ツール（systemdタイマーやcron）に証明書更新のジョブが自動的に登録されます。通常は有効期限まで残り1/3（有効期間90日なら約 30日前）になると自動で更新処理が行われます。
更新タイミングと ARI について
上記の「残り1/3」は目安です。Certbot 4.1.0 以降は ARI（ACME Renewal Information）に対応しており、CAが対応している場合は既定で有効になります。UPKIのCAは ARI に対応しているため、対応バージョンのCertbotでは、CAが提示する更新推奨期間（suggestedWindow）に従って、より最適なタイミングで更新します。
いずれの場合も、その時期が来るまで certbot renew は「まだ更新は不要」と判断してスキップします（正常な動作です）。動作確認で今すぐ挙動を見たい場合は、次の手順3の --dry-run を使用してください。
ただし、証明書ファイルが新しくなった後にWebサーバを再読み込みさせる必要があります。Certbot には「更新成功後に自動実行するスクリプト」を配置するための専用ディレクトリ（/etc/letsencrypt/renewal-hooks/deploy/）があります。ここにスクリプトを置くことで、更新のたびに確実に実行されます。
① スクリプトファイルを作成する
以下のコマンドでエディタを開きます。
エディタが開いたら、以下の内容を入力してください。
（Apacheの場合は nginx を httpd または apache2 に読み替えてください）
入力後、Ctrl+O → Enter で保存し、Ctrl+X でエディタを終了します。
② 実行権限を付与する
作成したスクリプトに実行権限を付与します。
③ 動作を確認する
スクリプトを手動で実行し、エラーなく完了することを確認します。
エラーが出なければ設定完了です。次回以降の証明書更新時に、このスクリプトが自動で実行されます。
手順3：ACMEチャレンジ（ドメイン所有確認）の動作を確認する（推奨）
実際のUPKIサーバーへ証明書発行リクエストを送信し、ドメイン所有確認（ACMEチャレンジ）が正しく動作するかを確認できます。取得した証明書はWebサーバーにインストールされません。
成功すると、以下のように表示されます。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/www.example.ac.jp.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Simulating renewal of an existing certificate for www.example.ac.jp
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations, all simulated renewals succeeded:
/etc/letsencrypt/live/www.example.ac.jp/fullchain.pem (success)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
--dry-run オプションについて
--dry-run は証明書の発行リクエストを実際にUPKIサーバーに送信し、ドメイン所有確認などの全プロセスを検証するオプションです。
発行履歴には記録されますが、証明書ファイルのWebサーバーへのインストールは行われません。
UPKI環境では --server オプションの指定が必要です。
問題なく完了すれば Congratulations, all simulated renewals succeeded と表示されます。
このコマンドで確認できないこと
--dry-run では証明書のインストールが行われないため、手順2で設定したWebサーバーの自動再読み込み（deploy-hook）が実行されるかどうかは確認できません。
deploy-hookの動作確認は、手順2③のスクリプト手動実行で代用してください。
5. 公式マニュアル
本ガイドよりも詳しい設定や応用的なオプションについては、UPKI電子証明書発行サービスの公式マニュアルを参照してください。