AWSCertificateManager（ACM）を利用すると、SSL/TLS証明書を無料で発行し、ウェブサイトの常時SSL化を簡単に行えます。
この記事では、ACMでパブリック証明書を発行する具体的な手順、特に推奨されるDNS検証の方法、そして発行した証明書のAWSサービスへの適用例までを解説します。
Route53や外部DNSサービスを利用している場合の設定方法も網羅し、運用上の注意点についても触れていきます。

この記事でわかること
・ ACMを利用してSSL/TLS証明書を無料で発行し、更新も自動化できる仕組み
・ 推奨される「DNS検証」を用いたパブリック証明書の具体的な発行手順
・ 発行した証明書をALBやCloudFrontなど他のAWSサービスに適用する方法
・ 証明書の自動更新を維持するためのDNSレコード管理などの運用上の注意点

AWS Certificate Manager（ACM）とは？無料でSSL/TLS証明書を発行・管理できるサービス

AWSCertificateManager（ACM）とは、AWS上で利用するSSL/TLS証明書の発行、管理、デプロイを簡素化するサービスです。
大きな特長は、パブリック証明書を無料で発行できる点です。
証明書のプロビジョニングや更新といった煩雑な手作業を自動化し、ALB（ロードバランサー）やCloudFront（CDN）などのAWSサービスと簡単に統合できます。

これにより、セキュアなウェブサイトやアプリケーションを効率的に構築・運用可能です。

ACMでパブリック証明書を利用する4つのメリット

AWSCertificateManager（ACM）を利用してパブリック証明書を管理することには、コスト、運用、管理の各面で多くのメリットがあります。
証明書の発行が無料であることに加え、更新作業の自動化やコンソールでの一元管理が可能になるため、インフラ担当者の負担を大幅に軽減します。
また、他のAWSサービスとのシームレスな連携により、セキュアなアーキテクチャを迅速に構築できる点も大きな利点です。

メリット1：SSL/TLS証明書を無料で発行できる

ACMを利用する最大のメリットは、パブリックSSL/TLS証明書を無料で発行できる点です。
無料のパブリックSSL/TLS証明書においては、Let's Encryptが最も有名ですが、ACMはAWSの各種サービスとの連携が強みです。
証明書の発行枚数や利用するAWSサービスの数に制限はなく、追加コストを気にすることなくウェブサイトやAPIのエンドポイントを保護できます。

これにより、開発環境から本番環境まで、あらゆる場面でHTTPS化のコストを削減できます。

メリット2：証明書の有効期限切れを防ぐ自動更新機能

ACMには、証明書の有効期限を自動で更新する機能が備わっています。
DNS検証を利用して発行されたACM証明書は、有効期限が近づくとAWSによって自動的に更新処理が行われ、関連付けられたAWSリソースにデプロイされます。
この機能により、手動での更新作業を忘れてしまい、サイトが表示されなくなる「証明書切れ」のリスクを回避できます。

運用負荷を軽減し、サービスの継続性を高める上で非常に有効です。

メリット3：コンソール上で証明書の管理が完結する手軽さ

ACMはAWSマネジメントコンソール上で、証明書のリクエストから発行、削除まで、すべての管理操作を完結できます。
従来のように、サーバー上で秘密鍵やCSR（証明書署名要求）を生成し、証明書ファイルをアップロードするといった煩雑な作業は必要ありません。
コンソールの直感的なUIに従ってドメイン名や検証方法を選択するだけで、数ステップで証明書の設定が完了します。

これにより、証明書管理のプロセスが大幅に簡略化されます。

メリット4：ALBやCloudFrontなど他のAWSサービスと容易に連携可能

ACMで発行した証明書は、ApplicationLoadBalancer（ALB）やCloudFront、APIGateway、ElasticBeanstalkなど、多くのAWSサービスと簡単に統合できます。
各サービスのコンソール画面から、ドロップダウンリストで利用したいACM証明書を選択するだけで設定が完了します。
これにより、サーバーに直接証明書をインストールする手間が不要となり、インフラの構成を迅速かつセキュアに変更できます。

ACMを使ったパブリック証明書の発行とDNS検証の具体的な手順

ここでは、AWSCertificateManager（ACM）を用いてパブリック証明書を発行し、ドメインの所有権を証明するためのDNS検証を行う具体的な手順を解説します。
AWSマネジメントコンソール上での操作を中心に、リクエストの開始から証明書の発行完了までをステップバイステップで説明します。
この手順に沿って進めることで、誰でも簡単に証明書を取得できます。

ステップ1：ACMの管理画面から証明書のリクエストを開始する

はじめに、AWSマネジメントコンソールにログインし、サービス一覧から「Certificate Manager」を選択してACMのダッシュボードを開きます。
リージョンが証明書を使用したいサービス（ALBなど）と同じであることを確認してください。
ただし、CloudFrontで利用する場合は、必ず「バージニア北部（us-east-1）」リージョンで発行する必要があります。

画面中央にある「証明書をリクエスト」ボタンをクリックし、リクエストのプロセスを開始します。

ステップ2：証明書を適用したいドメイン名（FQDN）を指定する

証明書のリクエスト画面で、「パブリック証明書をリクエスト」が選択されていることを確認し、「次へ」進みます。
次に、「完全修飾ドメイン名」の入力フィールドに、証明書を適用したいドメイン名（例:www.example.com）を入力します。
同じドメインの複数のサブドメイン（例:blog.example.com）にも対応させたい場合は、「この証明書に別の名前を追加」ボタンから追加できます。

また、*.example.comのようにワイルドカード証明書をリクエストすることも可能です。

ステップ3：推奨される検証方法「DNS検証」を選択する

ドメイン名の指定後、ドメインの所有権を証明するための検証方法を選択します。
ACMでは「DNS検証」と「Eメール検証」の2種類が用意されていますが、「DNS検証」が推奨されます。
DNS検証を選択する最大の理由は、証明書の自動更新に対応している点です。

Eメール検証の場合、証明書の更新時にも手動でのメール承認作業が必要となり、運用の手間が増加します。
特別な理由がない限りは「DNS検証」を選びましょう。

ステップ4：CNAMEレコードを追加してドメインの所有権を証明する

DNS検証を選択すると、ACMは検証用のCNAMEレコードを生成します。
このレコードを、利用しているDNSサービスのドメイン設定に追加することで、ドメインの所有権を証明します。
ACMは指定されたドメインのDNS設定を定期的にチェックし、このCNAMEレコードが存在することを確認できれば検証が完了します。

具体的な設定方法は、DNSサービスがAWSのRoute53か、それ以外の外部サービスかによって異なります。

【Route 53の場合】レコードの自動作成機能で簡単に設定

ドメインの管理にRoute53を利用している場合、DNSレコードの設定は非常に簡単です。
ACMの画面に表示される「Route53でレコードを作成」というボタンをクリックするだけで、検証に必要なCNAMEレコードが自動的にRoute53のホストゾーンに追加されます。
手動でレコード名や値をコピー＆ペーストする必要がなく、設定ミスを防ぎながら迅速に検証プロセスを進めることが可能です。

【外部DNSの場合】CNAMEの値をコピーして手動で設定

お名前.comやGoogleDomainsなどの外部DNSサービスを利用している場合は、手動での設定が必要です。
ACMの画面に表示される「CNAME名」と「CNAME値」をそれぞれコピーします。
その後、利用しているDNSサービスの管理画面にログインし、指定された内容でCNAMEレコードを新規に登録してください。

TTL（TimeToLive）は任意の値で問題ありませんが、特に指定がなければデフォルトのままで構いません。

ステップ5：ステータスが「発行済み」に変わるのを確認する

DNSレコードの設定が完了したら、ACMのコンソールに戻り、証明書のステータスを確認します。
最初は「保留中の検証」と表示されていますが、ACMがDNSレコードの変更を検知すると、ステータスは自動的に「発行済み」に変わります。

DNSの変更がインターネット全体に反映されるまでには時間がかかることがあり、数分から数時間、場合によってはそれ以上待つ必要があります。
ステータスが「発行済み」になれば、証明書を利用する準備は完了です。

発行した証明書はどう使う？主なAWS統合サービスへの適用例

ACMで発行したSSL/TLS証明書は、単体では機能しません。
Application Load Balancer(ALB)やAmazon CloudFrontといったAWSのサービスに適用することで、初めてウェブトラフィックの暗号化が有効になります。
ここでは、発行した証明書をこれらの主要なサービスに紐づけて利用する具体的な適用例を紹介します。

EC2インスタンスに直接インストールするのではなく、これらのサービスを介して利用するのがACMの基本的な使い方です。

適用例1：Application Load Balancer（ALB）に紐づける

ALBに証明書を適用することで、クライアントとロードバランサー間の通信を暗号化できます。
設定はALBの「リスナー」タブから行います。
「リスナーの追加」を選択し、プロトコルとして「HTTPS」、ポートに「443」を指定します。

次に、「デフォルトのSSL/TLS証明書」の項目で、「ACMから」を選び、先ほど発行した証明書をドロップダウンリストから選択します。
これにより、ALBがSSL/TLSの終端処理を行い、配下のEC2インスタンスへのトラフィックをセキュアに分散できます。

適用例2：CloudFrontのカスタムドメインで利用する

CloudFrontのディストリビューションにカスタムドメイン（例:cdn.example.com）を設定し、HTTPS通信を有効にする際にACM証明書を利用します。
CloudFrontのディストリビューション設定画面で、「代替ドメイン名(CNAME)」にカスタムドメインを指定します。

次に、「カスタムSSL証明書」の項目で、発行済みの証明書を選択します。
注意点として、CloudFrontで利用する証明書は、必ずバージニア北部（us-east-1）リージョンで発行する必要があります。

ACM運用で知っておきたい注意点とよくある問題の解決策

AWSCertificateManager（ACM）は非常に便利なサービスですが、運用する上で知っておくべきいくつかの注意点や制約が存在します。
証明書の有効期限を維持するための自動更新の条件や、EC2に直接インストールできない仕様、検証がうまくいかない場合の対処法などを理解しておくことで、安定したサービス運用が可能になります。

ここでは、よくある問題とその解決策について解説します。

注意点：EC2サーバーへ直接インストールはできない構成上の制約

ACMの重要な制約の一つは、発行した証明書の秘密鍵をユーザーがダウンロードできないことです。
秘密鍵はAWSによって安全に管理されており、エクスポートすることは許可されていません。
このため、証明書ファイルをEC2インスタンス上のWebサーバー（ApacheやNginxなど）に直接インストールして利用することは不可能です。

ACM証明書を利用するには、必ずALBやCloudFrontなど、ACMと統合されたAWSサービスをフロントに配置する構成を取る必要があります。

自動更新の条件：DNS検証で利用しているCNAMEレコードを削除しない

ACMの証明書自動更新機能を有効に保つためには、DNS検証で設定したCNAMEレコードをDNS設定から削除しないことが重要です。
AWSは証明書の有効期限が近づくと、このCNAMEレコードを使ってドメインの所有権を再度検証します。
もしレコードが削除されていると再検証に失敗し、証明書が自動更新されず、最終的に有効期限切れを起こしてしまいます。

一度設定した検証用レコードは、その証明書を使い続ける限り、維持し続ける必要があります。

解決策：「検証保留中」のまま進まない時に確認すべきこと

DNSレコードを設定したにもかかわらず、証明書のステータスが長時間「検証保留中」のまま変わらない場合、いくつかの原因が考えられます。
まずは、DNSに設定したCNAMEレコードの名前と値が、ACMの画面に表示されたものと完全に一致しているかを確認してください。
特に、余分な文字やドメイン名の重複がないか注意が必要です。

また、DNSの変更がインターネット全体に反映されるには時間がかかるため、しばらく待つことも必要です。

AWS Certificate Manager（ACM）のDV認証に関するよくある質問

ここでは、AWSCertificateManager（ACM）のドメイン検証（DV）パブリック証明書に関して、ユーザーから頻繁に寄せられる質問とその回答をまとめました。
DNS検証が推奨される理由や、Route53以外のDNSサービスでの利用可否、検証が進まない場合のトラブルシューティングなど、ACMを使い始める際に抱きやすい疑問点を解消します。

ACMの証明書発行で「DNS検証」が推奨されるのはなぜですか？

証明書の自動更新機能が利用できるためです。
DNS検証で発行された証明書は、有効期限が近づくとAWSが自動で更新処理を行いますが、Eメール検証では更新の都度、承認メールへの手動対応が必要です。

運用の手間を削減し、証明書切れのリスクを回避できるため、ACMではDNS検証が強く推奨されています。

お名前.comなど、Route 53以外のDNSでもパブリック証明書は使えますか？

はい、利用可能です。
Route53以外の外部DNSサービスを利用している場合でも、ACMが発行するCNAMEレコードの情報を、お使いのDNSサービスの管理画面で手動設定すれば問題なくドメインの所有権を検証できます。
Route53のような自動設定機能はありませんが、手順通りに設定すれば証明書は発行されます。

証明書のステータスが「検証保留中」から変わりません。原因は何ですか？

主な原因は、DNSに設定したCNAMEレコードが正しくないか、DNSの変更がインターネット全体に反映されていないかのどちらかです。
CNAMEの名前や値に誤りや余分な文字がないか再確認してください。
設定が正しい場合は、DNSの反映（プロパゲーション）に時間がかかっている可能性があるため、最大で72時間ほど待つ必要があります。

まとめ

AWSCertificateManager(ACM)を利用することで、SSL/TLS証明書を無料で発行し、管理・更新のプロセスを自動化できます。
特に、推奨されているDNS検証方式とRoute53を組み合わせることで、数クリックで証明書の発行からDNSレコードの設定までを完了させることが可能です。
発行した証明書はALBやCloudFrontなどのAWSサービスと連携させることで、ウェブサイトやアプリケーションの通信を容易に暗号化できます。

EC2に直接インストールできないといった制約や、自動更新のためにCNAMEレコードを維持する必要がある点に留意して運用することが求められます。