運用・管理のベストプラクティス
本ドキュメントでは、ACMEを用いた証明書運用をより安全かつ確実に、そして手間なく行うための推奨事項（ベストプラクティス）を、初級編から上級編まで段階別にご紹介します。
1. 【初級編】まずはここから：確実な自動更新のために
-
いきなり本番実行せず、ドライランでテストする UPKIにはテスト専用のエンドポイント（ステージングURL）が存在しません。設定ミスで発行エラーを繰り返すのを防ぐため、事前にクライアントツールのドライラン機能（
--dry-runなど）を用いて検証することを推奨します。ドライラン実行時は
--serverオプションを必ず指定してくださいCertbot などの ACME クライアントで単に
--dry-runのみをして実行すると、クライアントのデフォルト動作として Let's Encrypt のテストサーバーに接続を試みてしまい、UPKIのEABキーやドメイン検証が正常に動作するかの正しい検証になりません。 UPKIでドライランを行う際は、必ず本番用エンドポイント（--server https://secomtrust-acme.com/acme/）を明示的に指定して実行してください。※ただし、ドライランであっても本番のACMEサーバーと通信を行うため、設定誤りによる認証失敗等はサーバー側のエラー試行回数制限（レートリミット）にカウントされます。「ドライランなら何度失敗しても大丈夫」というわけではないため、事前に設定内容（EAB情報やドメイン名等）に誤りがないか十分に見直してから実行してください。
コマンド例：
- 定期的な動作確認（強制更新テスト）
運用開始直後は、自動更新タスクが意図通りに動き、Webサーバが正しく再起動するかを手動で強制実行（
--force等）して確認してください。
強制更新は実際に再発行を行います（特に acme.sh は鍵設定に注意）
--dry-runと異なり、強制更新（Certbotのcertbot renew --force-renewal、acme.shのacme.sh --cron --force等）は実際にUPKIへ再発行リクエストを送信します。 UPKIのCAは同一の公開鍵での再発行を許可していないため、acme.sh をお使いの場合、発行時に--always-force-new-domain-keyを指定していないと、この強制更新テストで公開鍵が同一の証明書が発行済みのため更新発行を行えませんエラーになります。詳細は acme.sh ガイド を参照してください（Certbot・win-acme はデフォルトで新しい鍵を生成するため、通常この問題は起きません）。 - 定期的な動作確認（強制更新テスト）
運用開始直後は、自動更新タスクが意図通りに動き、Webサーバが正しく再起動するかを手動で強制実行（
2. 【中級編】証明書の有効期限監視
「自動化されているから安心」と放置せず、万が一自動更新が失敗した場合に備えた「監視の仕組み」が必要です。
- 手軽な外部監視の導入（おすすめ） 初学者には、サーバ内部の仕組みを構築するよりも、外部の監視サービス（Uptime Robot など）やクラウドの監視機能（AWS CloudWatch Synthetics 等）を利用した「外形監視」をおすすめします。「対象ドメインの証明書期限が残り14日を切ったらアラートを飛ばす」といった設定が、短時間で簡単に構築できます。
-
通知の自動化（チャットツール等との連携） cronやsystemd timer等の自動更新タスクの実行結果を監視し、エラーが発生した時のみ管理者に通知する仕組みを用意しましょう。
メール通知とチャット連携について
従来のようなOS標準のメール機能（MTA）を用いたエラー通知は、昨今の送信ドメイン認証（SPF/DKIM/DMARCなど）の厳格化に伴い、初学者にとって正しく設定・到達させることが非常に困難になっています。 そのため、現在では自動更新スクリプト内でエラーを検知し、SlackやTeams、LINE WorksなどのチャットツールへWebhook等を利用して通知を送る仕組みの構築や、前述の外部監視サービスによる有効期限監視を頼る方法を強く推奨します。
- 本格的な監視（Zabbix / Prometheus） すでに組織内にZabbixやPrometheus等の統合監視インフラがある場合は、証明書の有効期限をメトリクスとして収集し、一元的にアラートを上げる仕組みを構築してください。
3. 【中級編】複数台サーバでの運用（複雑化を避けるアプローチ）
複数台のWebサーバに「同一の証明書」を配布・共有する仕組み（セキュアな鍵配送）を作るのは、設定が複雑になりセキュリティリスクも伴います。
- ロードバランサ（LB）の活用を検討する 最も推奨されるのは、複数台のサーバの前段にロードバランサ（L7）を配置し、ロードバランサ上で証明書を一括管理（TLSオフロード）する構成です。後段の各サーバに証明書を配る必要がなくなります。
-
各サーバで個別に証明書を取得する ロードバランサがない場合、各サーバーで個別にACMEクライアントを動かしてそれぞれ証明書を取得・更新する方法があります。複雑な同期システムを自作するよりも構成がシンプルになります。
DNSラウンドロビンなどの分散環境におけるHTTP-01の制約
同一のFQDN（例:
www.example.ac.jp）に対して、DNSラウンドロビン等で複数台のサーバーへ直接アクセスを分散させている場合、各サーバーで個別にHTTP-01チャレンジを実行すると認証に失敗します。これは、認証局（CA）からの検証アクセス（ポート80番）が、ACMEリクエストを送信したサーバーとは「異なるサーバー」にルーティングされてしまうためです。このような複数台分散環境で個別取得を行う場合は、HTTP-01チャレンジの代わりに「DNS-01チャレンジ」を利用するか、あるいは各サーバーのWebサーバー設定（リダイレクト・プロキシ機能）を用いて
/.well-known/acme-challenge/へのアクセスを特定の1台の検証用サーバーに集約する（または共有ストレージを利用する）必要があります。
4. 【上級編】セキュアな一元管理と鍵配送
どうしても1台のサーバで取得した証明書を複数台のサーバにコピーしなければならない環境（DNS-01チャレンジの制約等）では、以下の点に留意して安全な配送の仕組みを構築してください。
- セキュアな転送と自動化:
rsync over SSH（鍵認証）や、Ansibleなどの構成管理ツールを用いて、安全かつ自動的に証明書ファイルを同期する。 - 権限の最小化: コピー先のサーバにおいても、秘密鍵のパーミッションは厳格に設定（rootや特定のプロセス所有者のみに読み取り権限を付与）する。
5. 組織としての運用ルール（引き継ぎと管理）
- 登録担当者と利用管理者の引き継ぎ 担当者の異動や退職時には、「誰がUPKIポータルにアクセスできるのか（登録担当者）」と「どのサーバでどのACMEクライアントが動いているか（利用管理者）」のリストを確実に引き継ぐルールを設けてください。
- EAB Credential と証明書の失効（Revoke） EAB Credential は厳重に管理し、不要に使い回さないでください。また、不要になったサーバや侵害が疑われるサーバの証明書は、速やかに失効手続き（Revoke）を行うプロセスを組織内で整備しておきましょう。