TLS証明書更新を学ぶ：HTTP-01とDNS-01 チャレンジの仕組み〜運用設計

Posted at 2026-08-30

動画

当記事の動画です。理解の一助にご参照ください。

はじめに

HTTPS通信を成立させるために不可欠な TLS/SSL証明書 は、定期的な更新作業が求められます。しかし、手作業による証明書管理を継続することには、運用上の重大なリスクや構造的な課題が伴います。

手作業による証明書更新における主な課題は以下のとおりです。

更新忘れ・台帳差異: 更新時期の失念や管理台帳の更新漏れによる期限切れ事故
配備ミス・再読み込み忘れ: 新しい証明書を配置したもののWebサーバーの再読み込みを失念し、古い証明書が配信され続けるトラブル
証明書の短命化（有効期限の短縮）: かつて数年単位だった証明書の有効期間は短縮傾向にあり（Let's Encryptは90日、さらに短期間化の議論も進行中）、手動更新の運用は構造的に持続が困難となっています。

証明書の有効期限が切れると、ブラウザではアクセス時に警告画面が表示され、API連携では接続エラーとなって決済や業務システムが停止し、サービスの信用失墜に直結します。

本記事では、無料かつ自動で証明書を発行できる Let's Encrypt とそのクライアントツール Certbot を対象に、ドメイン所有権の認証方式である 「HTTP-01」 と 「DNS-01」 の仕組みの違い、実践的な選定基準、AWS Route 53を用いた自動化と権限設計、さらにはマルチテナント運用を見据えたセキュアな運用設計までを整理して解説します。

[!NOTE]
※本記事および掲載している図解・スライド資料は、AIを活用して技術仕様やベストプラクティスを調査・整理した知見をもとに構成しています。

1. 基礎概念の整理：Let's Encrypt / ACME / Certbot の役割

証明書の自動化を理解する上で、混同しやすい3つのキーワードを整理しておきましょう。

用語	役割・概要
Let's Encrypt	無料・自動・オープンを掲げる公開認証局（CA: Certificate Authority）。DV（Domain Validation: ドメイン使用権の確認）証明書を発行します。
ACME (RFC 8555)	Automated Certificate Management Environment の略。証明書の注文・認証・発行・失効を自動化するための標準通信規約（プロトコル）です。
Certbot	ACMEプロトコルに準拠し、証明書の申請・更新手続きを自動実行する公式推奨のクライアントソフトウェア（CLIツール）です。

標準プロトコル（ACME）に基づいているため、認証局やクライアントツールは必要に応じて別のものに差し替えることも可能です。

2. 証明書ライフサイクルと発行・更新の流れ

証明書の自動化とは、「単にコマンドを叩いて証明書ファイルをダウンロードすること」ではありません。以下の 8つの工程を一連のサイクル（閉ループ）として自動化 することが求められます。

実務における発行・更新シーケンス

アカウント・注文: Certbotがアカウント鍵と対象FQDNをCAへ送信して注文
認証課題を受領: CAからチャレンジ（HTTPまたはDNS方式の提示とトークン）を受領
認証情報を配置: 指定されたトークンファイルまたはDNSのTXTレコードを公開
CAが確認: CAが外部の複数地点からファイルまたはTXTレコードを検証
CSRを送信: 秘密鍵を手元で生成し、CSR（証明書署名要求）をCAへ提出（秘密鍵は外に出さない）
証明書を取得: 発行された証明書チェーンを受信して保存
配備・再読込: Webサーバーやロードバランサーへ証明書を配置し、サービスを再読み込み
提示内容を確認: 外部からHTTPS接続し、実際に新証明書が提示されているかを検査

[!IMPORTANT]
「確認」の重要性
自動更新ジョブが「成功」で終了しても、Webサーバーの再読み込みに失敗していれば、外部ユーザーには古い証明書が配信され続けます。自動化システムには必ず「外部から実際に新証明書が見えているか」の外形確認までを組み込みましょう。

3. 「HTTP-01」と「DNS-01」の仕組みと比較

ACMEにおいてドメインの所有権を証明する方法（チャレンジ）には、主に HTTP-01 と DNS-01 の2種類があります。

比較項目	HTTP-01	DNS-01	設計上の意味
必要な開放ポート	TCP/80 (HTTP) 必須	不要	外部からのWeb到達性か、DNS更新権限か
DNSの更新権限	通常は不要	必須 (API連携)	API認証情報・IAMの厳格な管理が必要
ワイルドカード証明書	不可	可能 (`*.example.com`)	ワイルドカードが必要ならDNS-01一択
非公開サーバーでの利用	原則不可 (外部到達が必要)	可能	社内・プライベート環境はDNS-01が適合
LB / WAF / CDNの考慮	大きい (転送や遮断に注意)	小さい (Web通信を経由しない)	ネットワーク経路の複雑さで成否が左右される
主なリスク	到達性・ルーティングの変更による失敗	DNS書き換え権限の漏洩	リスクの性質がインフラ側かセキュリティ側か
運用の適性	単純な単一の公開Webサーバー	複数サーバー、非公開環境、集中発行	システムの規模とガバナンス方針で選択

HTTP-01 の仕組みと成立条件

HTTP-01 は、Webサーバーの特定の公開ディレクトリに一時ファイルを配置し、認証局がインターネット経由でそのファイルを取得できるか確認する方式です。

HTTP-01 の成立条件と障害ポイント

HTTP-01 では、DNS解決、L4到達性、L7ルーティングのすべてが正常である必要があります。

レイヤー	確認事項	典型的な失敗原因	対策
DNS	FQDNが公開IPへ正しく解決されるか	内部IPが返る、古いA/AAAAレコード	権威DNSと世界的な名前解決伝播を確認
Firewall	インターネットからの `TCP/80` が許可されているか	ポート80閉塞、特定送信元IPのみ許可	検証時および更新時にもポート80を開放
Load Balancer	チャレンジパスが正しいバックエンドへ届くか	複数台構成でファイルが置かれていない別インスタンスへルーティング	共有ストレージの利用、またはチャレンジパスのみ専用solverへ転送
WAF / CDN	challenge URLへのアクセスを改変・遮断しないか	Bot遮断、Basic認証、CAPTCHA	`/.well-known/acme-challenge/*` を除外設定
Redirect	リダイレクトが正常に処理されるか	特殊な別ポートへの転送、リダイレクトループ	`http://` から `https://` への単純な301/302リダイレクトにとどめる
IPv6	AAAAレコードが設定されている場合に応答可能か	IPv6のWebサーバー設定漏れ	AAAAレコードの通信疎通を確認するか、不要なら削除

[!TIP]
「ポート80を開ける＝危険」ではありません。 ポート80の開放と、HTTPでコンテンツを平文配信することは別の話です。/.well-known/acme-challenge/ のパスのみを最小限で公開し、それ以外の通信はすべて HTTPS (ポート443) へリダイレクトすれば、実際のコンテンツがHTTPで配信されることはなく、チャレンジのトークンも一時的かつ公開前提の値のため盗聴リスクはありません。

チャレンジパスのみを公開するWebサーバー設定例（nginx）

以下のように設定すれば、ポート80で公開されるのはチャレンジ用の一時トークンファイルのみで、それ以外のリクエストはすべてHTTPSへリダイレクトされます。トークンファイルは検証完了後にCertbotが自動で削除するため、常時公開されるコンテンツはありません。

server {
    listen 80;
    server_name example.com;

    # ACME チャレンジのパスだけ応答する
    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    # それ以外はすべて HTTPS へリダイレクト
    location / {
        return 301 https://$host$request_uri;
    }
}

DNS-01 の仕組みとDNSの基礎知識

DNS-01 は、対象ドメインのDNS（TXTレコード）に認証局から指定されたトークンを書き込み、認証局がDNS参照して検証する方式です。

Webサーバーと直接通信しないため、サーバーが社内ネットワーク内にあっても証明書が発行可能 であり、ワイルドカード証明書（*.example.com）も取得可能 です。

押さえておきたいDNS解決の基礎

CertbotがAPI経由で操作すべきは 「権威DNS」 です。レジストラ側の設定画面でDNSを編集しても、NSレコードが委譲されていれば反映されません。

レジストラ (お名前.com, Google Domains等): ドメインの登録窓口。親ゾーンへどの権威DNSに委譲するか（NS設定）を管理します。
権威DNS (AWS Route 53, Cloudflare等): Hosted Zone内の各レコード（A, CNAME, TXT）を実際に回答するサーバーです。

Public DNS と Private DNS の違い

認証局（Let's Encrypt）はインターネット側から問い合わせを行うため、公開DNS（Public Hosted Zone）に登録されたレコードのみが観測可能 です。

Public Hosted Zone: インターネットから参照可能。HTTP-01の名前解決やDNS-01のTXT検証に利用されます。
Private Hosted Zone / 社内AD DNS: VPCや社内ネットワークからのみ参照可能。公開CAからは見えないため、ここにTXTを置いても認証は通りません。
内部サーバーでの活用: サーバー自体は社内専用であっても、公開可能なドメイン配下のPublic DNSにTXTレコードを公開できれば、DNS-01による正規証明書の発行が成立します。

4. AWS Route 53 を利用した DNS-01 自動化と権限設計

ここからは、AWS Route 53 と公式プラグイン certbot-dns-route53 を用いた実践的な自動化手法とセキュリティ設計を解説します。

1. Certbotコマンド例

certbot certonly \
  --dns-route53 \
  -d example.com \
  -d "*.example.com" \
  --agree-tos \
  --email admin@example.com \
  --non-interactive

certonly: Webサーバーの設定書き換えは行わず、証明書の取得・更新のみを行う安全なモード
--dns-route53: Route 53専用の公式DNS認証プラグインを指定（AWS SDKを通じて自動でTXTレコードの追加・待機・削除を実行）
-d: 発行対象のドメインを指定（ワイルドカードとルートドメインの併用が可能）

2. 最小権限のIAMポリシー設計

サーバー上に長期利用のアクセスキー（Access Key / Secret Key）を平文で置くのはセキュリティ上の大きなリスクです。EC2やECS、Lambdaなどの IAMロール（一時クレデンシャル） を活用しましょう。

Certbotに必要なRoute 53の権限は以下の3つです。

route53:ListHostedZones (ゾーン一覧の取得)
route53:GetChange (DNSレコード変更の完了確認)
route53:ChangeResourceRecordSets (TXTレコードの作成および削除)

最小権限ポリシーの例

Zone変更の権限は、必ず 対象のHosted Zone ARNに限定 します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "route53:ListHostedZones",
        "route53:GetChange"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "route53:ChangeResourceRecordSets"
      ],
      "Resource": "arn:aws:route53:::hostedzone/Z1234567890EXAMPLE"
    }
  ]
}

3. 他社アカウント・マルチテナントでのクロスアカウント運用

運用代行やSaaS基盤などで「Certbotを実行する基盤」と「顧客のRoute 53」が別アカウントにある場合、IAMの AssumeRole（一時的な権限の委譲） を利用します。

メリット: 顧客側のアカウント内に長期キーを発行・受領する必要がなく、信頼ポリシーの解除だけで即座にアクセスを遮断できます。
混同代理問題の対策: 第三者運用においては、AssumeRoleの信頼ポリシーに sts:ExternalId 条件を必須として設定します。
監査性: AWS CloudTrailにより、誰がいつAssumeRoleを行い、どのレコードを変更したかを追跡可能です。

4. 主要DNSプロバイダー比較

https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/517421/eb1722ae-59ab-4acf-b790-4b994cbb94b3.jpeg" width="80%">

プロバイダー	主な認証方式	権限制御の単位	Certbot連携	注意点・ベストプラクティス
AWS Route 53	IAM Role / STS	IAM Policy + Zone ARN	公式 `certbot-dns-route53`	長期キーを避け、EC2/ECS IAMロールで短期クレデンシャルを利用
Cloudflare	API Token	Zone・操作（DNS:Edit）に限定	公式 `certbot-dns-cloudflare`	全権限を持つGlobal API Keyは使用せず、特定Zone限定のAPI Tokenを発行
Google Cloud DNS	Service Account / ADC	IAM Role + Project / Resource	公式 `certbot-dns-google`	鍵ファイル保管を避け、Workload Identityの活用を推奨
Azure DNS	Managed Identity / SP	Azure RBAC + Resource Scope	外部プラグイン (要保守確認)	マネージドIDを活用。外部プラグイン利用時はメンテナの更新頻度を確認

5. 運用設計とセキュリティ統制（8つの柱）

DNSの書き換え権限や秘密鍵は、組織にとって最重要クラスの機密資産です。DNS認証情報が漏洩した場合、攻撃者が正規の証明書を自由に発行し、完全な中間者攻撃（なりすまし）を成立させることが可能 になってしまいます。

認証情報の保護: HashiCorp Vault等による動的取得や、クラウドの短期クレデンシャル（IAM Role / STS）を利用する。
最小権限の徹底: 特定のHosted Zone、特定のアクションのみに権限を絞り込む。
秘密鍵のライフサイクル: 秘密鍵はRunnerやローカル環境で生成し、平文で外部転送しない。保管時は暗号化する。
監査ログの相関: 自動化ジョブの実行ログ、CloudTrail、DNS変更ログを一元管理し、不正な証明書発行がないかを監査可能にする。
多層監視: 「証明書の残存有効日数」「ジョブの実行成否」「外部から見える提示証明書」「APIレート制限」を監視する。
復旧手順（Runbook）の整備: 自動更新失敗時の再試行フロー、手動更新手順、ロールバック計画を定義する。
変更管理と事前検証: 本番適用前に Let's Encrypt の Staging環境や --dry-run オプションでテストを実施する。
ガバナンスとCAA: DNSに CAAレコード（issue "letsencrypt.org" 等）を明示し、意図しない認証局からの不正発行を防止する。

6. シナリオ別・規模別の選定ガイド

シナリオ別選定マトリクス

利用シナリオ	推奨方式	選定理由	前提条件・注意点
単一の公開Webサーバー	HTTP-01	構成が極めてシンプルでDNS権限が不要	ポート80への到達性を維持できること
ALB / WAF / CDN配下	HTTP-01 または DNS-01	パス制御が容易ならHTTP-01、複雑ならDNS-01	WAFの除外設定や複数バックエンドでの整合性
ワイルドカード証明書	DNS-01	HTTP-01ではワイルドカード発行が不可	DNS APIによるレコード自動更新環境
社内専用Webシステム	DNS-01	Webサーバーへの外部到達性が一切不要	パブリックDNSにTXTレコードを反映できること
SaaS基盤 / 複数ドメイン	DNS-01	中央のRunnerからまとめて一括更新可能	適切なゾーン委譲とAPIレートリミットの管理
DNS APIが提供されない環境	HTTP-01	DNSの手動更新は定期運用に耐えないため	期限切れ前に確実に疎通できる経路の確保

規模別の推奨アーキテクチャ

システム規模の拡大に合わせて、段階的に自動化とガバナンスのレベルをステップアップさせていきます。

小規模 (数台〜): 各サーバー上で Certbot を動かし、systemd timer や cron で定期更新。HTTP-01中心で運用開始（ただし監視は初日から必須）。
中規模 (十数台〜数十台): 集中Runnerを用意し、DNS-01を用いて一括発行。証明書・鍵はVault等で管理し、各サーバーへ安全に配布。
大規模・マルチテナント: Ansible Automation Platform (AAP) や CI/CD 等のワークフロー基盤で台帳（CMDB）と連動。顧客ごとにIAMロールとVaultパスを完全分離し、発行・配備・外形検証・ログ監査までを全自動化。

7. まとめ

Let's Encrypt と Certbot によるTLS証明書管理において、最も大切なのは 「単に発行できるか」ではなく「3年後も破綻せず自動で回り続けるか」 という運用設計の視点です。

方式選定: シンプルな単体公開Webなら HTTP-01、ワイルドカードや非公開サーバー、大規模な集中管理なら DNS-01 を選定する。
セキュリティ: DNS書き換え権限は最重要機密。長期アクセスキーを避け、IAMロール・短期クレデンシャル・最小権限のARN指定 を徹底する。
運用: 「発行」で終わらせず、「配備」と「外部からの提示確認」まで含めた 閉ループ を構築する。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

TLS証明書更新を学ぶ ：HTTP-01とDNS-01 チャレンジの仕組み〜運用設計

動画