Chrome .localトップレベルドメインの使用によるSSLエラーを表示します
いくつかのサーバー（すべてIIS7でホストされている）でSSL証明書を置き換えました。 ITマネージャーの提案により、サーバーごとに個別の証明書ではなく、サブジェクト代替名証明書を使用しています。この証明書はDigicertから購入しました（自己署名ではありません）。サーバーに証明書をインストールしました。サイトは警告なしに読み込まれ、FirefoxとInternetExplorerで適切なロックが表示されます。ただし、Chromeは、URLの「https」部分のロックアイコンと取り消し線フォントに赤い「x」を表示します。[接続]タブには次のエラーが表示されます。
「このWebサイトのIDは確認されていません。接続しているサーバーのIDを完全に検証できません。ネットワーク内でのみ有効な名前を使用してサーバーに接続しています。外部の認証局では検証できません。一部の認証局はこれらの名前の証明書を発行するため、攻撃者ではなく目的のWebサイトに接続していることを確認する方法はありません。」
「証明書情報」をクリックすると、証明書の完全なチェーン（証明書、Digicertの中間証明書、DigicertのCA証明書）が表示され、3つすべての証明書のステータスが「この証明書はOKです」と表示されます。 URLで使用しているホスト名が、証明書の共通名またはサブジェクト代替名の1つと完全に一致することを4回確認しました。これらのサイトで以前に持っていた証明書は、*。mycompany.localのワイルドカード証明書でしたが、新しい共通名とSANの名前は、mycompany.localドメイン内の特定のホスト用です（つまり、eng- wiki.mycompany.local）。
Chromeからの説明は、サーバーのIPを解決するために内部DNSサーバーが使用されていることを検出したように聞こえますが、古いワイルドカード証明書の場合も同様です。これは、IDを検証できなかったと主張する正当な理由でした。古いワイルドカード証明書でも同じように失敗するはずでした（ただし、失敗しませんでした）。さらに、その説明は、社内サーバーがIDを取得できないことを意味します。検証済み。これは、正当な証明書に数百ドルを投じたにもかかわらず、Chrome）のセキュリティ警告を無視するようにユーザーに教える必要があるため、セキュリティに悪影響を及ぼします。それを避けるために。
助けていただければ幸いです。
ありがとう！
-編集-
今日さらに掘り下げて、エラーメッセージのテキストをChromiumソースで検索したところ、この問題の原因はChromeホスト名が一意ではないと結論付けられていることがわかりました。この問題を報告している他の投稿があります- このように with SAN URLにショートネームを使用する場合の証明書。ただし、wiki.mycompany.localなどの完全修飾サーバー名を使用しています。
ホスト名を一意ではないと判断するコードは ここ であり、根本的な原因であると思われるgTLDについて説明しているコメントがいくつかあります。グローバルトップレベルドメインについてはよくわかりませんが、私の会社では.local疑似TLDを使用しています。ウィキペディアは、これはもはや良い考えではないと言っているようです（サーバー障害で評判が低すぎるため、3つのリンクを作成できません。これを編集してリンクにしてくださいen.wikipedia.org/wiki /.local）、ただし、何年も前にITチームがネットワークを設定したときに推奨される方法でした。今すぐ変更するように依頼するのは簡単なことではありません
Mycompany.localにワイルドカード証明書を使用したときにこの問題が発生しなかったことを除いて、方程式からSAN要素を削除するように質問を編集したいのですが、それでも使用が疑われます。 of a SAN certは問題の一部です。それでも助けてくれてありがとう。
さらに、その説明は、企業の内部サーバーがIDを検証できないことを意味します。これは、Chrome。
ただし、証明書がいくら高価であっても、第三者に身元を確認させることはできません。
パブリックインターネット上でcontoso.comを「所有」できるのは1つの会社のみであり、その会社はserver1.contoso.comを指定でき、他の会社は指定できません。
DigiCert（または誰でも）は、server1.contoso.comの証明書要求が、contoso.comを所有しているのと同じ会社からのものであり、したがって（おそらく）不正な要求ではないことを確認できます。また、server1.contoso.comに対して1つの証明書を発行し、それ以上発行することもできません。
誰でもcontoso.localを持つことができます。一度にたくさんの人。 Digicertは、その名前のサーバーがあるかどうかを確認するために何もできません。そして、彼らはその名前の証明書をそれぞれ異なる人々に何度も何度も発行することができます。
したがって、セキュリティ警告は本物の警告です-Chromeは、これが意図したserver1.contoso.localであることを確認できません。これは、「server1.contoso.local」と呼ばれる1000台のコンピューターにまったく同じ証明書をインストールできるためです。 " 世界中で。
クレジットカードの詳細をサイトに掲載することを検討している場合、.local証明書はまったく安心しないはずです。
どうやらIEとFireFoxはこれについて異なる見解を持っており、実際には問題がないのに問題がないふりをすることを選択しています。
サーバーを実際のFQDNでアクセスできるようにし、代わりにその証明書を購入します。
これはかなり単純で、認証に要約されます。 TessellatingHecklerが述べたように、セキュリティ警告は本物であり、これには回避策があります。これはChromeの欠陥ではなく、IEまたはFFが追いつく必要があるかもしれないベストセキュリティプラクティスへのプロアクティブなアプローチです。なぜ一部のCAが追いつく必要があるのか疑問に思ったことはありません。まだ5年の証明書を販売していますが、他の人は3年しか販売していませんか？証明書の有効期間も間もなく変更されます。
Organizational Validated（OV）証明書が発行されると、CAは、ドメインがドメインレジストラに完全に登録されていること、および企業がドメインを使用する権利を持っていることを認証する必要があります。これは、WHOISとD＆Bを調べてこの情報を確認することによって行われます。たとえば、.com/.net /.eduであるもの。一方、.localは誰でも所有でき、どのCAも認証できません。 Digicertで認証がどのように行われたかはわかりませんが、そうすべきではありません。 SSL証明書を購入すると、何よりも認証に多くの費用がかかります。
これは、CA Browserフォーラムからのリンクで、2016年10月までに、セキュリティのベストプラクティスのためにすべての内部名の使用が廃止されることを示しています。うまくいけば、IT管理チームに光を当て、最後の最後まで待つのではなく、積極的なアプローチを取り始めることができます。
https://www.cabforum.org/Guidance-Deprecated-Internal-Names.pdf
この証明書は何年間有効ですか？私が尋ねる理由は、内部名に関してサーバー構成を整理できるように、当面は回避策があるためです。 CSRを生成するときは、共通名をwww.yourcompany.comとして入力し、SANフィールドに、「yourcompany.local」に入力します。このようにして、CAが認証処理中の場合、www.yourcompany.comへのアクセス権があることを確認でき、SANフィールド内で、yourcompany.localのIPアドレスも保護されます。この回避策は時間に敏感です。 CAは、その有効期間が義務付けられた変更を過ぎた場合、そのような条件下で3年間の証明書を発行します。
この情報がお役に立てば幸いです。
DigiCertはChromeをサポートされているブラウザとして 彼らのサイト としてリストしていません。 他の場所 で説明したように、a SANはSSLの実装に依存しており、FirefoxやInternet Explorerと比較してChromeは何か奇妙な（tm）を実行する可能性があると思います。
たまたま SubjectAltName でIPアドレスを使用していますか？ Chrome App コードサンプルオンライン の1つを見ると、IPではなくホスト名がそこにあることを期待しているようです。