この記事はアイレット25卒社員によるAWSブログリレーのAWS Certificate Manager（以降ACM）編です。

この記事はJapan AWS Top Engineersのエンタープライズクラウド事業部　構築第二セクション新川貴章さん監修の下、執筆をしております。

AWSブログリレーでは初学者や営業職の方などのこれからAWSについて学習する方向けに1記事1AWSサービスの概要やユースケースを解説するブログリレーとなっております。

AWSブログリレーについてはこちらの記事で詳しく記載しておりますので、ぜひご覧ください！

ACMの概要

Webサイトにアクセスしたときに「https://」という表記を見たことがあるかと思います。これはWebサイトの通信が暗号化されているということを意味します。

ACMはWebサイトの通信をHTTPSにする、つまり、通信を暗号化するために必要なSSL/TLS証明書を無料で簡単に発行・管理・自動更新してくれるサービスです。

この説明だけでは、ACMの凄さや良いところのイメージが湧きづらいと思うので、以下の流れで解説していきます。

・ACMの仕組みについて

・ACMを活用しないでSSL/TLS証明書を発行するとどうなるのか

ACMの仕組みについて

ACMが自動的に処理をしてくれているドメイン検証と自動更新の二つについて解説を行います。

なお仕組みの解説の前に補足ですが、これからの解説の内容は以下のスクリーンショットにあるパブリック証明書のリクエストから必要事項を入力して、リクエストを行った後にACMが裏側でどういった処理をしているかの解説になります。

解説の中で「リクエスト」という言葉が出てきた際にはこのスクリーンショットの「パブリック証明書のリクエスト」を意味します。

ドメイン検証

ACMが証明書を発行するには、「発行者が本当にそのドメインの所有者である」ことを確認する必要があり、この確認作業をドメイン検証と呼びます。

ACMでのドメイン検証には以下の2種類存在します。

・DNS検証

・Eメール検証

DNS検証

DNS検証とは何か？

簡単にいうとDNSサーバーを操作できる人＝ドメインの所有者とみなす検証方法です。

DNS検証の流れ

1：リクエスト

ユーザーがk-nakatani-training.entry-training-tky01.clp-staging.jpの証明書が欲しいとACMにリクエストをします。

2：CNAMEレコードの提示

リクエストを受けたACMがCNAMEレコード設定値の結果を返します。

3：DNS設定

ユーザーが証明書のリクエストを行うとコンソール上では下のスクリーンショットの画面になります。

赤く囲っているRoute53でレコードを作成をクリックすることでリクエストを行った際に指定したドメインのCNAMEレコードを追加することができます。

ここから追加を行うと証明書のリクエストの際に指定したドメインのCNAMEレコードが正式に追加されます。（同じAWSアカウント上に限る）

Route53を確認しにいくと、リクエストの段階では（スクリーンショットの）青枠のAレコードしかありませんでしたが、Aレコードに加えてCNAMEレコードが追加されているのが確認できます。

4：検証

CNAMEレコードの追加後、ACMはインターネット上からCNAMEレコードの登録を確認しにいきます。そこで指示通りの設定（2のCNAMEレコードの指示で準備をしていたもの）CNAMEレコードの確認が取れると所有者本人だと判断をします。

5：発行

4の検証が完了するとACMは証明書を発行します。

検証が無事完了し、発行ができると下のスクリーンショットのように証明書のステータスに発行済みと表示され、ドメインのステータスには成功と表示されます。

ACMの検証と発行処理があるのでCNAMEレコードの追加から少し時間がかかります。

Eメール検証

Eメール検証はAWS公式から非推奨の検証方法となっております。そのため解説はDNS検証よりも簡潔に行います。

Eメール検証とは何か？

ドメインの管理者用メールアドレスに確認メールを送信することで検証を行う方法です。

Eメール検証の流れ

1：リクエスト

ここはDNS検証と同じです。

2：メール送信

ACMがドメインの管理者用メールアドレス宛に承認するかどうかのメールを送ります。よくあるアプリの会員登録とかの確認メールみたいな感じです。

3：承認

ユーザーが送られてきたメールを受信し、メール内の承認リンクをクリックすることで検証完了になります。

4：発行

メールでの承認が確認されるとACMが証明書を発行します。

 

なぜEメール検証が非推奨なのか？

・証明書の自動更新の際にもメール確認が必要となり、実質手動更新になってしまう

ACMを利用する理由の一つとして、証明書の更新作業が面倒だということです。ですが、Eメール検証を採用すると証明書の有効期限が近づくとACMが再び承認確認メールを送信します。

そうすると担当者がメールを開いて承認リンクを手動でクリックしないといけなくなり、自動更新のメリットが失われてしまいます。

・メールが届かない、見落とす可能性がある

アプリの会員登録の際にも経験された方がいると思うのですが、承認メールが届かないといったトラブルが発生する可能性があります。

他にも、承認メールが他の重要なメールに埋もれてしまうなど、見落としによるヒューマンエラーのリスクが高まります。AWSのSNS（Simple Notification Service）設定等で見落とし防止の設定を導入できるとは思いますが、導入すること自体が手間になります。それだったら最初から自動で更新をしてくれるDNS検証を活用する方が良くなります。

・管理が面倒になってくる

もし運用するWebサイトが一つなら、Eメール検証でも管理できるかもしれません。

しかし、運用するWebサイトが増えてくると管理がしきれなくなってきて、結果的に更新漏れに繋がる可能性が出てきます。

ACMを活用しないでSSL/TLS証明書を発行するとどうなるか

結論

ACMを活用する場合と比較して、コスト・手間・管理リスクの3つの課題が発生する。

コスト

ACMを活用しない場合ドメインの所有者を確認するDV認証で年間数千円〜、OV認証、EV認証の場合は年間数万円〜数十万円の費用が発生します。

ACMを利用する場合はこの料金が一切発生しません。それだけでもACMを利用する価値があります。

手間

ACMで証明書を発行しないということは、認証局に対して自分で証明書の発行依頼をすることになります。また、認証局から証明書ファイルが送られてきたらそれをサーバーに設定する必要があります。

サーバーの設定には以下のステップを踏む必要があります。

1、ファイルの配置

2、Webサーバーの設定

3、設定の反映と確認

このステップの作業手順も調べる必要があります。このことからACMを活用する際と比べて手間が発生することになります。

管理リスク

SSL/TLS証明書には有効期限が存在し、ACMを活用する場合は自動で更新をしてくれますが、活用しない場合は更新作業を行う必要があります。

プロジェクトごとに証明書の期限を把握しておかないといけない上、期限が切れる前に発行手続きとインストール作業が発生します。

このような状況から、証明書の更新漏れが発生する可能性があります。更新漏れをしてしまうとサービスに影響が発生し、損害につながります。

例外

これまでの解説ではSSL/TLS証明書には絶対ACMを使った方がいいじゃないかと思った人も多いと思います。

しかしACMを使わない方がいい場合、例外もあります。

EV証明書やOV証明など、より厳重な証明書の発行が必要な要件の場合

銀行や金融機関・大規模なECサイトなどで最高レベルの信頼性を示す必要がある際には、ブラウザのアドレスバーに組織名を表示するEV証明書などが必要になる場合があります。

ACMが無料で発行できるのはDV認証のみです。これは「ドメインの所有権」だけを証明するもので、企業や組織が実在するかどうかまでは証明しません。なので、EV証明書やOV証明書はACMで発行できないのです。

そのため、この場合はDigiCertやGlobalSignなどの認証局から、有料のOV/EV証明書を購入する必要があります。

ACMの証明書をインポートする機能

ACMでは購入した証明書をACMにインポートすることができます。

なので、EV証明書やOV証明などを発行する必要がある際は、発行した証明書をACMにインポートすることでACMで証明書の管理ができます。

注意点として、管理すること自体はできますが、ACMによる自動更新はできないです。あくまでもAWS環境に証明書を持ってくることはできるということになります。

まとめ

最後まで読んでいただきありがとうございました！ACMがどういうサービスなのか、どういう風に活用されているかを理解していただけると嬉しいです！