web-dev-qa-db-ja.com

オペレーティングシステム（Linux）はどのようにしてセキュリティ証明書を無効にしますか？

Linux以外のマシン（私の電話を含む）で問題なくサイトにアクセスできます https://ce.uci.ed 。しかし、LinuxコンピューターでChromeまたはFirefoxのいずれかでそれを参照すると、「NET :: ERR_CERT_AUTHORITY_INVALID」というエラーが表示されます。

他の人がそうではないのに、なぜ私のオペレーティングシステムがこれを引き起こしているのですか？セキュリティ証明書の検証はOSから独立していると想定されていませんか？

IT部門は問題がないため、面倒な会話になります。

linuxhttps
4
machineghost

サーバーは「中間」証明書（別名「チェーン」）を送信していないため、クライアントには確認するのに十分な情報がありません。

デスクトップブラウザやOSは、検出したすべての中間証明書をキャッシュすることで、この問題について報告しています。このサイトにアクセスすると、ブラウザはそのキャッシュを使用してチェーンを完成させます。モバイルブラウザと非ブラウザアプリは、通常、それを行いません。

IT部門は問題がないため、面倒な会話になります。

彼らは、ブラウザでWebサイトを開く以外に、適切にチェックする方法を知りません。 （「開くと動作します。」）

それらを与えてみてください。スキャン結果は https://www.ssllabs.com/ssltest/ で、この種の設定ミスを正確に検出しようとする広く使用されているWebサイトです。

セキュリティ証明書の検証はOSから独立していると想定されていませんか？

プロセス自体–はい（ほとんどの場合、複雑になる可能性があります）。

（バグや時計の不一致などの些細な問題は無視しましょう。）

「信頼できる」ルートCAリスト

最初の違いは、多くのブラウザが「信頼できる」証明書発行者の独自のリストを使用しないことです。それらはthatの部分をOSと各OSに委任します別のリストがある可能性があります。 MicrosoftとAppleは確かにOS用に独自の信頼できる発行者プログラムを持っていますが、ほとんどのLinuxディストリビューションはMozillaのリストを使用しています（GoogleもAndroid専用ですが、デスクトップChrome用ではないと思います）。

  • たとえば、IEおよびEdge/UWPは、証明書の検証とルートCAリストを含むWindowsの「SChannel」TLSスタックを常に使用します。
  • Chromeは、残りの部分に独自の「BoringTLS」ライブラリを使用しているにもかかわらず、Windows TLS証明書関数も呼び出します（したがって、Windows CAリストを使用します）。ただし、基本的なCAチェックに加えてカスタムポリシーを適用します。発行日に基づいて特定の署名タイプを拒否します。
  • FirefoxにはMozillaCAリストが組み込まれており、すべてを「NSS」ライブラリの内部で実行します。繰り返しになりますが、標準の検証を超えてポリシー制限を追加できます。
    • ただし、Windowsでは、Firefoxはオプションで組み込みリストに加えてOSリストから管理者がインストールしたルートCAをロードできます。 （重要なことに、この機能を手動で有効にしても、デフォルトのCAは読み込まれません。）
    • 同様に、Linuxでは、一部のLinuxディストリビューションはNSS（したがってFirefox）にパッチを適用して、内部リストではなくシステム全体のCAリストを常に使用します。これはデフォルトのシステムCAをロードします。
  • Windows上のほとんどの非ブラウザーアプリはSChannelを使用しますが、OpenSSLを使用するアプリもあります。 OpenSSLをChromeのように、Windows TLS検証に従わせるのは比較的難しいため、これらのアプリは、独自のCAセット（curl-ca-bundle.crtという名前のファイル）をバンドルすることがよくあります。 Mozillaのリスト）そして時々そのファイルはかなり古くなる。
  • 次に、Javaがあります...

キャッシング

「中間キャッシュ」の問題もあります。商用Web証明書は、常に少なくとも2層システムを使用して発行されます。ルートCAはオフラインで保護され、「中間」証明書のみを発行します。これらの証明書のみがオンラインであり、サーバー証明書の発行が許可されます。検証に合格するには、クライアントは「チェーン」全体を知っている必要があります。

通常、クライアントにはルートCAのみがあり、サーバーは中間証明書を送信します。ただし、sysadminがサーバーを誤って構成している（または正しく構成できない）ために、中間体が送信されず、検証チェーンが壊れている場合があります。たとえば、サイトでは、ルートCAの1レベル下にある「InCommonRSAServerCA」によって発行された証明書を使用しています。ただし、InCommon証明書自体は送信されないため、「信頼されたルートCA」リストと照合することはできません。

このような間違いに対処するために、一部のブラウザ（および一部のOS）は、以前に見られた中間CAのキャッシュを構築します。 （Windowsはそれ自体でダウンロードしなければならなかったものをキャッシュします; Firefoxはそれが見たすべての中間体をキャッシュします。）つまり、誤って構成されたWebサイトにアクセスしている場合、成功/失敗は次のように変化する可能性がありますユーザー間、それらはすべて異なるキャッシュが構築されているためです。

これは、システム管理者の自動応答が「私のシステムでは正常に機能します」の場合に特に有害になります。これは、システム管理者が無意識のうちに作成した場合にのみ機能するためです。

チェーンビルディング

「相互署名」が行われているために、複数のチェーンが同じ証明書に対して有効である可能性がある場合があります。たとえば、Let's Encrypt証明書は、IdenTrustの「DSTルートCA X3」またはでルート化できます。 独自の でルート化できます。光沢のある新しい「ISRGルートX1」。クライアントの内容と、サーバーが送信する中間体（複数送信する可能性があります）によって異なります。

一部の米国のmil/gov Webサイトは、商用CAからの証明書ではなく、独自の連邦PKI証明書を使用しています。このための「信頼できる」ルートCAが付属しているOSはWindowsだけです。他のブラウザは、いくつかのルートCAを手動でインストールしない限りそれを受け入れません。また、インストールするwhichルートCAによっては、同じWebサイトに多くの信頼パスがあり、チェーン内に最大6〜7個の証明書がある場合があります。

さまざまなブラウザ、特に検証をOSにオフロードするブラウザは、その状況でさまざまなチェーンを思い付く可能性があります。たとえば、Windowsは非常に柔軟性がありますが、OpenSSLは1.1.x以前は非常に不足しており、Firefoxは通過しましたthreeは、チェーン構築コードを書き直します。 （現在使用されているライブラリmozilla :: pkixは、最初は「insanity :: pkix」と呼ばれていました。これにより、ライブラリがどれほど複雑になる可能性があるかについてのヒントが得られます。）

authorityInformationAccess

Windowsは、不足している中間体をそれ自体でダウンロードできると述べました。技術的には標準機能ですが、プライバシーの懸念から実装を完全に拒否するブラウザもあれば、不必要な複雑さを追加するために気にしないブラウザもあります。これにより、WindowsとLinuxの間にさらに別の違いが生まれます。

（繰り返しになりますが、この機能は、クロスシグニチャが普及し、システムがメッシュよりも（-===-）のように見え始める米国の「連邦PKI」で頻繁に使用されています。ルート化された階層。たとえば、組織AはチェーンA→B→C→Dを認識し、別の組織はまったく同じサーバー証明書DでB→A→C→DまたはB→C→Dを認識する場合があります。）

8
user1686