AWS Certificate Manager

目的

最近、dev環境で証明書期限切れ？更新失敗？の通知が度々来ていて、証明書更新を脳死で実施しようとしていました。
そんなとき、「ドメインは残っているの？」という質問を上司から受け、何言ってるのかよくわからず、、、ということで関連サービスのALB、ACM、Route53の関係性を整理します。

ACMとは

サービス自体の理解は簡単です、SSL/TLS証明書を発行するサービスです。
この証明書を使って、通信を暗号化できます。
また、本物のドメインであることを証明するためのものでもあります。
私は↑この役割を知らずに過ごしていました。。。
１回でもマネジメントコンソール上から証明書リクエストしてみればわかることでしたね。。。😅
ちなみに、通信の暗号化と通信のHTTPS化は別物で、通信のHTTPS化は通信の暗号化＋通信相手の認証のようです。

通信の暗号化とドメインの正当性証明を通して、利用者が信頼できるWebサイトにするために、SSL/TLS証明書は使用されているんですね。
たまに見る以下の画面はSSL/TLS証明書関連の整備ができていないWebサイトにアクセスしていることを表しているようです。

パブリック証明書とプライベート証明書

マネジメントコンソールから証明書をリクエストするとどちらか選択させられます。(プライベート証明書はプライベートCAがないと選択できません)

-ざっくりとした違い
①パブリック証明書
信頼された認証局（CA）が発行
多くのブラウザやOSに「信頼済み」として登録されている
インターネット上の公開サービス（Webサイト、APIなど）で利用
②プライベート証明書
組織内の独自CAや社内システムで発行
社内ネットワークや限定された環境で利用
外部のブラウザやOSでは「信頼されていない」ことが多い
③オレオレ証明書（自己署名証明書）(おまけ)
自分自身で発行した証明書（CAを使わず自分で署名）
信頼性はなく、ブラウザやOSで「警告」が表示される
テストや開発環境で一時的に利用されることが多い
テスト用にわざわざ発行手続きするのがめんどくさい。(自分で作ったシステムに自分でアクセスするだけなので著名はなくていい)

外部公開サービス用なのか、社内限定なのか、テスト用なのかなどでどれを使うか判断するといった感じですね。
ちなみに、ACMを採用するのか、オンプレなのかによってパブリック証明書とプライベート証明書の管理や発行コストは逆転したりしています。(ACMでは証明書発行自体は無料ですが、プライベート証明書を発行するには、プライベートCAが必要でその運用費がかかります→AWS Private Certificate Authority)

社内システムやVPC内サービス間通信用の証明書はセオリー通りに行けばプライベート証明書を使うことになるのですが、コストや管理工数からパブリック証明書にしたり、自己著名証明書を使っていたりというケースもあるようですね。

ALB、ACM、Route53の関係性

SSL/TLS証明書はALBにアタッチさせます。
ALBにもDNS名が作成時に割り当てられていますが、基本的にACMで発行したSSL/TLS証明書はRoute53等で別途取得したドメインを保証するように作成し、そのドメインのAレコードでALBを紐づけます。
一見回りくどいというなぁと思ってしまいますが、わざわざALBのDNS名ではなく、Route53で発行するには当然理由があります。(ドメイン固定化、SEO対策、URLのわかりやすさ、メールや他サービスとの連携etc..)
今回整理するに至った質問「ドメイン残っているの？」というのは、「本来ACMは年１で自動更新が走るはずだけど、それが失敗しているということはそもそもその証明書が保証していたドメインが残っていないのでは？であれば、証明書は更新するよりむしろ削除したほうがいいんじゃないの？」 ということだったんですね。

ちなみに、既存の証明書を残したまま保証するドメインだけ変えるといったことはできず、保証ドメインを変える場合は再発行が必要でした。

まとめ

ACMというよりは証明書の話になってしまいましたが、整理はできました。
AWS Private Certificate Authorityを軽く見てみましたが、これも設定項目多くて理解に時間がかかりそうです。
とはいっても、そんなセッティングする機会は多くないだろうし、実務で使うまではいったんお預け。