2つの異なるパスを使用して検証された証明書

Question

StartSSLには、EV証明書の署名に使用する中間証明書があります sub.class4.server.ca.pem 。この証明書の発行者は、openssl x509によって/ C = IL/O = StartCom Ltd./OU=Secure Digital Certificate Signing/CN = StartCom Certification Authorityと示されます。これは、ルートCAとして配布する証明書 ca.pem と一致します。

ただし、Firefox/Mozillaには、そのサブジェクトを持つ2つの証明書が含まれています。 1つは、StartSSLが配布する証明書と同じです。その他 ^{（以下に添付）} 検証可能に異なります。たとえば、前者のシリアル番号は1で、後者のシリアル番号は45です。Edit：Afterさらなる調査により、これはStartSSLが ca-sha2.pem 。として配布する証明書と同じであることが判明しました

openssl verifyを使用して sub.class4.server.ca.pem を ca.pem に対してチェックすると、機能します。

% openssl verify -CAfile ca.pem -verbose sub.class4.server.ca.pem sub.class4.server.ca.pem: OK

興味深いことに、Firefox/Mozilla証明書と照合すると、引き続き機能します。

% openssl verify -CAfile ca-ff.pem -verbose sub.class4.server.ca.pem sub.class4.server.ca.pem: OK

私の結果をファウルするために何か他のものがそこに入っていないことを確認するために、私は私が間違っているものであることがわかっている証明書に対してそれを試しました：

% openssl verify -CAfile ca-wrong.pem -verbose sub.class4.server.ca.pem sub.class4.server.ca.pem: C = IL, O = StartCom Ltd., OU = StartCom Certification Authority, CN = StartCom Extended Validation Server CA error 20 at 0 depth lookup:unable to get local issuer certificate

これは2つの可能性を残します：openssl verifyが実際の署名をチェックせず、発行者のサブジェクトのみに依存している（おそらく間違って使用しているため）か、この証明書を2つの異なる証明書で検証できます。

最初の可能性を確認するために、同じ発行者情報で自己署名証明書を作成し、それを使用して中間証明書を検証しました。

% openssl verify -CAfile ca-fake.pem -verbose sub.class4.server.ca.pem sub.class4.server.ca.pem: C = IL, O = StartCom Ltd., OU = StartCom Certification Authority, CN = StartCom Extended Validation Server CA error 20 at 0 depth lookup:unable to get local issuer certificate

ですから、openssl verifyはそれほど簡単には手探りではないようです。

次に、2つの異なる証明書が同じRSA鍵を使用している場合、同じ子証明書を検証できることに気付き、2つの証明書について報告された公開鍵係数が同じであることがわかりました。

StartComが2つの異なる証明書に同じRSAキーを使用しているように見えることはまったく心配ですか？私には悪い考えのようですが、私は素人です。

これを調べている他の人のために、Firefoxが持っている追加の証明書を以下に示します。

Thomas Pornin · Accepted Answer

X.509に関する限り、同じ公開鍵を持つ複数の証明書があってもまったく問題はありません。 validationプロセスについて詳しく説明します here ;簡単に言えば、次のことが確認されます。

チェーン内の各証明書は現在有効です（有効期限の開始日と終了日に関して）。
各証明書の署名は、証明書の内容と発行元CAの公開キーに対して正しいものです。
各証明書の発行者DNは、その発行CAのサブジェクトDNと一致します。
すべての証明書拡張（証明書ポリシー、名前の制約...）は正しいです。

2つの異なる証明書で同じ公開鍵を使用することは問題ではありません。各証明書は、公開鍵とアイデンティティ間のバインディングを表明します。同じバインディングをアサートする10個の証明書がある場合は、それだけ多くのことができます。

実際には、同じ名前とキーを持つ複数の証明書を持つことが、更新の通常の結果です。証明書の有効期限が切れた場合、新しい証明書用に同じキーペアを保持したい場合があります。

あなたのケースでは、関係する証明書はルート証明書であり、つまり「実際の」証明書ではないため、状況は少し異なります。これらはCAによって発行されたものではありません。それらはトラストアンカーのための便利な船です。それにもかかわらず、両方の証明書の比較（openssl x509 -text -noout -in ca.pem）は、2つある理由を明らかにします（これは非常に悪い理由です）。これは、SHA-1で予測される包括的な過敏症の一部です。実際、ルート証明書は多くの場合自己署名されており（X.509形式の署名にはオプションのフィールドがないため）、署名アルゴリズムはハッシュ関数から始まります。「古い」証明書（ca.pem（StartSSLのファイル）はSHA-1で署名を宣言しますが、（Firefoxの内臓からの）「新しい」証明書はSHA-256ベースの署名を使用します。

もう1つの違いは、「新しい」証明書にCRLダウンロードのURLが含まれていないことです。これは、ルート証明書が定義上、発行元のCAによって取り消されないためです。

シリアル番号、ハッシュアルゴリズム、CRLダウンロード用のURLを除いて、2つの証明書は同一です。同じ名前、公開鍵、有効期限が含まれています。私は、SHA-1のブラインドで体系的で熱心な拒絶が、ここでの主な動機だと思います。次の理由により、これは不十分な理由です。

SHA-1はまだ壊れていません。特にシグネチャの場合、衝突よりもプリイメージで機能します。
ルート証明書の署名は無意味なので、宣言されたハッシュ関数がSHA-1、SHA-256、MD5、またはFOOBAR42であるかどうかは問題ではありません。