内部CAによって生成された署名付きSSL証明書を使用しています。 myserver.example.netとmyserverの両方がサイトで有効になるように、サブジェクトの代替名を追加しました。これはFirefoxとIEの両方で正しく機能しますが、Chromeでは、ユーザーが短い名前のmyserverを使用すると、[1]警告メッセージ(「このサイトのIDは確認されていません。」)が表示されます。 CAがインストールされており、FQDNを使用するとChromはそれを問題なく検出します。証明書が未確認になるのは、SANの一部であるhostname( "uname -n")を使用する場合です。示されているように、生成されるエラーは一般的に異なります。私が読んだところによると、SANがある場合、一般名は無視する必要があり、これが当てはまるようです。 SANにリストされているFQDNは機能しているようですが、この問題の原因となっているのはSANにあるノード名だけです。ここで使用されているCAは、数千のクライアントと数百のサーバーを持つ大規模な(複数のクラスAネットワーク)企業のものです。ここで普及しているブラウザはIEであり、私が言おうとしているのは、この大規模な展開での作業方法に問題がない場合は、Chromeは[2] IEのように振る舞うのではなく、それだけが懸念の原因です。
私の質問は、ChromeでSSL警告を受け取らずにユーザーがmyserverを使用する方法はありますか?
エラーのスクリーンショット。
1。 http://imageshack.us/a/img259/9624/certerror.png
グーグルへの無視された最初の報告、上流からの助けはありません。
2。 http://productforums.google.com/d/msg/chrome/FWAtO5uikuE/0zVo9FU9pakJ
実際、Chromeはここで何かを行っています。証明書内のすべてのSANは、パブリックDNSによって順方向および逆方向に解決可能である必要があります。内部名とプライベートIPアドレス(RfC1918など)は、証明書ではお勧めできません。証明書の概念は、エンティティのIDを明確に証明することです。192.168.0.1という名前のホストと「mail」または「unix」という名前のホストが複数あるため、これらのホストの証明書は、の一部に対してのみ有効です。ネット。
CA/Browser Forum しばらく前に、SANでの証明書の使用を非推奨にしました。彼らはこの問題を具体的に説明する 紙 を発表しました。クライアント側でもこれを実施することは理にかなっています。Googleは新しい標準に準拠した最初の企業のようです。