令和なのに SSL/TLS サーバー証明書を ACM ではなく IAM にアップロードしてみた
昔は ACM なんて便利なものはなかったんじゃよ
コンバンハ、千葉（幸）です。
例えば ALB で HTTPS リスナーを作成し SSL/TLS サーバー証明書（X.509 証明書。以降は単に SSL 証明書と呼称）を設定したいとなった場合、真っ先に思いつくのは ACM の使用でしょう。むしろ ACM 以外に選択肢があることを知らない方もいるかもしれません。
外部で取得した SSL 証明書をインポートして有効期限やリソースとの関連付けをコンソール上で管理できたり、発行自体を ACM で行えば有効期限の自動更新までやってくれたりと、ACM はとても便利なサービスです。
そんな ACM が登場したのは 2016 年 1 月です。
ではそれ以前は ELB（あえて ALB とは書かない）などのAWS リソースに関連づける SSL 証明書の管理はどうしていたのか？まさか ACM が登場するまでは SSL 証明書を使えなかった？
そんなことはありません。当時はみんな、IAM に SSL 証明書をアップロードしていました。IAM と言えばみんなが好きな AWS サービス No.1 （わたし調べ）の認証・認可を司ってくれるサービスですが、SSL 証明書のアップロードまでできるのです。
……といったことを IAM のリソースタイプを舐めるように眺めていた時に思い出したので、昔を懐かしんでやってみることにしました。
自己署名証明書を作成する
IAM にアップロードするための自己署名証明書を作成します。 *1
work というディレクトリで作業しています。
work % openssl req -x509 -sha256 -nodes -days 3650 -newkey rsa:2048 -subj /CN=localhost -keyout server.key -out server.crt Generating a 2048 bit RSA private key .............................................+++ ............................+++ writing new private key to 'server.key' ----- work % ls server.crt server.key
今回は以下の名称で証明書とプライベートキーを生成しています。
- 証明書：
server.crt - プライベートキー：
server.key
ALB の HTTP リスナーに IAM にアップロードした証明書を設定する
ALB の作成時、リスナーに HTTPS を指定するとセキュアリスナーの設定画面が表示されます。そこではデフォルトの SSL/TLS 証明書をどの方式で設定するか選択します。
- ACM から（ACM にインポート済みのものを使用）
- IAM から（IAM にアップロード済みのものを使用）
- インポート（インポート/アップロードを行い、それを使用）
- ACM へ
- IAM へ
今回はもちろん IAM へのインポートを指定します。以下内容を入力し、ロードバランサーの作成を試みます。
失敗しました。
Certificate 'arn:aws:iam::012345678910:server-certificate/chibayuki-oreore' not found
証明書が見つからない、と怒られています。なんらかの理由でインポート（アップロード）できなく、それで失敗している気がします。
そう言えば昔もマネジメントコンソールからのアップロードはうまくいかなかったっけ……という記憶が蘇ってきます。コンソールからの操作を早々に諦め、以下のページを参考に AWS CLI からアップロードを試みます。
work % aws iam upload-server-certificate\
--server-certificate-name chibayuki-oreore\
--certificate-body file://server.crt\
--private-key file://server.key
{
"ServerCertificateMetadata": {
"Path": "/",
"ServerCertificateName": "chibayuki-oreore",
"ServerCertificateId": "ASCAQ3BIIH73R7DU7WLHE",
"Arn": "arn:aws:iam::012345678910:server-certificate/chibayuki-oreore",
"UploadDate": "2022-11-05T13:42:07+00:00",
"Expiration": "2032-11-02T13:19:52+00:00"
}
}
↑アップロードが成功しました。
アップロードした証明書を選択する方式をとることで、ロードバランサーの作成が正常に作成が完了しました。
アップロードした証明書は IAM コンソールからは確認できない
IAM にアップロードした証明書をマネジメントコンソールで管理することはできません。
以下のように、IAM のコンソールには証明書を管理できる項目が用意されていないことが分かります。
ALB の HTTPS リスナーの詳細画面から、ID や名前、有効期限などを確認することはできます。また、リスナーの作成時や証明書の追加時など、IAM にアップロード済みの証明書の一覧を確認することまではできます。
一方で、証明書の削除や「証明書一覧」のような形で独立して確認することはできません。逆説的に ACM の便利さを感じますね。
IAM にアップロードされた証明書を AWS CLI で管理する
コンソールからは管理らしい管理ができないので、AWS CLI でやっていきます。これも以下のページを参考にします。
証明書の一覧表示
% aws iam list-server-certificates
{
"ServerCertificateMetadataList": [
{
"Path": "/",
"ServerCertificateName": "chibayuki-oreore",
"ServerCertificateId": "ASCAQ3BIIH73R7DU7WLHE",
"Arn": "arn:aws:iam::012345678910:server-certificate/chibayuki-oreore",
"UploadDate": "2022-11-05T13:42:07+00:00",
"Expiration": "2032-11-02T13:19:52+00:00"
}
]
}
証明書の取得
取得できるのは証明書のみで、プライベートキーは取得できません。
% aws iam get-server-certificate --server-certificate-name chibayuki-oreore
{
"ServerCertificate": {
"ServerCertificateMetadata": {
"Path": "/",
"ServerCertificateName": "chibayuki-oreore",
"ServerCertificateId": "ASCAQ3BIIH73R7DU7WLHE",
"Arn": "arn:aws:iam::012345678910:server-certificate/chibayuki-oreore",
"UploadDate": "2022-11-05T13:42:07+00:00",
"Expiration": "2032-11-02T13:19:52+00:00"
},
"CertificateBody": "-----BEGIN CERTIFICATE-----\nMIIC……略……3dVcEMw=\n-----END CERTIFICATE-----",
"Tags": []
}
}
証明書の削除
正常に削除が完了した場合、特に戻り値はありません。
% aws iam delete-server-certificate --server-certificate-name chibayuki-oreore %
ちなみに証明書を使用中の場合は削除ができません。
% aws iam delete-server-certificate --server-certificate-name chibayuki-oreore An error occurred (DeleteConflict) when calling the DeleteServerCertificate operation: Certificate: ASCAQ3BIIH73R7DU7WLHE is currently in use by arn:aws:elasticloadbalancing:ap-northeast-1:012345678910:loadbalancer/app/test/0a1bdb7c0ccf167d. Please remove it first before deleting it from IAM.
昔は ALB なんて便利なものはなかったんじゃよ
昔を思い出して懐かしくなったので、CLB での操作も試してみます。ちなみに ALB は 2016 年 8 月にリリースされました。
ALB のリリース前は（今で言う）CLB は単に ELBと呼ばれており、ALB のリリースによって Classic という接頭辞を冠することになりました。「新しい ELB ではパスベースのルーティングができるらしいぜ！」なんて盛り上がっていたのを思い出します。
CLB はいまでは非推奨なのでロードバランサーの作成画面ではひっそりと隠されています。折りたたみを展開することで選択できます。
いくつかステップが分かれており、ステップ 1 で HTTPS リスナーを選択した場合にステップ 3 で証明書の設定を行うことになります。今回も IAM への証明書のアップロードを試みます。
ステップ 4、ステップ 5 を進み作成を試みたところやっぱりエラーが発生しました。分かってましたよ。
ロードバランサーを作成できませんでした: Server Certificate not found for the key: arn:aws:iam::012345678910:server-certificate/chibayuki-classic
あらかじめアップロード済みの証明書を選択する方式で作成が成功するのも同じでした。作成後リスナーから証明書の変更ができますが、ALB のようにリッチな画面で証明書の詳細が確認できたりはしませんでした。
CLB、今までありがとう。ゆっくり休んでね。
懐古もいいけどやっぱり便利なのが一番
ACM があるこの時代に、あえて IAM に証明書をアップロードしてみました。
証明書の管理をコンソールからできない・証明書の有効期限が近い時に通知してくれないなど、ACM と比べて IAM で証明書を管理するアドバンテージは存在しません。
（あるのか分かりませんが）ACM がサポートされていないリージョンを使用する、といった特別な事情が無い限りは IAM での証明書管理はやめましょう。
昔を思い返したことで、現代の便利さに思いを馳せることができました。
以上、 チバユキ (@batchicchi) がお送りしました。
参考
脚注
- コマンドは以下サイトを参考にさせてもらいました。
オレオレSSL証明書（自己署名証明書）を作るワンライナー - karakaram-blog ↩
![[Auth0] Route 53+ACM+CloudFrontでAuth0にカスタムドメインとリバースプロキシを設定してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-e37cf03c5caac969de0f633e4738977d/1862834d1806cb03b64a8000a5a1a39e/Auth0ByOkta.jpg)
