SSL/TLS証明書の有効期限短縮に備える ― ACMEとAWSでワイルドカード証明書を自動更新・集約する方法

はじめに

こんにちは。エンジニアリングチームの「いかろちゃん」こと清水です。 SSL/TLS証明書の最長有効期間が今後、大幅に短縮されることが決定しています。この変更により、従来は年1回で済んでいた証明書更新作業は、今後は年7〜8回以上の対応が必要になります。それに伴い、運用負荷は大きく増加すると考えられます。特に、ワイルドカード証明書を利用して複数のサーバーやサービスへ証明書を配布している環境では、影響はより深刻です。更新のたびに広範囲へ反映が必要となるため、手動による運用は現実的ではなくなります。本記事では、弊社内で構築したACMEプロトコルを使ったワイルドカード証明書の自動更新・集約システムの設計と実装のポイントをご紹介します。

SSL/TLS証明書の最長有効期限短縮のスケジュールと背景

これまで、SSL/TLSサーバー証明書の最長有効期間は398日（約13か月）とされていましたが、すでに2026年3月15日に第一回の短縮が行われ、200日となっています。今後、段階的にさらに短縮されて最終的には47日まで短縮されます。スケジュールは以下の通りです。

〜 2026年3月14日: 398日(元々の期間)
2026年3月15日〜: 200日(第1段階の短縮)
2027年3月15日〜: 100日(第2段階の短縮)
2029年3月15日〜: 47日(最終目標）

そもそもなぜ、CA/BフォーラムはSSL/TLS証明書の有効期間を短縮することを決定したのでしょうか。その最大の目的は「セキュリティ強化」です。具体的には以下の3つが挙げられます。

秘密鍵漏洩時の影響軽減: 万が一、サーバーの秘密鍵が漏洩した場合、有効期間が長い証明書ほど、攻撃者に不正利用（中間者攻撃やフィッシングなど）される期間が長くなってしまいます。有効期間を短く保つことで、悪用可能な期間を狭めることができます。
暗号技術の進化や脆弱性への迅速な対応: 暗号技術や攻撃手法は日々急速に進化しています。今後新たな脆弱性が発見され、インターネット全体の証明書を早急に入れ替える必要性が生じた際、長期間有効な証明書が多数存在していると、安全な新規格への移行に多大な時間がかかってしまいます。
証明書の認証情報の信頼性向上: 有効期間が長いと、組織の変更やドメインの譲渡などが行われた後も、古い証明書が有効なまま残り続けるリスクがあります。短いサイクルで認証を行うことで、証明書の信頼性を常に高く保つ狙いがあります。

SSL/TLS証明書の最長有効期限短縮に伴う、ワイルドカード証明書の運用課題と自動化要件

SSL/TLS証明書の最長有効期限短縮に伴いワイルドカード証明書についても同様に最長有効期限が短縮されます。ワイルドカード証明書は主に同一ドメインに属するサブドメインを複数運用する環境で利用されます。このような証明書を利用する環境は、大規模な構成が想定されます。シングルクラウドの場合は対象クラウドにて自動更新まで含めた証明書の管理ソリューションが提供されていることが多いです。一方、マルチクラウドにて多様な環境が共存する場合、クラウド固有の証明書管理機能のみで証明書の自動更新対応を行うのは困難です。さらに、無料の証明書ではなく商用の証明書（商用CA）を利用したいという要件や、監査証跡の記録が求められるケースも少なくありません。

有効期間の短縮により手動更新の工数が増大するため、現実的な運用は困難になります。また、自動更新に利用されるACMEプロトコルの仕様により、複数箇所で利用されるワイルドカード証明書の自動更新時はそれぞれで更新リクエストのタイミングが被らないように気をつける必要があります。そのため、排他制御をしつつ個別に取得するよりも、一箇所で集約管理すると効率的です。

まとめると、サブドメインを複数運用する環境でのSSL/TLS証明書の自動更新を行う際は、以下要件を満たすことが理想的です。

ワイルドカード証明書の自動更新が可能なこと
商用CAが利用できること
異なる環境に対応できること
一箇所に集約可能なこと
証跡が残せること

なお、弊社の社内システムはシングルクラウドではなくマルチクラウドを用いて運用しており、商用のワイルドカード証明書の自動更新・配布を実現する必要がありました。これらの課題を一気に解決するため、AWS環境上に証明書のライフサイクル全体を自動化するシステムを設計・構築しました。

ACMEプロトコルと商用ワイルドカード証明書についての技術的背景

実装の詳細を解説する前に、SSL/TLS証明書の自動更新に利用するACMEプロトコルと、それを用いたワイルドカード証明書更新の概要を説明します。

ACMEプロトコルとは

ACME（Automatic Certificate Management Environment）はRFC 8555で標準化された証明書の自動発行・更新プロトコルです。Let's Encryptが普及のきっかけを作り、現在ではJPRSなど多くの商用CAも対応しています。

ACMEプロトコルによる証明書の自動更新は、利用者側の「ACMEクライアント」と、認証局側の「ACMEサーバー」が通信し合うことで実現されます。ACMEプロトコルにてSSL/TLS証明書を発行する際、ドメインの所有権を証明するための認証手続きのことを「チャレンジ」と呼びます。まとめると、取得元のACMEクライアントが、認証局のACMEサーバーに対してチャレンジを行い、証明書を自動取得します。

EAB(External Account Binding)について

商用CAでACMEサービスを使う場合、EAB（External Account Binding）と呼ばれるACMEアカウントを既存の商用CAアカウントと紐付けるための仕組みを使います。プログラムから自前でEAB認証を実装する場合、処理の順序に注意が必要です。処理の流れは以下の図の通りです。

EAB認証とACMEアカウント発行までのシーケンスダイアグラム

あらかじめ認証局あるいはその代理店から、鍵識別子（KID）とHMACキーという認証情報を取得して使用します(図中①、②)。その後、クライアント側でACMEアカウントの認証に利用するキーペア（秘密鍵と公開鍵）を作成します(図中③)。次に、その公開鍵に対して取得したKIDとHMACキーを用いて署名（JWS: JSON Web Signature）します(図中④)。この署名データをアカウント登録リクエストに含めて認証局側へ送信(図中⑤)することで、アカウント作成と既存CAアカウントとの紐付けが完了します(図中⑥)。紐付けが完了して以降はキーペアをACMEアカウントのログイン情報として利用します。

Certbotやacme.sh等のクライアントを利用する場合、鍵の発行から署名までの処理が内部で自動的に行われるため、ユーザーは特に意識する必要がありません。

ワイルドカード証明書とDNS-01チャレンジについて

ACMEのチャレンジには以下の2つがあります。

HTTP-01チャレンジ：Webサーバー上に指定されたファイルを配置して所有権を証明する方式
DNS-01チャレンジ：DNSに指定されたレコードを追加して所有権を証明する方式

ワイルドカード証明書をACMEプロトコルを用いて取得するには、DNS-01チャレンジが必須です（HTTP-01チャレンジでは発行できません）。DNS-01チャレンジの流れは以下の通りです。

ACMEサーバーがトークンを発行
ACMEクライアントが_acme-challenge.{ドメイン}のTXTレコードへ、トークンから計算される値を設定
ACMEサーバーがDNSの名前解決によりトークンを確認し、ドメイン所有権を証明
証明書を発行

1のトークンは、ランダムな値であることがRFC 8555により定められています。そのため、チャレンジごとにTXTレコードへ設定すべき値も異なります。2のTXTレコード設定値は、ACMEアカウントの公開鍵（JWK Thumbprint）とトークンを結合した文字列のSHA-256ダイジェストをBase64urlエンコードした値です。

CNAME委譲について

DNS-01チャレンジでは_acme-challenge.{ドメイン}にTXTレコードを書き込む必要があります。しかし、環境によっては「ドメインの権威DNSがAPI更新に対応していない場合」や、「本番環境の更新権限を自動化システムと切り離したい場合」などがあります。ここで利用する技術が、CNAMEレコードを利用した事実上の権限委譲（別名解決による権限分離）です。厳密なDNSの委譲（NSレコード）ではありませんが、ACMEの文脈では慣例的に「CNAME委譲（CNAME Delegation）」と呼ばれます。本記事でも「CNAME委譲」と呼称します。

DNSの仕様（RFC 1034）では、リゾルバはTXTレコードを名前解決する際もCNAMEチェーンを透過的に辿ると定義されています。つまり_acme-challenge.{ドメイン}がCNAMEを返せば、リゾルバはその先のレコードを再帰的に解決します。ACMEの仕様（RFC 8555 Section 8.4）もこの挙動を明示的に認めています。「CAはDNS-01チャレンジの検証時にCNAMEチェーンを辿らなければならない」と規定されているため、ACMEサーバー側はCNAMEを含む応答を正常に処理できます。

この性質を利用したツールとしてはacme-dns（https://github.com/joohoi/acme-dns）がよく知られています。専用サーバーを立てずとも、Amazon Route 53等のマネージドDNSサービスを使えば同様の仕組みを実現可能です。

アーキテクチャ：ハブ＆スポーク型の証明書管理

前述したように弊社の社内システムはマルチクラウドで構成されています。そのため、各システムがバラバラに証明書を取得する方式では不便が生じることが予想されました。これらを踏まえ、ワイルドカード証明書を自動更新・集約する仕組みを設計・構築しました。集約先としては弊社で採用実績の多いAWSを利用する方針としました。

全体構成

まずは本システムのアーキテクチャについて解説します。設計のコンセプトは、AWS Secrets Managerに証明書を集約するハブ＆スポーク構成です。

ハブ（AWS）: AWS LambdaがACMEで証明書を取得し、AWS Secrets Managerに保存する
スポーク（各環境）: IAM Roles Anywhereで認証し、AWS Secrets Managerから証明書を取得する

アーキテクチャ図は以下のようになります。

この構成を採用した最大の理由は「権限の分離」と「運用の手離れ」です。証明書の発行やDNS操作といった強力な権限を伴う処理は、すべて中央の「ハブ」に閉じ込めます。各サーバーなどの「スポーク」には、自身の証明書を読み取るだけの最小権限しか与えない設計にしています。各スポーク側は、ハブ側での証明書の更新処理を意識することなく、証明書を利用できます。

システム全体の動きは、大きく分けて以下の「2つの独立したフロー」で構成されています。

証明書更新フロー（ハブ側の処理）

EventBridge Schedulerを起点とする、証明書の取得・更新プロセスです。図の左半分から中央にかけての処理にあたります。

起動: Amazon EventBridge Schedulerが毎日定時にAWS Lambdaを自動起動
Lambdaによる処理
- 2.1. 有効期限チェック: 起動したLambdaが設定を読み込み、管理対象ドメインごとの証明書有効期限をチェック
- 2.2. アカウント準備: ACMEアカウント情報がない場合（初回起動時など）は商用CAとのEAB紐付けを実施してアカウントを準備し、アカウントキーは別途AWS Secrets Managerに保存して次回以降は再利用
- 2.3. チャレンジ実行: 更新が必要な場合、認証局と通信してDNS-01チャレンジを開始し、Route 53のTXTレコードを書き換えてドメイン所有権を証明
- 2.4. 保存: 新しく発行された証明書と秘密鍵を取得し、AWS Secrets Managerに新しいバージョンとして安全に保存

証明書取得フロー（スポーク側の処理）

各環境（オンプレミスや他クラウドの仮想マシン）が、最新の証明書を取得するプロセスです。図の右半分の処理にあたります。

認証: スポーク環境のサーバーが、IAM Roles Anywhereを利用して自身のクライアント証明書で認証し、一時的なAWSアクセス認証情報（STSトークン）を取得
取得: 取得した権限を用いてAWS Secrets Managerへアクセスし、自身に必要なドメインの証明書を取得(Pull)

このPull操作を含め、AWS Secrets Managerへのアクセス履歴はすべてAWS CloudTrailによってロギングされ、監査証跡として残ります。

各コンポーネントの役割

構成するコンポーネントは以下の通りです。

Amazon EventBridge Scheduler: 毎日定時にAWS Lambdaを自動起動するスケジューラー。再試行ポリシーとDLQを組み合わせて信頼性を確保
AWS Lambda: システムの中核。ACMEチャレンジ実行・証明書取得・AWS Secrets Managerへの保存を担当
Amazon Route 53: DNS-01チャレンジ用TXTレコードの書き込み先
AWS Secrets Manager: 証明書・秘密鍵を暗号化保管し、バージョン管理も提供。スポーク環境はここに読み取り専用でアクセスし証明書を取得
AWS CloudTrail: AWS Secrets Managerへの全APIコールをS3に記録し、監査証跡として機能
IAM Roles Anywhere: スポーク環境がクライアント証明書を使ってAWS一時認証情報を取得するための仕組み。アクセスキーの配布が不要
AWS SQS DLQ: AWS Lambdaが失敗した際にイベントを保存し、後から原因調査やリトライを可能にする仕組み

実装上のポイント

次に本システムを実装する上での技術的判断や実装した機能について紹介します。

実行環境にAWS Lambdaを採用した理由

証明書の更新処理を実行するコンピューティング環境として、常時稼働の仮想サーバー（Amazon EC2）やコンテナ（Amazon ECS）ではなく、サーバーレスコンピューティングであるAWS Lambdaを採用しました。その主な理由は以下の3点です。

バッチ処理との相性とコスト効率: 証明書の有効期限チェックとACMEチャレンジの実行は、1日1回、数分程度動けば十分なタスクです。常時起動するサーバーを用意するとリソースの無駄が生じ、OSのパッチ適用などの保守運用も発生してしまいます。AWS Lambdaであれば、Amazon EventBridge Schedulerからのトリガー時のみ起動し、実行した時間（ミリ秒単位）にのみ課金されるため、運用負荷・インフラコストの両方を最小化できます。
ステートレスな設計によるセキュリティ向上: AWS Lambda関数は実行が終わると環境がリセットされる（エフェメラルな）性質を持ちます。証明書の秘密鍵やACMEアカウントキーといった機密データを一時的にメモリ上で扱い、処理の完了とともに破棄する「ステートレスな設計」と非常に相性が良く、永続化はセキュアなAWS Secrets Managerに任せることで、アタックサーフェス（攻撃対象領域）を小さく保つことができます。
AWSサービス群とのシームレスな連携と権限管理: Amazon Route 53のTXTレコード書き換えや、AWS Secrets Managerへの保存といった操作は、すべてAWSのAPI経由で行います。AWS Lambdaであれば、実行用のIAMロールを付与するだけでクレデンシャル（アクセスキーなど）を直接管理することなく各サービスと連携できます。「このAWS Lambda関数には特定のホストゾーンの操作とシークレットの書き込みしか許可しない」といった最小権限の原則を簡単に実装できる点も選定理由です。

利用した言語とライブラリ

AWS Lambdaの言語にはPythonを用いました。ACME関連の処理をすべて自前実装するのではなく、Let's Encryptの公式クライアントであるCertbotの中核部分として開発されているacmeライブラリを利用するためです。このライブラリを利用することで、TXTレコードの計算などの処理も平易に記述できます。

CNAME委譲への対応

証明書更新専用のDNSを切り出して利用できるようにCNAME委譲モードを実装しました。本実装はCNAME委譲をAmazon Route 53上で再現したものです。acme-dnsは専用のDNSサーバーを立てますが、本システムではAmazon Route 53の委譲先ゾーンがその役割を担います。

具体的には、外部DNSの_acme-challenge.{ドメイン}をAmazon Route 53の専用ゾーン上のレコードへCNAMEで指定します。これにより、AWS Lambdaは管理対象であるAmazon Route 53側にだけTXTレコードを書き込みます。

外部DNSのCNAMEは一度設定すれば変更不要です。以降の証明書更新では、AWS LambdaがAmazon Route 53のTXTレコードを書き換える操作のみで完結し、外部DNSへの操作権限が不要になります。ACMEサーバーが名前解決するとCNAMEを辿ってRoute 53のTXTレコードに到達し、チャレンジが成功します。

Apex + wildcard SANの処理

*.example.comだけでなくexample.com（Apex）も同じ証明書でカバーするケースがほとんどです。SANにワイルドカードとApexの両方を含む証明書を取得するとします。この場合、RFC 8555の規定により両方のチャレンジで同じレコード名を使用します。

Amazon Route 53は、同一レコードに対する複数TXT値の保持をサポートしています。そこでAWS Lambdaでは、トークンAとトークンBの両方を複数値レコードとして同時にUPSERTします。これにより、Apexとワイルドカードのチャレンジを一度のRoute 53同期待ちで並列処理できます。結果として、安全かつ高速に証明書を取得できます。 CNAME委譲モードの場合も、外部DNSに設定するCNAMEは1本のみでApexとワイルドカードの両方をカバーできます。

AWS Secrets Managerに保存するデータ構造

適用先差異を吸収するため、証明書は以下のJSON形式でAWS Secrets Managerに保存します。

{
  "certificate": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----\n",
  "private_key": "-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----\n",
  "chain": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----\n",
  "fullchain": "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----\n",
  "metadata": {
    "domain": "example.com",
    "san": ["example.com", "*.example.com"],
    "not_before": "2026-01-01T00:00:00Z",
    "not_after": "2026-04-01T00:00:00Z",
    "issuer": "Sectigo",
    "renewed_at": "2026-01-01T02:15:30Z"
  }
}

具体的には適用先によってはフルチェーンを要求するものや、中間証明書のみ別途必要となる環境があります。そこで本システムでは、スポーク環境側が使いやすいほうを選べるよう、あえて中間証明書のみのchainおよびフルチェーンのfullchainを冗長に保存しています。

また、シークレット名は ssl-certs/{ドメイン名} 形式で統一しており、スポーク環境からはドメイン名さえわかれば一意に取得できます。

ドメインの追加をしやすい仕組み

本システムはドメイン追加を容易に行えるよう設計を工夫しました。環境の再構築は不要で、AWS Secrets Managerのコンフィグシークレットを編集するだけで完了します。

aws secretsmanager put-secret-value \
  --secret-id ssl-renewer/config \
  --secret-string '{
    "domains": [
      {
        "domain": "example.com",
        "san": ["example.com", "*.example.com"],
        "hosted_zone_id": "ZXXXXXXXXXX",
        "enabled": true
      },
      {
        "domain": "example.jp",
        "san": ["example.jp", "*.example.jp"],
        "hosted_zone_id": "ZYYYYYYYYYY",
        "enabled": true
      }
    ],
    "renewal_threshold_days": 30
  }'

上記を実行するだけで、次回のAWS Lambda実行（または手動トリガー）時に、自動で証明書が取得されます。

IAM Roles Anywhere によるAWS環境外での認証

スポーク環境（オンプレミスサーバーや他クラウドの仮想マシン等）はIAMロールによる直接の認証ができません。そこでIAM Roles Anywhereを使用します。利用の流れは以下の通りです。

組織のCA（自己署名CAまたはACM PCA）でスポーク環境ごとにクライアント証明書を発行
スポーク環境はaws_signing_helperを利用し、クライアント証明書で署名したリクエストを送信
IAM Roles Anywhereが証明書を検証し、一時的なIAM認証情報（STSトークン）を発行
スポーク環境は発行された一時認証情報でAWS Secrets Managerから証明書を取得

IAM Roles Anywhereを使うことでアクセスキーの配布・ローテーション管理が不要になり、証明書ベースの認証でセキュリティも向上します。

IAMロールの設計

IAMロールに割り当てるポリシーは、最小権限の原則に基づき設計しています。

AWS Lambda用ロール： ACMEアカウント情報の読み取り、証明書シークレットへの書き込み、Amazon Route 53の特定ホストゾーンへの操作のみ
スポーク用ロール： ssl-certs/* への GetSecretValue のみ（書き込み権限なし）

スポーク側の証明書取得方法

スポーク環境では、AWS CLIを用いてAWS Secrets Managerから証明書を取り出し、jqコマンド等でJSONのパースを行い、証明書・秘密鍵・中間証明書に分割して利用できます。実際の運用では現在適用中の証明書とAWS Secrets Manager上の証明書のハッシュ値を比較し、更新があった場合のみApache等のミドルウェアをリロードする作りにするとより安全です。また運用しやすいように、この一連の処理をサンプル実装としてスクリプト化して利用しています。

まとめ

今回、SSL/TLS証明書期限短縮への対応としてAWS上にワイルドカード証明書の自動更新と集約するシステムを設計・構築しました。本システムで実現できたことを整理すると以下の通りです。

証明書更新の自動化: Amazon EventBridge Scheduler + AWS Lambdaで毎日自動実行
証明書の集約: AWS Secrets Managerにて一元管理
複数環境への配布: AWS Secrets Managerをハブとしたハブ＆スポーク構成
AWS以外の環境での認証: IAM Roles Anywhereでアクセスキー不要
Amazon Route 53以外のDNSへの対応: CNAME委譲モードで外部DNSプロバイダーに対応
操作証跡の確保: AWS CloudTrail Data Eventsで全アクセスを記録
セキュリティ: KMS CMK暗号化・最小権限のIAM適用

証明書の有効期間が47日に短縮されても、このシステムがあれば運用負荷は変わりません。ドメインを追加するたびに手動の証明書取得作業が発生することもなく、設定ファイルを編集するだけで対応できます。

弊社の環境では今までの1年更新でもシステム数が多いため、洗い出しや各環境への配布・設定変更・更新作業など大がかりな作業となっていました。本システムによる自動化ができたことで、今までより工数が削減できる見込みです。

類似の課題を抱えている組織へのアドバイスとして、まず「証明書の一元管理」から始めることをお勧めします。各環境に分散している証明書をAWS Secrets Managerなどの単一ストアに集約するだけでも、更新漏れのリスクは大きく減ります。そのうえでACMEによる自動取得を組み合わせると、完全に手離れのよい運用を実現できます。

なお、ACMEを利用する際は、ACMEに対応した証明書を購入する必要がありますが、すべての証明書発行事業者がそのような証明書を提供しているわけではない点に注意が必要です。

もし、「ノウハウはわかったが、自社だけでシステムを構築・運用するリソースが足りない」とお悩みの場合は、弊社のスポット対応サービス（アドバイザリーサービス）や、継続的なインフラ改善をご提案するマネージドサービスも提供しております。ぜひお気軽にご相談ください！

SSL/TLS証明書の有効期限短縮に備える ― ACMEとAWSでワイルドカード証明書を自動更新・集約する方法

カテゴリ:

はじめに

SSL/TLS証明書の最長有効期限短縮のスケジュールと背景

SSL/TLS証明書の最長有効期限短縮に伴う、ワイルドカード証明書の運用課題と自動化要件