AWS ACM 証明書のインポート・エクスポートとワイルドカード設定

AWS ACM 証明書管理の全体像と効率的な活用術

ACMで実現する証明書ライフサイクル管理の効率化

AWS Certificate Manager (ACM) は、SSL/TLS証明書のプロビジョニング、更新、デプロイを自動化し、証明書管理の負担を大幅に軽減するサービスです。特に、2025年6月のアップデートで導入された「エクスポート可能なパブリック証明書」は、従来の制約を大きく緩和しました。これにより、AWSマネージドサービス（ELB、CloudFrontなど）だけでなく、EC2インスタンスやオンプレミス環境のロードバランサーなど、AWS外のワークロードでもACM証明書を利用できるようになりました。証明書管理の一元化が進み、運用負荷の軽減に大きく貢献します。

有効期間については、ACMが発行するパブリック証明書は198日間ですが、エクスポート可能なパブリック証明書は新規リクエスト時に限り395日間の有効期間が設定されるため、利用目的によって適切な種類を選択することが重要です。

エクスポート可能な証明書が拓く新たな利用シナリオ

エクスポート可能なパブリック証明書の登場は、ACMの適用範囲を大きく広げました。この機能は、特に以下のようなシーンで活用できます。第一に、EC2インスタンス上のウェブサーバーに直接SSL/TLS証明書を適用する場合です。これにより、ALBやCloudFrontを介さずに、より柔軟な構成が可能になります。第二に、オンプレミス環境で運用しているロードバランサーやウェブサーバーにACMで管理された証明書を導入する場合です。

これにより、AWSとオンプレミス環境で証明書管理プロセスを統一し、セキュリティポリシーの一貫性を保つことができます。注意すべきは、この機能を利用するには、証明書をリクエストする際に「エクスポートを有効にする」オプションを必ず選択する必要がある点です。既存の証明書ではエクスポートできないため、必要な場合は新規リクエストが必須です。

ACM証明書の上限とリージョナリティの理解

ACMで発行可能な証明書のデフォルト上限数は100個です。大規模なサービスを運用する際には、この上限を考慮した上で証明書管理戦略を立てる必要があります。必要に応じて上限緩和を申請することも可能ですが、計画的な利用が求められます。

また、ACM証明書は「リージョナルリソース」であるという重要な特性を理解しておく必要があります。これは、証明書をリクエストした特定のAWSリージョンでのみ利用可能であることを意味します。特に、Amazon CloudFrontディストリビューションでカスタムSSL証明書を使用する場合、証明書は必ず米国東部（バージニア北部）リージョンでリクエストする必要があります。異なるリージョンで発行された証明書をCloudFrontにアタッチしようとすると、エラーが発生するため、利用するAWSサービスとリージョン選定の整合性を事前に確認することが極めて重要です。

出典：Amazon Web Services、DevelopersIO

ACMへの証明書インポート・エクスポート実践手順

外部証明書をACMへインポートする基本ステップ

外部で取得したSSL/TLS証明書をACMにインポートすることで、AWSサービスとの連携を強化し、一元的な証明書管理が可能になります。インポートには、証明書本文（Certificate body）、プライベートキー（Certificate private key）、そして証明書チェーン（Certificate chain）の3つの情報が必要です。これらの情報はPEM形式で準備し、ACMコンソールで各フィールドに貼り付けてインポートを実行します。

インポートされた証明書は、ACMの自動更新の対象外となるため、手動での更新管理が必要になりますが、AWSのALBやCloudFrontなど、様々なサービスに容易にアタッチできるようになります。プライベートキーの管理は非常に重要であり、紛失や漏洩がないよう厳重な注意が必要です。

エクスポート可能な証明書を新規発行する具体的な流れ

エクスポート可能なパブリック証明書を新たに発行する際は、ACMコンソールの「証明書のリクエスト」画面で「パブリック証明書のリクエスト」を選択後、次に進む画面で「エクスポートを有効にする」のチェックボックスにチェックを入れることが最重要です。この設定は、一度発行した後は変更できません。その後、保護したいドメイン名（例: example.com や *.example.com）を指定し、ドメイン検証方法（DNS検証またはEメール検証）を選択します。

DNS検証が推奨されており、ACMが自動でRoute 53にCNameレコードを登録し、検証を完了させます。発行が完了したら、証明書の詳細画面から「証明書、プライベートキー、およびチェーンのエクスポート」ボタンをクリックし、ファイルをダウンロードすることで、プライベートキーを含んだ証明書バンドルを取得できます。

既存証明書のエクスポート不可への対処法

既存のACM発行証明書がエクスポートできない場合でも、AWS外での利用が必要になった際には対応策があります。最も確実な方法は、対象ドメインに対して「エクスポートを有効にする」設定で新たなパブリック証明書をACMで発行し、既存の証明書と置き換えることです。この際、現在の運用中のサービスへの影響を最小限に抑えるため、計画的な移行プロセスが求められます。

具体的には、新しい証明書が発行され、十分にテストされた後、トラフィックの少ない時間帯を選んで、ロードバランサーやウェブサーバーの設定を変更し、新しい証明書に切り替える作業を行います。切り替え時には、古い証明書を無効化する前に、新しい証明書が正常に機能していることを確認し、万が一問題が発生した場合に備えて切り戻し手順も準備しておくことが重要です。

ワイルドカード証明書の利用シナリオと設定例

ワイルドカード証明書で管理を簡素化するメリット

ワイルドカード証明書（例: *.example.com）は、複数のサブドメインを持つウェブサービスを運用している場合に、SSL/TLS証明書管理を大幅に簡素化できる強力なツールです。個々のサブドメインごとに証明書を発行・管理する手間がなくなり、1枚の証明書で同一階層の複数のサブドメイン（例: www.example.com, blog.example.com, app.example.com）をまとめて保護できるため、証明書リクエスト、更新、デプロイの作業を一元化できます。

これにより、運用コストの削減、管理者の負担軽減、そして人為的な設定ミスによるセキュリティリスクの低減に貢献します。特に、開発環境やステージング環境など、サブドメインの追加や削除が頻繁に行われる環境において、そのメリットは顕著です。

ワイルドカード証明書の設定と適用時の注意点

ワイルドカード証明書をACMで設定する手順は、通常の証明書リクエストと同様ですが、ドメイン名の指定でアスタリスク（*）を使用します。例えば、「ドメイン名を追加」の欄に *.example.com と入力します。ただし、ワイルドカード証明書には適用範囲に重要な制約があります。

*.example.com は sub.example.com のような単一階層のサブドメインのみを保護対象とし、deep.sub.example.com のような複数階層のサブドメインは保護されません。また、ゾーンエイペックス（example.com 自体）も保護対象外である点に注意が必要です。これらの範囲外のドメインを保護したい場合は、別途ドメインを追加するか、別の証明書を用意するなどの対応が必要になります。

ワイルドカード証明書とゾーンエイペックスの併用戦略

ワイルドカード証明書を利用しつつ、ゾーンエイペックス（ルートドメイン、例: example.com）も同時に保護したい場合は、ACMの証明書リクエスト時に両方のドメイン名を指定する戦略が効果的です。具体的には、証明書のリクエスト画面で「ドメイン名を追加」の欄に*.example.com と example.com の両方を入力します。

これにより、単一のACM証明書で、サブドメインとルートドメインの両方に対してSSL/TLS保護を提供することが可能になります。この設定は、ウェブサイトの全てのページをHTTPS化したい場合や、リダイレクト設定の複雑さを避けたい場合に特に有効です。一つの証明書で広範囲をカバーすることで、管理の複雑性を軽減しつつ、ユーザーに安全なブラウジング環境を提供できます。

AWS ACM 証明書運用で注意すべき落とし穴

エクスポート可否設定の変更不可と事前の計画

ACM証明書において、「エクスポート可否」の設定は、一度証明書を発行すると後から変更できないという重要な制約があります。この特性は、将来的にAWS以外の環境（例えばオンプレミスサーバーや他のクラウドプロバイダー）で当該証明書を利用する可能性がある場合に、特に注意が必要です。もし発行時に「エクスポートを有効にする」を選択しなかった場合、後からエクスポートが必要になっても対応できず、新たに証明書をリクエストし直す手間が発生します。

そのため、証明書をリクエストする前の段階で、長期的な利用計画とデプロイ環境を十分に検討し、エクスポートの必要性を慎重に判断することが極めて重要です。この事前の検討が、将来の無駄な作業や運用コストの発生を防ぐ鍵となります。

リージョナルリソースとしてのACM証明書の限界

ACM証明書は、AWSの多くのサービスと同様に「リージョナルリソース」です。これは、特定のAWSリージョンで発行された証明書が、そのリージョン内でのみ利用可能であることを意味します。この特性は、グローバルに展開するサービス、特にAmazon CloudFrontディストリビューションでカスタムSSL証明書を使用する際に重要な考慮事項となります。CloudFrontはエッジロケーションに証明書をデプロイするため、証明書は必ず米国東部（バージニア北部）リージョンでリクエストする必要があります。他のリージョンで発行された証明書はCloudFrontにアタッチできません。

マルチリージョンでELBなどを運用する場合も、各リージョンで個別に証明書を管理するか、クロスリージョンロードバランシングの仕組みを検討する必要があります。

証明書の有効期間と更新プロセスの管理

ACMが発行するパブリック証明書の有効期間は現在198日間であり、エクスポート可能なパブリック証明書は395日間です。ACMはこれらの証明書の自動更新をサポートしており、通常はユーザーが手動で更新作業を行う必要はありません。しかし、この自動更新プロセスが成功するためには、いくつかの条件が満たされている必要があります。

特にDNS検証方式で発行された証明書の場合、ドメインのDNSレコード（特にCNameレコード）が正しく設定され、期限切れまで維持されていることが不可欠です。もしDNSレコードが変更されたり削除されたりすると、自動更新が失敗し、証明書が期限切れになる可能性があります。Eメール検証の場合は、指定されたメールアドレスへの通知に適切に対応する必要があります。期限切れによるサービス停止を避けるため、定期的なACMコンソールでの証明書ステータス確認が推奨されます。

【ケース】インポート時のエラー解決と安全な証明書移行

架空のケース：インポート時の「プライベートキーの不一致」エラー

これは架空のケースです。

ある企業のシステム担当者が、外部で発行されたSSL/TLS証明書をAWS ACMにインポートしようとした際、「プライベートキーと証明書本文が一致しません」というエラーメッセージに直面しました。この問題の主な原因は、提供されたプライベートキーファイルが、インポートしようとしている証明書本体とペアになっていないことでした。具体的には、以前の証明書で使用していた古いプライベートキーを誤って選択してしまったり、証明書発行時に生成されたキーペアが複数あり、正しいものを特定できなかったりするケースが考えられます。また、プライベートキーがパスフレーズで暗号化されたままインポートしようとした場合にも、同様のエラーが発生する可能性があります。

このエラーを解決するためには、まずインポートする証明書本体と、それに紐づく正しいプライベートキーを確実に特定することが不可欠です。OpenSSLコマンドラインツールを使用して、証明書ファイルとプライベートキーファイルそれぞれからモジュラス値を抽出し、両者が完全に一致するかを確認する手法が有効です。例えば、「openssl x509 -noout -modulus -in certificate.crt | openssl md5」と「openssl rsa -noout -modulus -in private.key | openssl md5」を実行し、出力されるMD5ハッシュ値が同じであることを確認します。さらに、プライベートキーがパスフレーズで保護されている場合は、インポート前にそのパスフレーズを解除し、暗号化されていない状態で提供する必要があります。これらの手順を踏むことで、インポート時の問題を解決し、スムーズな証明書登録が可能になるでしょう。

証明書移行における安全確保のベストプラクティス

SSL/TLS証明書の移行は、ウェブサービス全体のセキュリティと可用性に直結する重要な作業です。安全かつスムーズな移行を実現するためには、いくつかのベストプラクティスを遵守することが推奨されます。まず、最も重要なのは本番環境での適用前に、必ずステージング環境や開発環境で新しい証明書の動作確認を徹底することです。これにより、証明書の形式エラーや設定ミスによる予期せぬサービス停止リスクを最小限に抑えられます。

次に、移行作業は、サイトへのアクセスが比較的少ない時間帯を選んで実施し、万が一問題が発生した場合に備えて、古い証明書への「切り戻し」手順を明確に定めておくことが不可欠です。具体的な手順書を作成し、関係者間で共有しておくことで、緊急時の対応を迅速に行えます。さらに、証明書移行中は、ウェブサーバーやロードバランサーのログ、そしてウェブサイトのHTTPS接続状況をリアルタイムで厳重にモニタリングすることも重要です。例えば、SSL Labsのテストツールなどで証明書設定を検証したり、ブラウザでの接続テストを複数回行ったりすることで、問題の早期発見に繋がります。DNSレコードの変更が伴う場合は、伝播遅延による影響を軽減するために、変更前にTTL（Time To Live）値を短く設定する戦略も有効です。これらの複合的な対策を講じることで、ダウンタイムを最小限に抑えつつ、安全な証明書移行を実現する可能性が高まります。

エラー発生時のログ確認と専門家への相談

ACMでの証明書運用においてエラーが発生した場合、問題の迅速な特定と解決のためには、関連するログの詳細な確認が最初のステップとなります。AWS CloudWatch Logsや、証明書がアタッチされているサービス（例：ALB、CloudFront）のアクセスログ、エラーログなどを確認することで、具体的なエラーコードやメッセージ、発生時刻などを把握できます。例えば、ACM自体の問題であればAWS CloudTrailのイベントログも役立つでしょう。これらのログ情報から、証明書の形式不正、ドメイン検証の失敗、権限不足、リージョン間の不一致など、様々な原因を特定する手がかりを見つけられる可能性があります。AWSの公式ドキュメントを参照しながら、エラーメッセージの意味を深く理解することが解決への近道です。

しかし、ログだけでは解決策が見つからない場合や、問題が複雑で自力での対応が困難な場合は、迷わずAWSサポートへの問い合わせを検討してください。AWSサポートは、専門的な知見と豊富な経験に基づき、適切なアドバイスや具体的な解決策を提供してくれます。また、企業によっては、セキュリティエキスパートなどの外部の専門家やコンサルタントに相談することも有効な選択肢です。厚生労働省の職業情報提供サイト（job tag）にも「セキュリティエキスパート」として定義される専門職があるように、高度なセキュリティ知識を持つプロフェッショナルは、複雑な証明書管理や移行におけるリスク評価、トラブルシューティングにおいて、強力なサポートを提供してくれるでしょう。専門家の視点を取り入れることで、より安全で効率的な解決に繋がる可能性があります。

出典：厚生労働省