はじめに
- パブリック証明書のお話です
- AWSコンソールからの操作を前提としています
- なるべく簡潔に書いてます
- はじめに
- ACMあるある?
- それは勘違いかもしれない
- おわりに
- 関連リンク
ACMあるある?
こんな人いませんか？
- Eメール検証で証明書をリクエストしていたため、更新メールの見落としていた！二ヶ月も前に受信していたのに！
- DNS検証にしておけば自動更新が簡単だったのに！今更移行しようと思ってもサービス動いているし大変そう
それは勘違いかもしれない
ACM、意外と勘違いしていました。かくいう私が知らなかったことが多かったのでまとめてみます。
勘違い１： Eメール検証は自動更新できない
結論、自動更新できます。 「え？でも毎回、証明書更新してねメールが来るんだけど？」な人がいそうです。 自動更新には条件があります。そちらを見てみましょう。
【Eメール検証の証明書が自動更新されるための条件】
| 証明書のドメイン名 | 自動更新するために必要なドメイン名 | 条件1 | 条件2 |
|---|---|---|---|
| example.com | example.com www.example.com |
左記のドメインにHTTPSでアクセスできる | アクセスしたドメインに左記の証明書が適用されている |
| *.example.com | example.com www.example.com |
〃 | 〃 |
ACMはHTTPS接続の確立後、証明書とACMが更新すべき証明書が一致するかを確認します。
そのため、HTTPSでアクセスできる＆更新対象の証明書が適用されている必要があります。
ちなみに、証明書のドメイン名がワイルドカードであってもそうでなくても、自動更新に必要なドメインはwww.example.comかexample.comです。
Eメール検証の証明書が自動更新できなかったときのチェックポイント
- HTTPSアクセスできるサイトがあるのか
- そのサイトには更新したい証明書が適用されているのか
【よくあるミス】
| 原因 | 例 |
|---|---|
| example.comかwww.example.comのサイトがない | 「subdomain.example.comしかなかった」など |
| サイトに適用している証明書が違う | 「*.example.comの証明書を更新したいのに、適用されているのはexample.comの証明書だった」など |
ある意味、毎回証明書更新のメールが来る人は自動更新の条件をクリアできず失敗していることになりますね。
勘違い２：ダウンタイムなしでDNS検証に切り替えるのは大変そう
結論、証明書の変更はサービスに影響しません。 Eメール検証で自動更新に手間取るくらいならDNS検証に切り替えたいところです。
前提1：そもそも最初からDNS検証にできるならそのほうが良い
ACMで証明書をリクエストするときの方法は2種類あります。
- Eメール検証
- DNS検証
さきほどの話は、Eメール検証時のお話です。 Eメール検証では、さきほどご覧になったとおり、自動更新するための条件がやや面倒です。
となると、DNSによる検証のほうが圧倒的に楽です。 これは公式にも書いてあります。
DNS 検証は、E メール検証よりも多数のメリットがあります DNS を使用したドメインの所有権の検証 - AWS Certificate Manager
つまり、最初に証明書をリクエストするときは、DNS検証にしておくのがおすすめということです。 Route53を利用している場合は、ワンクリックで自動的に「レコードを登録からDNS検証」までを終わらせてくれます。 気づいたら証明書が利用可能になっているので、地味に便利です。Eメール検証でポチポチするような作業はありません。
前提2： 証明書を切り替えたとしてもサービスに影響はない
さらに、置き換えて大丈夫なのか？という話も先にしておきます。 結論から言うと、影響はないのですが、簡潔に見ていきましょう。
ビューワーは、プロセスが完了した後だけでなく、証明書を更新している間もコンテンツにアクセスし続けることができます。
証明書を更新または置き換えしても、ロードバランサーノードが受信し、正常なターゲットへのルーティングを保留中の未処理のリクエストには影響しません。証明書更新後、新しいリクエストは更新された証明書を使用します。証明書置き換え後、新しいリクエストは新しい証明書を使用します。
線路切り替えのイメージ
LBもCloudfrontも、旧証明書へのリクエストが終わるまではたとえ更新中であってもその証明書を使うようにできています。 証明書が置き換えられたあとのリクエストは、新しい証明書に向かいます。
よって、インサービスの状態でも証明書を切り替えることができます。
本題：DNS検証に切り替える
さて今回の問題はEメール検証で運用ミスがでると困るからDNS検証にしたいという話でした。 すでに動いているサービスに証明書が適用されています。 しかもEメール検証で発行した証明書を、そのままDNS検証に切り替えることはできないという問題があります。
なので、大まかに以下の方法で切り替えます。
1. DNS検証で新しい証明書をリクエストする 2. Cloudfront、LBに適用されている証明書を置き換える 3. 切り替わっていることを確認してから削除する
1. DNS検証で新しい証明書をリクエストする
同名でもDNS検証用の証明書リクエストは可能なのでご安心ください。
1 新たに証明書をリクエストする(cloudfrontで証明書を使用する場合はバージニアで取得することを忘れずに)
*.example.comで取得して、example.comも使用したい場合は追加の名前にexample.comを追加します
- DNS検証を選択します
2 「確認とリクエスト」→ 「続行」をクリックしてACMのページへ
- リクエストした証明書のプルダウンを押すと、 「Route 53 でのレコードの作成」があるのでクリック。さらに「作成」を押します
- ※ Route53以外でドメイン管理している場合は、「名前」と「値」をCNAMEとしてドメイン管理先に登録します
- 時間がかるので待つ
これで証明書の再リクエストは完了です。
2. Cloudfront、LBに適用されている証明書を置き換える
1 Cloudfront、LBに適用されている証明書を変更する
【LBの証明書変更】
- 「ロードバランサー」ページにて対象のLBを選択します
- 「リスナー」のタグを選択します
- 「編集」にチェックを入れ、「編集」を押します
- 「デフォルトのSSL証明書」のプルダウンから新しい証明書を選択し、ページ上部の「更新」をクリックする
これで完了です。
【Cloudfrontの証明書変更】
注意したいのは、Cloudfrontの証明書はバージニアのみ適用できるところです。（なおLB証明書は東京リージョン、Cloudfront証明書はバージニアリージョン、という形でも問題ないことを確認しています）
- 「Cloudfront」のページにて対象のディストリビューションを選択
- 「Edit」をクリックする
- 「State」が「Enabled」になるまで待つ（あるいは他のディストリビューションを変更していく）
切り替わっていることを確認する
証明書がすべて変更されたかは、ACMのページから確認できそうです。 ACMのページにて、対象の証明書をプルダウンすると詳細が見れます。
「関連リソース」という項目がなくなっていれば問題ないでしょう。
完全に更新されるまでは旧証明書は削除しない
完全に切り替わったことを確認するまでは旧証明書は削除してはいけません！
3. 切り替わっていることを確認してから削除する
- ACMのページにて対象の証明書を削除します
- 右上の「アクション」をクリックし、「削除」を選択します
これで完了です。
おわりに
「証明書の自動更新がされず、サービスダウンさせた」なんてことにならないようにしましょう。 DNS検証のほうが圧倒的に便利なので、これからリクエストする人はぜひそちらを選択してみてください。
※ 間違いなどありましたらご指摘ください。
