☰

ワイルドカード自己署名証明書で URL の不一致が発生するのはなぜですか?

tag-icon • tag-icon apache-2.4 openssl self-signed-certificate
ワイルドカード自己署名証明書で URL の不一致が発生するのはなぜですか?

Apache で使用するために自己署名ワイルドカード証明書を設定しようとしています。通常、これは非常に簡単で、ルート ドメインでサブジェクト代替名を設定し、共通名フィールドに *.dcrdev.com を指定するだけです。ただし、これは機能していないようです。Chrome でサイトにアクセスしようとしたり、SSLabs でテストしたりすると、www.dcrdev.com や subdomain1.dcrdev.com などのサブドメインにアクセスすると URL の不一致が報告されます。理由はわかりませんが、Chrome で証明書情報を表示すると、共通名が *.dcrdev.com として表示されます。

私のCSR:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Development, CN=*.dcrdev.com/[email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                lah blah

私の証明書:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1048577 (0x100001)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Root Authority, CN=*.dcrdev.com/[email protected]
        Validity
            Not Before: Oct 13 23:41:03 2015 GMT
            Not After : Oct 10 23:41:03 2025 GMT
        Subject: C=GB, ST=South Yorkshire, L=Sheffield, O=DCR Holdings, OU=DCR Development, CN=*.dcrdev.com/[email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
               Blah blah
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                83:2D:84:F1:E2:B0:72:30:E6:3B:6A:F6:8E:6A:68:8E:3F:D4:69:44
            X509v3 Authority Key Identifier: 
                keyid:F5:A6:82:E2:DD:52:10:CE:FD:C5:C7:E1:E9:CF:C6:8C:30:26:D7:DC

            X509v3 Subject Alternative Name: 
                DNS:dcrdev.com
            X509v3 Key Usage: 
                Digital Signature, Non Repudiation, Key Encipherment
    Signature Algorithm: sha256WithRSAEncryption
        Blah blah

答え1

クロスデュープのhttps://stackoverflow.com/questions/3093112/certificateexception-no-name-matching-ssl-someurl-de-found。

サブジェクト共通名は HTTPS 証明書を制御しなくなりました。

私の知る限り、実際にそう言う基準はないが、ここ数年の慣例では、ブラウザなどは、存在する場合は SubjectAlternativeName (SAN) 拡張子を使用し、SAN が存在しない場合にのみ、Subject に CommonName (CN) を使用します。証明書には SAN が存在するためdcrdev.com、一致するのは のみです。

アップデート：見つかったRFC2818 3.1:

タイプ dNSName の subjectAltName 拡張が存在する場合、それを ID として使用する必要があります。それ以外の場合は、証明書のサブジェクト フィールドの (最も具体的な) Common Name フィールドを使用する必要があります。Common Name の使用は既存の慣行ですが、非推奨であり、認証局は代わりに dNSName を使用することが推奨されます。

そのRFCは2000年5月だったが、私の記憶では、私が遭遇した証明書は2010年近くまでSANを使用し始めていなかった。より最近の2011年3月のRFC6125@JennyDによって特定された（回答の本文で機能するでしょうか？）はより一般的な治療法ですが、明示的に

また、このドキュメントは、付録 B に抜粋されているような、このドキュメントより前に公開された既存のアプリケーション プロトコルの仕様で提供されているサービス ID の検証ルールに取って代わるものではありません。

付録 B には RFC2818 が含まれています。

ベースライン要件CA-ブラウザフォーラムCAは問題SAN を使用した証明書は推奨されますが、Subject.CN は非推奨です。ただし、これはブラウザ/クライアントでは直接の要件ではありません。

ドメインとサブドメイン (1 レベルのみ) の両方を使用する場合は、 とdcrdev.comの2 つの dnsName エントリを SAN に配置します*.dcrdev.com。

関連情報