Windows Azure：MicrosoftがルートID証明書を変更

現在SSLを介して利用できるすべてのWindows Azureサービスは、単一のルート証明書GTE Cyber​​Trust Global Rootに基づく証明書チェーンを使用しています。 マイクロソフトは、これをより信頼性の高いBaltimore Cyber​​Trust Root （md5の代わりにsha1、1024の代わりに2048ビットの公開キー）に変更することを決定しました。 移行は2013年4月15日に開始され、数か月続きます。 すべてのAzure SSL / TSLサービス証明書が置き換えられます。

プラットフォームとそこにホストされているアプリケーションのほとんどのユーザーは、変更に気付きません。「新しい」 Baltimore Cyber​​Trustルートは、新しいものとはほど遠いもので、Windows、Windows Phone、Android、iOSなどの多くのOSのルート証明書のリストにあります。 IE、Safari、Chrome、Firefox、Operaで認識されます。 少数派は4月15日までに行動を起こすことをお勧めします。

ルート証明書とは何ですか？

Windows Azure APIおよび管理ポータルには、SSLおよびTSLを介してアクセスできます。 ポータルにログインして証明書情報を取得すると、次のことがわかります。



つまり、接続は、 Microsoft Internet Authority証明書によって署名されたMicrosoft Secure Server Authorityによって保護され、その信頼性はGTE Cyber​​Trust Global Rootによって確認されます。

GTE Cyber​​Trust Global Root- ルートおよび自己署名 。 彼を保証する人はいませんが、ルート証明書のリストに追加されているため、システムは彼を信頼しています。 ブラウザー全体がmanage.windowsazure.comを信頼するのは、既知の数少ないルート証明書のいずれかによってチェーン全体が署名されているためです。

4月15日にこのチェーンのルートが変更されるとどうなりますか？

最良の場合、あなたは何にも気付かないでしょう-新しいルート証明書は古いものと同じようにシステムに認識され（つまり、信頼されたもののリストに既に存在します）、すべてが以前のように機能し続けます。

最悪の場合、セキュリティポリシーが無効な証明書を使用したSSL接続を禁止し、 Baltimore Cyber​​Trust Rootがルートとして登録されていない場合、ブラウザはポータル（およびそれに署名された他のすべてのサイト）にアクセスできません。

同様に、* .windowsazure.com、* .accesscontrol.windows.net、* .core.windows.netなどにあるすべてのAzureサービスの証明書が変更されます。 これは、それらの1つと直接動作するアプリケーションがある場合（たとえば、blobストレージまたはサービスバスを使用する場合）、4月15日に新しいSSL証明書に遭遇し始め、場合によってはこの準備ができていない可能性があることを意味しますイベントの順番。

これは誰の懸念ですか？

1. WebアプリケーションはAzureでホストされ、https：//*.azurewebsites.netやhttps：//*.cloudapp.netなどのアドレスでSSLを介してエンドユーザーがアクセスできます。 -4月15日から、新しいルート証明書を持たないユーザーは、セキュリティリスクに関する恐ろしいブラウザメッセージを受信し始めることができます。
2. アプリケーション/サービス/エージェントは仮想マシン（Azure VMロール）にインストールされ、azureストレージまたは別のAzureサービスを使用します。この仮想マシンのルート証明書のリストにはBaltimore Cyber​​Trust Rootはありません。 -4月15日から、サービスの機能が失われる可能性があります。
3. Azureサービス（ACS（* .accesscontrol.windows.net）など）を消費し、 Baltimore Cyber​​Trust Rootの 「信頼関係」を持たないSharePoint Server -4月15日から、SharePointは接続できなくなり、次の形式のエラーメッセージでEventLogを攻撃し始めます。

   「次の証明書に検証エラーがあるため、操作が失敗しました：...証明書チェーンのルートは信頼されたルート機関ではありません」

4. アプリケーションは、非標準の証明書検証システムを使用します（たとえば、.netの場合：アプリケーションは独自のServerCertificateValidationCallbackを実装します）。 -検証ロジックによっては、動作が停止する場合があります。

この場合の対処方法

1. これが通常のWebサイトである場合、 Baltimore Cyber​​Trust Rootを持たないユーザーの数はごくわずかであると想定できます。 ただし、警告が表示され、新しい証明書cacert.omniroot.com/bc2025.crtへのリンクを提供する必要がある場合があります。
2. 仮想マシンのすべてのインスタンスにBaltimore Cyber​​Trust Rootがインストールされていることを確認してください。
3. Baltimore Cyber​​Trust Rootとの「信頼関係」を作成します。
4. ロジックを確認してください。

誰も気にしないの？

1. Azureでホストされ、 www.myapp.comなどのアドレスのエンドユーザーが使用できるWebアプリケーション（これは、アプリケーションが独自の証明書を使用することを意味します。証明書は決して変更されません）。
2. Azureでクラウドサービスとしてホストされるアプリケーションは.netで記述され、標準の.netライブラリを使用してリソースにアクセスします（プラットフォームがすべてを処理します）。
3. SSLを使用しないアプリケーション。

そしてもちろん、4月15日までにAzureにアップロードされた管理、ユーザー、およびその他すべての種類の証明書は、自動的に変更されません。