Amazon Web Services ブログ

AWSの自社認証局への移行に備える方法

AWS Certificate Manager image

更新 2017年12月2日: 本記事を初回に公開した2017/11/7の際、AWS CLIやPython SDK は 2015年2月5日 より古いバージョンを使っている場合に更新が必要としていましたが、2013年10月29日より古いバージョンが更新必要と修正させていただきます。
更新 2018年3月28日: Amazon Trust Services の表にある古い値を新しい値に置き換えました。

TLS (Transport Layer Security, 以前は SSL と呼ばれていました) はインターネットでやりとりされる情報を暗号化するために不可欠です。例えば、Amazon.com ではウェブサイト上の全トラフィックに TLS を使用していますし、AWS は AWS サービスへの安全な呼び出しに使用しています。

証明書と呼ぶ電子ドキュメントは、暗号化した接続を行う際にサーバのアイデンティティを証明します。アドレスバーに入力した Web サイトとブラウザが安全に通信しているかを検査するのに証明書は役立ちます。CA としても知られている 認証局 は、特定のドメイン名に対して証明書を発行します。ドメインが信頼された認証局から発行された証明書を提示すると、ブラウザやアプリケーションは通信を行っても安全だとわかります。

2016年 1月、AWS は AWS Certificate Manager (ACM) の提供を開始しました。このサービスは、AWS サービスで使用できる SSL/TLS 証明書を簡単に作成、管理できるようにします。証明書にはアマゾンの自社認証局 Amazon Trust Services から発行されたものを追加料金無しで利用できます。ブラウザやその他のアプリケーションが証明書を信頼するには、証明書の発行者がブラウザなどが信頼している認証局一覧である 信頼ストア に含まれている必要があります。もし信頼ストアに発行した認証局が含まれていない場合は、ブラウザはエラーメッセージ（参考例）を表示したり、アプリケーションは独自のエラーを表示します。AWS は Amazon Trust Services 認証局 があらゆるところで確実に使えるようにするために、2005年以降のほとんどのブラウザで信頼されているルート認証局である Starfield Services の認証局の一つを購入しました。これは Amazon Trust Services で発行された証明書を使うために何もする必要が無いことを意味しています。

AWS は Amazon Trust Services 認証局 からお客様に無料の証明証を提供してきました。これより AWS は Amazon EC2 や Amazon DynamoDB などのサービスにも Amazon Trust Services からの証明書を使用するよう移行して行きます。このブログ記事では、Amazon Trust Services 認証局を使う準備ができているか検証する方法について説明します。

証明書ストアに Amazon Trust Services の認証局群が含まれているか確認する

次の表は Amazon Trust Services の証明書一覧です。これらの証明書が使用しているブラウザの信頼ストアに含まれているか確認するには、表にあるそれぞれの Test URL をクリックして正常に表示されるか確認して下さい。問題がある場合は、この例 のようにエラーが表示されます。

識別名 (DN) サブジェクトの公開鍵 SHA-256 ハッシュ Test URL
CN=Amazon Root CA 1,O=Amazon,C=US fbe3018031f9586bcbf41727e417b7d1c45c2f47f93be372a17b96b50757d5a2 Test URL
CN=Amazon Root CA 2,O=Amazon,C=US 7f4296fc5b6a4e3b35d3c369623e364ab1af381d8fa7121533c9d6c633ea2461 Test URL
CN=Amazon Root CA 3,O=Amazon,C=US 36abc32656acfc645c61b71613c4bf21c787f5cabbee48348d58597803d7abc9 Test URL
CN=Amazon Root CA 4,O=Amazon,C=US f7ecded5c66047d28ed6466b543c40e0743abe81d109254dcf845d4c2c7853c5 Test URL
CN=Starfield Services Root Certificate Authority – G2,O=Starfield Technologies\, Inc.,L=Scottsdale,ST=Arizona,C=US 2b071c59a0a0ae76b0eadb2bad23bad4580b69c3601b630c2eaf0613afa83f92 Test URL
Starfield Class 2 Certification Authority 15f14ac45c9c7da233d3479164e8137fe35ee0f38ae858183f08410ea82ac4b4 なし *

* 備考: アマゾンはこのルート証明書を所有しておらず、Test URLがありません。証明書はここからダウンロードできます。

以下のようにサブジェクトの公開鍵の SHA-256 ハッシュを計算することができます。PEM エンコードされた証明書ファイル certificate.pem の場合は、以下の openssl コマンドを実行して下さい。:

openssl x509 -in certificate.pem -noout -pubkey | openssl asn1parse -noout -inform pem -out certificate.key
openssl dgst -sha256 certificate.key

例えば、Starfield Class 2 Certification Authorityの自己署名証明書が PEM エンコードされたファイルが sf-class2-root.crt だとすると、以下の openssl コマンドを実行して下さい。:

openssl x509 -in sf-class2-root.crt -noout -pubkey | openssl asn1parse -noout -inform pem -out sf-class2-root.key
openssl dgst -sha256 sf-class2-root.key ~
SHA256(sf-class2-root.key)= 15f14ac45c9c7da233d3479164e8137fe35ee0f38ae858183f08410ea82ac4b4

証明書ストアに Amazon Trust Services の認証局群が含まれていなかった時に何をすべきか

Test URL の確認がどれか 1 つでも失敗した場合は、信頼ストアをアップデートする必要があります。信頼ストアをアップデートする最も簡単な方法は、使用している OS や ブラウザをアップグレードすることです。以下の OS では Amazon Trust Services の証明書群が含まれています。:

  • Microsoft Windows Vista, Windows 7, Windows Server 2008 以降のバージョン（2005年 1月以降のパッチがインストールされていること）
  • Mac OS X 10.4 with Java for Mac OS X 10.4 Release 5, Mac OS X 10.5 以降のバージョン
  • Red Hat Enterprise Linux 5 (2007年3月), Linux 6, and Linux 7 and CentOS 5, CentOS 6, and CentOS 7
  • Ubuntu 8.10
  • Debian 5.0
  • Amazon Linux (全バージョン)
  • Java 1.4.2_12, Jave 5 update 2 以降のバージョン、Java 6, Java 7, Java 8 含む

全ての最新ブラウザはアマゾンの認証局を信頼しています。単にブラウザをアップデートする事で、ブラウザの証明書バンドルをアップデートすることができます。ブラウザをアップデートする手順はそれぞれの Web サイトで確認する事ができます。:

もしアプリケーションが独自の信頼ストアを使用している場合は、アマゾン ルート認証局群 をアプリケーションの信頼ストアに登録頂く必要があります。登録手順はアプリケーションやプラットフォームによって異なります。使用しているアプリケーションやプラットフォームのドキュメントを参照して下さい。

AWS SDK や CLI

ほとんどの AWS SDK や CLI は Amazon Trust Services 認証局への移行の影響を受けませんが、もし 2013年 10月 29日 より前にリリースされた Python の AWS SDK や CLI を使用している場合は、アップグレードする必要があります。.NET, Java, PHP, Go, JavaScript, C++ の SDK や CLI には証明書は含まれておらず、基礎となる OS から証明書が来ています。Ruby SDK では 2015年 6月 10日以降 は必要な認証局の少なくても1つが含まれています。それより前の Ruby V2 SDK には証明書が含まれていません。

証明書ピンニング

証明書ピンニング (certificate pinning) と呼ばれる手法を使ってドメインごとに信頼する認証局を限定している場合、ピンニングを調整して Amazon Trust Services 認証局を追加する必要があります。証明書ピンニングは、不正な証明書を使いアプリケーションを騙して違法ななりすましサイトへ接続させようとする攻撃への防御に役立ちます。特定の固定された証明書への制限は、送られてきた証明書が期待される証明書であることを確認することによって行われます。これは、サーバから受信した証明書の公開鍵のハッシュがアプリケーションが対象ドメインについて保存し期待しているハッシュと一致するかどうかをチェックすることによって行われます。もしハッシュが一致しなければ、アプリケーションは接続を中止します。

AWS は、証明書ピンニングの使用は将来的な可用性リスクを招くため、推奨していません。もしピンニングしている証明書が置き換えられると、アプリケーションは接続が行えなくなってしまいます。ピンニングが必要なユースケースの場合は、個々の証明書ではなく認証局をピンニングすることを推奨します。Amazon Trust Services 認証局をピンニングする場合、このブログ記事記載の全ての認証局全てをピンニングすべきです。

このブログ記事にコメントがる場合、（原文の）記事のコメントセクションに記載して送って下さい。もしこの記事について質問がある場合は ACM forum に新しいスレッドを作成して質問して下さい。

– Jonathan

(翻訳は SA 辻 義一 が担当しました。原文はこちら)