ブログ

AWS運用者必見! AWSの認証局が変更になるってどういうこと?

2021年3月23日に Amazon S3 と CloudFront で利用するサービス証明書の認証局が変更になりました。AWS運用をされている方は、AWSからこんなタイトルの英文メールを受け取っているのではないでしょうか。

「Amazon S3 and Amazon CloudFront migrating service certificates to Amazon Trust Services starting March 23rd 2021」

本ブログでは、認証局の変更と、実際に注意するべきポイントをじっくり紹介させていただきます!

AWS運用者に通知があった?認証局の変更で何が起きるの?

冒頭でお話したとおり、もう既にAWSの認証局は変更されています。しかしながら、ほとんどのAWS運用者の方はその影響を感じていないのではないでしょうか?

ですが、極々一部の環境で影響が出ているかもしれません。

たとえば影響が出ている場合、以下の様な状態になります。

  • 特定のPCでWebサイトにつながらなくなった!! ・・しかし、他のPCからは接続できる。
  • 特定のアプリでS3バケットに接続ができなくなった!! ・・でも、他のアプリやCLIから操作すると接続ができる。

※エラー画面例

AWSは毎年大量のサービスをリリースしていく中で、独自の認証局を持ち始めました。しかし、独自の認証局を持つ前に運用しているサービスは他社の認証局を利用しています。そのため、少しずつAWS独自の認証局に切り替えを行っているのです。

切り替えが決まった環境はアカウントのメールアドレスに通知され、AWSの技術ブログにも詳細情報が投稿されます。

2021年3月23日 に認証局の変更が行われたのは以下のSSL証明書でした。

  • CloudFront のデフォルトSSL証明書 (cloudfront.net)
  • S3バケットのデフォルトSSL証明書 [*1]

該当するSSL証明書を使ったAWS環境を利用していた方は、SSL証明書の発行元がこれまでの DigiCert から AWSの独自認証局 に変更となったことで、SSL証明書の問い合わせ先が変わってしまいました。

とはいえ、AWSの独自認証局は2005年以降に開発されているほとんどの環境で正常に動作することが保証されています。基本的には影響がないと思って問題ありません。

しかしながら、古いアプリを月に1回動かしたり、古いOSからアクセスしなければいけない環境があるかと思います。

まずは、影響が出る環境と出ない環境の違いについてご案内させてください。


[*1] S3バケットをご利用の場合
具体的には下記のドメインが対象であり、これらは全てS3のエンドポイントに当たります。

*.s3.amazonaws.com (*には不特定の文字列が入ります)
以下のリージョンで認証局が変更されます。
AP-NORTHEAST-1(東京), AP-NORTHEAST-2(ソウル), AP-NORTHEAST-3(大阪: ローカル), AP-SOUTH-1(ムンバイ), AP-SOUTHEAST-1(シンガポール), AP-SOUTHEAST-2(シドニー), CA-CENTRAL-1(カナダ (中部)), EU-CENTRAL-1(フランクフルト), EU-NORTH-1(ストックホルム), EU-WEST-1(アイルランド), EU-WEST-2(ロンドン), EU-WEST-3(パリ), SA-EAST-1(サンパウロ), US-EAST-1(バージニア北部), US-EAST-2(オハイオ), US-WEST-1(北カリフォルニア), US-WEST-2(オレゴン)

*.s3. <リージョン指定> .amazonaws.com (*には任意の文字列が入ります)
以下のリージョンで認証局が変更されます。
AP-NORTHEAST-1(東京), AP-NORTHEAST-2(ソウル), AP-SOUTH-1(ムンバイ), AP-SOUTHEAST-1(シンガポール), AP-SOUTHEAST-2(シドニー), CA-CENTRAL-1(カナダ (中部)), CN-NORTH-1(北京), CN-NORTHWEST-1(寧夏), EU-CENTRAL-1(フランクフルト), EU-WEST-1(アイルランド), EU-WEST-2(ロンドン), SA-EAST-1(サンパウロ), US-EAST-1(バージニア北部), US-EAST-2(オハイオ), US-GOV-WEST-1(AWS GovCloud (米国西部)), US-WEST-1(北カリフォルニア), US-WEST-2(オレゴン)

*.s3-fips-us-gov-west-1.amazonaws.com (*には任意の文字列が入ります)
以下のリージョンで認証局が変更されます。
US-GOV-WEST-1(AWS GovCloud (米国西部))

「AWSの認証局が変更になった」のはわかった。そもそも認証局って何?

認証局とはルート認証局のことで、SSL証明書の発行元を指します。

※ SSL証明書については、ブログ記事「AWS運用には無料のSSL証明書を活用しよう!(取得も簡単、難易度低です)」をご覧ください。

今回AWSから通知があった2021年3月23日の変更は「特定のSSL証明書の発行元が変わります」という内容でした。

これで何の影響が出るのか・・・SSL証明書の役割はもちろん変わりません。どこで発行されたSSL証明書でも、しっかりとHTTP通信を暗号化してHTTPS通信にしてくれます。

なのに、SSL証明書の発行元が変わると、上手く対象のドメインにアクセスができなくなってしまうことがあるのです。

その理由は、認証局の役割に大きく関係しています。

イメージしやすくするために、HTTPS通信の仕組みについて改めて見てみましょう。HTTPS通信をするためには「TLSハンドシェイク」という作業を行います ──

[TLSハンドシェイクで通信を暗号化]

SSL証明書があれば暗号化される・・というイメージが少し伝わりましたでしょうか?でも、これってSSL証明書が「信頼できるもの」であることが前提なんです。

ここからは例え話です。

悪意のある第三者が、フィッシング詐欺を行うために偽物のドメイン [*2] を用意してWebサイトを開設したとします。SSL証明書も偽物ですので、HTTPSリクエストをして手元に届く証明書と公開鍵はWebサイトにアクセスできてしまいます。

[*2] ここでは悪意のあるWebサイトを運用するために用意されたドメインとご理解ください。

[TLSハンドシェイクを利用して、悪意あるサイトが通信を暗号化]

それを防ぐために、HTTPSでアクセスを行うPCやアプリは受け取ったSSL証明書が適切なものか、一度ルート認証局に問い合わせを行います。

ルート認証局は世界中にいくつも存在していますが、ブラウザやOS、JAVAなどのアプリが信頼できるルート認証局を登録してくれています。

[ルート認証局の動作図]

ルート認証局を自分とするSSL証明書の作り方がありますが、当然どんなブラウザやOSにも信頼できるルート認証局として登録されていません。

これによりエラー画面が返ってきたり、信頼できない証明書であると注意喚起の出力がされる様になります。

以上がHTTPS通信の仕組みと、認証局の役割です。

ところで、AWSが認証局を変更したことによりWebサイトへアクセスできなくなる可能性をお伝えするのが本ブログでした。

この説明だと、まるでAWSの独自認証局が発行するSSL証明書は信頼できない様に見えてしまうかもしれません。

勿論、そんなことはありませんのでご安心ください。

エラーが出てしまい、Webサイトへアクセスできなくなる場合はAWSの独自認証局が信頼できるルート認証局として登録されていないからです。そして、AWSの独自認証局は2005年以降に開発されているほとんどの環境で正常に動作することが保証されています。

つまり、2004年以前に開発されたOSやブラウザ、アプリのバージョンをお使いの環境ではまだAWSの独自認証局の存在を知らないため、信頼できる認証局に登録されていないのです。

AWSの認証局変更によりエラーが出る可能性がある環境はどこ?

では、もう少し具体的に、どのような環境の場合に注意すべきかご紹介します。

今回 AWS から案内があった、2021年3月23日の認証局変更の場合、以下の条件の組み合わせでエラーが発生する可能性があります。

  • 変更対象となるAWSリソースの構成、及び運用
    • パターン1: https://*.cloudfront.net をご利用の構成 (*には任意の文字列が入ります)
    • パターン2: S3バケットのオブジェクトをマネージメントコンソール操作以外の方法で保存やダウンロードを実施する運用
  • 影響が発生する可能性があるアクセス元環境
    パターン1 もしくは パターン2に対して、影響発生はしないことが確認されている環境 [*3] よりも古いOSや古いJavaのバージョンを利用してHTTPSリクエストをしている [*4]

[*3] 以下の環境からHTTPSリクエストをする場合、影響はありません

  • 2005年1月以降の更新プログラムがインストールされている Microsoft Windows バージョン、Windows Vista、Windows 7、Windows Server 2008、およびそれ以降のバージョン
  • Mac OS X 10.4と Java for Mac OS X 10.4リリース5、Mac OS X 10.5 以降のバージョン
  • Red Hat Enterprise Linux 5(2007年3月)、Linux 6、Linux 7および CentOS 5、CentOS 6、CentOS 7
  • Ubuntu 8.10
  • Debian 5.0
  • Amazon Linux(すべてのバージョン)
  • Java 1.4.2_12、Java 5アップデート2、および Java 6、Java 7、Java 8 を含むすべての新しいバージョン

[*4] HTTPSリクエストとは以下の様な操作を指します。

  • 「https://」から始まるURLに対してブラウザからアクセスする
  • CurlコマンドやJava等のプログラムで「https://」から始まるURLに対して実行させている

AWS運用者が気にすべき、認証局変更によりエラーが出た場合の対応

エラーが出た場合の基本的な対応として、影響が出ないことが確認されているバージョンまでアップデートが必要です。

ブラウザからHTTPSリクエストを行っている場合、以下のブラウザは単にブラウザのアップデートを行うだけで証明書バンドルをアップデートすることができます。

以下のブラウザは Windows OS が証明書バンドルを管理しています。ブラウザのアップデートではなく、Windows OS のアップデートが必要となってしまいます。

アップデートが難しい場合は、証明書ピンニング をお試しください。

ただし、証明書ピンニングはAWSで推奨されていない方法です。AWSのサポートでは証明書ピンニング設定が考慮されていない事をご理解くださいませ。

ピンニングする場合には、証明書ではなく認証局に対して実施することをを推奨します。
AWSの独自認証局は以下のURLで公開されていますので、設定される場合はご参照ください。

https://www.amazontrust.com/repository/

以上がエラーが発生する可能性がある環境と、発生した場合の対応です。

新しい環境であれば特に影響はありませんが、環境によっては古いOSやブラウザが必要で使い続けている場合がありますよね。

本ブログを参考に、念のためご確認いただけますと幸いです。

元記事発行日: 2021年05月21日、最終更新日: 2024年02月28日