FirefoxとChromeで証明書チェーンが異なるのはなぜですか？
HTTPSを使用するサーバーを使用していますが、理解できない非常に奇妙な動作に気づきました。
Firefoxでチェーンをチェックすると、次のようになります。
しかし、Chromeではこれがわかります：
したがって、パスが異なることは明らかです（チェーン内の4アイテムと5アイテム）。より詳細には、証明書「信頼されたルートCA SHA256 G2」には1つの異なる親証明書があるようです。
portecle を使用してチェーンをチェックしたところ、チェーンに5つのアイテムがあります。
私の質問は：チェーンはCN/DNに基づいて構築されていますか？これは、名前だけですが、弱いようです...違いがどこから来ているのか誰かが知っていますか？
edit：Markoの質問のおかげで、申し訳ありませんが、強調していない重要なことが1つありました。
これらの2つのチェーンには、正しいように見える証明書「GlobalSign」がありますが、Firefoxチェーンでは、証明書のシリアル番号は04:00:00:00:00:01:21:58:53:08:A2ですが、Chromeのチェーンでは、同じエイリアスの証明書にシリアル番号04 00 00 00 00 01 25 07 1d f9 afがあるため、問題は、その「信頼されたルートCA SHA256 G2」証明書には、異なる親証明書があります。
おそらく、FirefoxとChromeは異なるレベルの証明書を信頼することを決定しました。Chromeは「GlobalSign Root CA」を信頼し、証明書をルートまでチェーンします1つは有効性をチェックしますが、FireFoxは「Trusted Root CA SHA256 G2」を信頼しているため、ルート1までをすべてチェックして、そのブラウザがそれを信頼しているかどうかを通知する必要はありません。チェーンは親の証明書SIGNING子の証明書に基づいて構築されており、署名の検証はパスが有効であるかどうかのみを知ることができます。
編集：まあ、証明書のエイリアスは一意ではないので、1つのCAは多くの証明書に同じ名前を使用できます。たとえば、私が使用した1つのCAは、異なる期間のクライアント証明書を発行するために、同じエイリアスを持つ複数の中間証明書を使用しました。したがって、この場合、それらは同じエイリアス、同じルートを持ち、どちらも有効ですが、シリアル番号や有効期限などは異なります。したがって、どのエイリアスまたはシリアル番号証明書を使用するかは問題ではなく、信頼することを選択した1つのルート証明書にすべてチェーンするだけです。この場合、GlobalSign Rootにつながる同じ名前のチェーンがいくつも存在する可能性があり、そのルートを信頼し、その署名チェーンが有効である場合、そのパスへのパスは重要ではありません。これがあなたの懸念に役立つことを願っています。
GlobalSignには3つのアクティブなルートCAがあります そのうち2つはCommonGlobalのCommonNameを持っていますが、詳細を見ると他の名前コンポーネントは異なります。
ルートR1：CN = GlobalSignルートCA、OU =ルートCA、O = GlobalSign nv-sa、C = BE
有効な1998/09/01〜2028/01/28
sha1指紋b1 bc 96 8b d4 f4 9d 62 2a a8 9a 81 f2 15 01 52 a4 1d 82 9c
Root-R2：CN = GlobalSign、O = GlobalSign、OU = GlobalSign Root CA-R2
有効な2006/12/15〜2021/12/15
sha1指紋75 e0 ab b6 13 85 12 27 1c 04 f8 5f dd de 38 e4 b7 24 2e fe
Root-R3：CN = GlobalSign、O = GlobalSign、OU = GlobalSign Root CA-R3
有効な2009/03/18から2029/03/18
sha1フィンガープリントd6 9b 56 11 48 f0 1c 77 c5 45 78 c1 09 26 df 5b 85 69 76 ad
SSLとHTTPSの開始直後からR1が使用されているが、R2とR3は大幅に新しいことに注意してください。 （また、将来の使用のためにR4 R5 R6が発行されています。）
サーバーが使用している（非公開ではない）中間証明書は、R3によって次のように発行されます。
CN =信頼されたルートCA SHA256 G2、O = GlobalSign nv-sa、OU =信頼されたルート、C = BE
有効な2014/04/25〜2027/04/25
sha1指紋9a bb 55 a2 6f 9c 06 d5 00 c4 59 91 f0 2c 15 b5 5d 00 a7 02
その指紋をチェックして、私たちが同じものを見ていることを確認してください。
さらに、独自のルート証明書に加えて、各ルートCAは、その他のCAから発行された証明書を持つことができます ;これらは一般的に「クロスCA」または単に「クロス」証明書と呼ばれ、いくつかの目的に使用できます。特に、確立されたCAオペレーターによって新しいルートが作成または取得されると、古いルートの下で新しいルートCAの名前とキーを認証する「ブリッジ」証明書が発行されるため、すでに信頼している検証者（ブラウザーなど）は（発行された証明書）古いルートは、検証者のトラストストアが新しいルートで更新されるのを待たずに、新しいルートで発行された証明書も信頼します。これは、数か月から何年もかかることもあれば、まったくないこともあります。逆に、新しいルートは古いルートを「再認証」する可能性があるため、SHA-2やSHA-3などの素晴らしい機能を備えた新しいルートのみをサポートするようにベリファイアが作成または変更された場合でも、それは受け入れられます。ピアは既存の完全にサービス可能であるが、派手な証明書チェーンを使用しています。
特にSSL/TLSclient（HTTPSブラウザーを含む）は、ハンドシェイクで送信されるサーバー証明書チェーンに限定されず、サーバー（リーフ）証明書から信頼するルートへと選択する有効なトラストチェーンを作成して使用できます。照合は、CommonNameだけでなく、完全なサブジェクト/発行者名（「識別名」）で行われます。それでも、悪意を持って名前を複製するのは簡単であり、偶然の可能性もあります。子証明書のsignatureは親キーの下で検証する必要があるため、これは「弱い」ものではありません。これは、正当なCAのキーが侵害されない限り偽造できません。 、または誰かが暗号を破る可能性があり、現在使用されているサイズ（RSA 2048）では、太陽系に存在するよりも多くの物質とエネルギーが必要です。
R2の下で発行されたExtendedSSL中間体のページにあるGlobalSign Webサイト（そしておそらくR2の下で最初に発行されたものであり、したがって最初にこの問題に直面したようです）は、R1-to-R2クロス証明書を説明および提供しています。 R1からR3に関するWebサイトには何も表示されませんが、透過性ログはcrt.sh havethreeand this one はあなたが投稿したシリアル番号を持っています。その指紋を、表示されている指紋と照合してください。
ただし、Chrome、つまり2台のWindowsマシン（8.1およびVista）にはR3があります（指紋d6 9b）。ルートストア（インターネットオプション/コンテンツ/証明書/ TrustedRoots、またはMMCスナップインcertmgr.msc）この証明書が存在するか、R1のみかを確認します。別のプラットフォームを意味しているが、それを言わなかった場合、Chrome=は常にプラットフォームのトラストストアを使用するため、プラットフォームに依存し、バージョン/アップデートに依存します。両方のルートがある場合、いずれかを選択することは許可されていますが、私はそれを選択することを考える短い方を選択するのを観察しました（一方、Firefoxはすべてのプラットフォームで独自のトラストストアを使用し、38esrにはGlobalSign R1 R2がありますR3およびR4 R5およびいくつかの中間体。）