web-dev-qa-db-ja.com

google証明書は正しいCA

https://www.google.com.ua/ の証明書を表示します

enter image description here

だから私は、cURL経由でリクエストするときに、CURLOPT_CAINFOそれらの証明書（GeoTrust Global CAおよびGoogle Internet Authority G2バンドルなど）、Googleの証明書の検証に合格します。しかし、それを行う唯一のCAはEquifax Secure CA（gitの単純な列挙でそれを発見したCA bundle）。誰かがなぜそうなのか説明できますか？どうもありがとう。

UPD：それはグーグルの行動だけではなく、別のサイトもそのように振る舞うので、私は何かを誤解している（それはありそうです）か、間違った情報が表示されていると思います（もう一度、これはなぜ起こっているのですか）

tlscertificatescertificate-authoritygooglex.509
5
zogby

これはおそらく時代遅れの「ブリッジ」であり、現在間違った場所につながっています。

この証明書には2つの有効な信頼チェーンがあります。 2002年から有効なGeoTrust Global CAのルート証明書があり、現在のWindows/IEおよびFirefoxストア（およびJava）にあります。また、Equifax Global CAに基づくそのCAの「クロス署名された」証明書は次のとおりです。

Data:
    Version: 3 (0x2)
    Serial Number: 1227750 (0x12bbe6)
Signature Algorithm: sha1WithRSAEncryption
    Issuer: C=US, O=Equifax, OU=Equifax Secure Certificate Authority
    Validity
        Not Before: May 21 04:00:00 2002 GMT
        Not After : Aug 21 04:00:00 2018 GMT
    Subject: C=US, O=GeoTrust Inc., CN=GeoTrust Global CA
    Subject Public Key Info: <snipped: same as root>
   X509v3 extensions:
        X509v3 Authority Key Identifier:
            keyid:48:E6:68:F9:2B:D2:B2:95:D7:47:D8:23:20:10:4F:33:98:90:9F:D4
        X509v3 Subject Key Identifier:
            C0:7A:98:68:8D:89:FB:AB:05:64:0C:11:7D:AA:7D:65:B8:CA:CC:4E
        X509v3 Basic Constraints: critical
            CA:TRUE
        X509v3 Key Usage: critical
            Certificate Sign, CRL Sign
        X509v3 CRL Distribution Points:
            Full Name:
              URI:http://crl.geotrust.com/crls/secureca.crl
        X509v3 Certificate Policies:
            Policy: X509v3 Any Policy
              CPS: https://www.geotrust.com/resources/repository
<snip signature>

これは明らかに「ブリッジ」証明書であり、名前が変更された（ここ）または新しいCAルートが作成され、古いCAルートの既存の信頼を一時的に利用したい場合によく使用されます。 Equifaxルートは1998年から有効なので、たとえば1999年と2000年には、GeoTrustルートではなくEquifaxルートを知っているクライアントがたくさんいました。 12年後それは時代遅れになるはずです。

「openssl s_client」を実行すると、www.google.com.uaがSSLハンドシェイクで独自の証明書、Google Internet Authority G2中間証明書、およびブリッジ証明書を提供していることが確認されます。 IE、FF、およびJavaはすべて、ブリッジを無視して、内部に格納されているGeoTrustルートを使用するのに十分スマートです。curlが使用するOpenSSLは、使用されていないか、少なくとも使用されていません。 curlにOpenSSLにEquifaxルートを与えるように指示する必要があります（現在ベータ版のOpenSSL 1.0.2リリースでは、証明書チェーン検証の領域が強化されたと発表されていますが、これについてはまだ詳しく説明していません）。

EDIT 3/13：回答にコメントできない（！）ので、ここに追加します。前述のとおり、GeoTrust Global CAには2つの証明書があります。1つはルート、もう1つは「ブリッジ」です。

IE/WindowsおよびFF[〜＃〜] do [〜＃〜]にはGeoTrustルートがあります。 IEまたはFFのWebページを開いた状態ですでに証明パスで確認しました。または、InternetOptions/Content/Certificates/TrustedRootsおよびTools/Options/Advanced/Certificates /を使用してトラストストアを直接見ることができます。当局。両方またにはEquifaxルートがありますが、ここでは使用しないでください。両方IEおよびFFは、サーバーが送信したもの;とは異なりますが、証明書パスusedある見方では「間違っている」が、別の見方では「正しい」かもしれません。

ルート証明書は常に自己署名されています。これはルートである必要があります（常にアンカー用ではありませんが、そのままにしておきます）。 GeoTrustルート証明書はルートです。 GeoTrustブリッジ証明書はルートではなく、ルートであるEquifaxルート証明書にリンクしています。また、Equifaxルートは、curl + opensslのニーズの1つです。

EDIT 9/01：https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=AR1426&actp = search＆viewlocale = en_US＆searchid = 1283360269668 これがEquifaxへのブリッジ証明書であることを確認します。

UPDATE 2017/03/28：最初に、OpenSSL 1.0.2は-trusted_firstを追加し、GeoTrustルートが存在する場合はそれを使用し、ブリッジ証明書を無視します。第二に、EquifaxルートがMozilla/NSSトラストストアから削除されたため、これはより重要になり、多くのクライアントが使用するcurl-project CAfileを参照してください https://serverfault.com/a/841071/ 2166 。

5
dave_thompson_085