web-dev-qa-db-ja.com

相互SSL認証と証明書の要件

内部テストでは、IISサーバー（2つのアプリケーションをホストします：ASP.NET Web GUIとWebサービス））とクライアント（2つのサーバーにアクセスする）の間に相互SSL認証を設定する必要があります可能な方法：ブラウザーを備えたWeb GUI、およびWinFormsで作成されたクライアントを備えたWebサービス。テストが完了し、結果が評価されたら、環境への設定方法をお客様に示す必要があります-a閉じた企業環境で、VPN経由で非公開URLからアクセスできます。

私はPKI、キー、および証明書全般に精通していますが、HTTPSのコンテキストでのPKIの経験はあまりありません。いくつかの利用可能なツール（主にXCA）を使用して、ルートCA証明書、サーバー証明書、および一連のクライアント証明書を作成することができました。 IISとクライアントストアにインストールしました。非常にスムーズに動作しますが、いくつかの問題と質問があります。

  • サーバー証明書に必要な（拡張）キー使用法の値は何ですか？私のテスト証明書で、Digital Signature、Non Repudiation、Key Enciphermentを取得し、TLS Web Server Authenticationを拡張しました-何か欠けていますか？これらすべてが必要ですか？
  • クライアント証明書に関する同じ質問：どのキーの使用法が必要ですか？私のテスト証明書にはDigital Signature、Key Encipherment、Data Enciphermentおよび拡張TLS Web Client Authenticationがあります-何か欠けていますか？これらすべてが必要ですか？
  • クライアント証明書に必要な他の特別な機能はありますか？
  • サーバー証明書の名前は、SANのリストにDNSエントリとしてリストされている必要があります（IPアドレスでアクセスしている場合はIPです）。しかし、その識別名のサブジェクトのCNフィールドはどうですか？特定の形式にする必要がありますか？空にする必要がありますか？ mytestenv.mycompany.lanなどの非公開アドレスをSANとして使用できますか？現在、テストサーバー証明書にはサブジェクトCNのみが設定されており、SAN DNSエントリがありません。追加する必要があると思いますが、正しいですか？
  • （ブラウザーまたはWindowsストアの信頼できるCAにCA証明書を追加する以外に）サイトが安全でないことについてブラウザーが全ページのセキュリティ警告を表示しないようにするために実行する必要のある手順はありますか？ 「緑の鍵」がなくても、またはアドレスバーなどに警告が表示されていても、私は生きていると思いますが、たとえばChromeは、ページ全体のセキュリティエラーを表示し、設定するまでWebページを表示しませんサーバーのセキュリティ例外。これを防ぐにはどうすればよいですか？SANが原因である可能性がありますか？IEとFirefoxがページを表示します。
  • DV/OV/EV、証明書の透明性、ブラウザに着信する「HTTPS黙示録」などは、私の（そしておそらく顧客の）設定に何らかの影響を及ぼしますか？これらに特別な注意を払う必要がありますか？

可能であれば、一般的な発言と、特定のサーバー（特にIIS）とブラウザー（顧客のインフラストラクチャでは、これらは主にIE 11+ and Edge）の要件）の要件に興味があります。

iisssl-certificatehttpsinternet-explorerssl-certificate-errors
3
Maciek

主な用途

TLSの場合、キー暗号化とデジタル署名、および該当するTLSWebサーバー/クライアント認証の拡張使用が必要です。否認防止は使用されません。理論的には、ECDHEではなくECDHに鍵共有を使用できます。 https://security.stackexchange.com/a/24107 を参照してください

証明書の透明性。

グーグルは彼らのかなりの影響力でこれを推進しています。証明書を透過性ログに送信するときに考慮すべき重要なことの1つは、実際にはドメイン名（またはワイルドカード）の公開であるということです。 letsencrypt証明書を取得した直後にWebサーバーへのクエリに気づきました。透過性ログには事前公開があるため、理論的には、これはssl証明書が実際にインストールされる前でも可能です。

参照： Scott Helmeブログ

4月Chrome更新：

差出人： https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/wHILiYf31DE

2015年1月以降、ChromeはEVステータスを取得するために拡張検証（EV）証明書がCTに準拠していることを要求しています。2018年4月に、この要件はすべての新規発行のパブリックに拡張されます-信頼できる証明書（DV、OV、EV）と、このポリシーに準拠していない証明書は、Chromeによる評価時に信頼できるものとして認識されません。ユーザーまたは管理者によって追加された、ローカルで信頼されたCAまたはエンタープライズCAから発行された証明書は、この対象ではありません。要件。

ローカル名を持つSAN

私が知っている問題はありません。 .localはマルチキャストDNSで使用されるため、特に厄介なTLDです。

その他の要件

成熟したシステムでは、CRLサーバーとOCSPサーバーが必要です。一部のサブプロセスは、ブラウザ自体よりもさらに要求が厳しい場合があります。たとえば、IE11のJavaプラグインです。Webstartアプリケーションまたはアプレットの階層に到達不能なCRLまたはOCSPサーバーがある場合、ブラウザフレームは数分間完全に空白のままになる可能性があります。ApacheWebサーバーがOCSPステープリングの場合、OCSPサーバーはWebサーバー自体が呼び出したときに応答する方が適切です。それ以外の場合、Apacheを使用すると、サーバーの応答が再びステープルされるまで、すべてのクライアントでエラーが表示されます。

権限キーID。この機能を使用して、エラーまたは侵害による中間証明書の撤回からの回復を可能にします。

CAAレコード。公的CAは、証明書を発行するときにこれを確認する必要があります。 https://scotthelme.co.uk/certificate-authority-authorization/ を参照してください

さらなる参照：

1
Gerrit