Amazon Web Services ブログ

Category: AWS Certificate Manager*

AWS Certificate Manager (ACM) が Certificate Transparency (CT) をサポートするための準備

  2018年4月30日 より、Google Chrome は全ての公式に信頼する証明書は少なくても 2 箇所の Certificate Transparency ログに記録されている事を必須条件とします。これにより Google Chrome ではログに記録されていない発行済の証明書にはエラーメッセージが表示される事になります。2018年4月24日より、お客様が Certificate Transparency ログへの記録を無効にしない限り、アマゾンは全ての新規や更新した証明書について少なくても 2 箇所以上の公開ログに記録を行うようにします。 Certificate Transparency ログが無い場合、所有するドメイン名に対する予期しない証明書発行を把握することは難しいでしょう。現行システムでは、発行された証明書の記録は保管されておらず、ドメインの所有者は不正な証明書を見つける信頼性のある方法はありませんでした。 この状況に対処するために、Certificate Transparency は発行された各証明書についての暗号化技術による安全なログを実現します。ドメインの所有者は間違いや悪意で発行されたものも含め、予期しない証明書を見つけるためにログを検索することができます。また、ドメインの所有者は不適切に証明書を発行している認証局 (CA) を見つける事も可能です。このブログ記事では、Certificate Transparency についてより詳細に説明し、どうやって準備をすればよいのかお伝えします。

Read More

Application Load BalancerがSNIを利用した複数のTLS証明書のスマートセレクションをサポートしました

本日、我々はApplication Load Balancer (ALB)でServer Name Indication (SNI)を使った複数のTLS/SSL証明書のサポートをリリースしました。これによって、単一のロードバランサの背後に、それぞれ別の証明書を持ったTLSで保護されたセキュアなアプリケーションを複数配置することが可能になります。SNIを利用するためには、複数の証明書をロードバランサの同じセキュアリスナーに紐付ける必要があります。ALBは各クライアントに最適なTLS証明書を自動的に選択します。これらの新機能は追加料金無しでご利用可能です。 もし新しい機能をどうやって使えばいいかを手っ取り早く知りたければ、こちらをクリックして下さい。この機能に興味があり、Transport Layer Security (TLS)について復習したい場合は続きをお読み下さい。 TLS? SSL? SNI? SSLとTLSは技術的には異なるものですが、これらを入れ替え可能な用語として使いがちです。SSLはTLSプロトコルの技術的な祖先にあたります。以下では簡潔さのために、TLSという用語を使っていきます。 TLSはパスワード、クッキー、クレジットカード番号といったデータを安全に伝送するためのプロトコルです。これによって、送信されるデータのプライバシー、認証、完全性が実現されます。TLSは、ウェブサイトのIDカードに相当する証明書を基礎とした認証技術を利用します。もし、その証明書を署名し発行した人、すなわちCertificate Authority (CA)を信用するなら、あなたはその証明書の中のデータは正しいと信用します。あるブラウザがTLSが有効化されたあなたのALBに接続するとき、ALBはあなたのサイトの公開鍵を表示しますが、それはCAによって暗号的に証明されたものになります。この方法によって、クライアントは”本物のあなた”からデータを得ていることと、あなたのサイトの公開鍵を利用して安全な接続を確立可能なことを確実にすることができます。 SNIのサポートによって、同一のALBで1つ以上の証明書をもっと簡単に利用できるようになりました。複数の証明書を使いたい最も一般的な理由は、同一のロードバランサで異なるドメインを捌きたいときです。これは、ワイルドカードやsubject-alternate-name (SAN)署名書をALBで利用することで元々実現可能ですが、いくつかの制約があります。ワイルドカード証明書は単純なパターンに合致する関連するサブドメインでしか使えません。SAN証明書は複数の異なるドメインをサポートできますが、単一の認証局でそれぞれを認証する必要があります。つまり、新しいドメインを追加するときには毎回証明書を再認証して再配布する必要があることを意味しています。 フォーラムやReddit、そして私のメールボックスで最も頻繁に頂いていた要望の1つが、TLSのServer Name Indication (SNI)拡張を利用してクライアント毎に証明書を選択するようにしてほしいというものでした。TLSはHTTPの下のトランスポートレイヤを担当するため、クライアントがリクエストしたホスト名を見ることができません。SNIはクライアントがサーバに”私が欲しい証明書はこのドメインです”というのを初回接続時に伝えることで動作します。これによってサーバはクライアントに返答するための適切な証明書を選択することができます。全てのモダンなウェブブラウザとその他のクライアントの大多数はSNIをサポートしています。実際、CloudFrontに接続しているクライアントの99.5%以上がSNIサポートしていることを今現在確認しています。 ALBの証明書スマートセレクション ALBの証明書スマートセレクションはSNIを越えていきます。正しいドメイン名の配列だけでなく、証明書にはサーバがサポートしている鍵交換方式と暗号、さらに証明書を署名する時に使った署名アルゴリズム (SHA2, SHA1, MD5)が含まれています。TLS接続を確立する時に、クライアントは”ClientHello”メッセージを送ることでTLSのハンドシェイクを開始しますが、そのメッセージにはクライアントが利用可能なプロトコルバージョン、拡張、暗号アルゴリズムの組、そして圧縮方式の概要が含まれています。各クライアントが何をサポートしているかを元に、ALBのスマートセレクションアルゴリズムがその接続のための証明書を選択し、クライアントに送ります。ALBは古典的なRSAアルゴリズムも、より新しくて人気で高速な楕円曲線ベースのECDSAアルゴリズムも両方サポートしています。クライアントのECDSAサポートはSNI程は広まっていませんが、全てのモダンなウェブブラウザではサポートされています。より高速でCPUの利用も少ないので、超低レイテンシなアプリケーションや、モバイルアプリのバッテリ残量の節約には特に有効です。ALBはTLSのハンドシェイクから各クライアントが何をサポートしているかが分かるので、同一ドメインのRSAとECDSA証明書の両方をALBにアップロードすることでALBが各クライアントに最適なものを自動的に選択させることができます。 ALBでSNIを利用する ここではウェブサイトの例として、VimIsBetterThanEmacs.comとVimIsTheBest.comを使います。Amazon Route 53でこれらのドメインを購入しホストしておいて、2つの別々の証明書をAWS Certificate Manager (ACM)で発行しています。もし1つのALBでこれらのサイトを両方とも安全に配信したいと思ったら、コンソールから両方の証明書を追加することができます。 最初に、コンソールから私のロードバランサを選択し、listenerタブに行き、”view/edit cerfiticates”を選択します。 次に、左上の角にある”+”ボタンを使って証明書を幾つか選択して、”Add”ボタンをクリックします。 これ以上の手順はありません。GUI好きな方ではなかった場合も、AWS Command Line Interface (CLI) (またはSDK)経由でももちろん新しい証明書を追加することはできますのでご安心下さい。 aws elbv2 add-listener-certificates –listener-arn <listener-arn> –certificates CertificateArn=<cert-arn> 知っておくべきこと ALBのアクセスログには、クライアントがリクエストしたホスト名と使われた証明書のARNが含まれるようになります。もし”hostname”のフィールドが空 (“-“で表現されます)だったときには、そのクライアントではリクエストにSNI拡張が使われていません。 […]

Read More