☰

Почему я получаю несоответствия URL-адресов в моем самоподписанном сертификате Wildcard?

tag-icon • tag-icon apache-2.4 openssl self-signed-certificate
Почему я получаю несоответствия URL-адресов в моем самоподписанном сертификате Wildcard?

Я пытаюсь настроить самоподписанный wildcard-сертификат для использования Apache, обычно это довольно просто. Я просто задаю альтернативное имя субъекта с корневым доменом и указываю *.dcrdev.com в поле общего имени. Однако, похоже, это не работает - когда я пытаюсь получить доступ к сайту в Chrome или тестирую его в sslabs, они сообщают о несоответствиях URL при доступе к любому поддомену, такому как www.dcrdev.com или subdomain1.dcrdev.com. Я не уверен, почему, когда я просматриваю информацию о сертификате в 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), если оно присутствует, и CommonName (CN) в Subject, только если SAN отсутствует. В вашем сертификате присутствует SAN с dcrdev.com, поэтому соответствует только это.

обновлять:найти вRFC2818 3.1:

Если присутствует расширение subjectAltName типа dNSName, оно ДОЛЖНО использоваться в качестве идентификатора. В противном случае ДОЛЖНО использоваться (наиболее конкретное) поле Common Name в поле Subject сертификата. Хотя использование Common Name является существующей практикой, оно устарело, и центрам сертификации рекомендуется использовать вместо него dNSName.

Этот RFC был выпущен в мае 2000 года, но, насколько я помню, сертификаты, с которыми я сталкивался, начали использовать SAN только ближе к 2010 году. Более поздний — в марте 2011 года.RFC6125определенный @JennyD (работает ли это в тексте ответа?) является более общим лечением, но явно говорит

Настоящий документ также не заменяет правила проверки подлинности сервиса, изложенные в спецификациях существующих протоколов приложений, опубликованных до настоящего документа, например, те, которые приведены в Приложении B.

а приложение B включает RFC2818.

Базовые требования отФорум CA-Browserговорят, что центры сертификации должныпроблемасертификаты с SAN, в то время как Subject.CN устарел, хотя это не является прямым требованием для браузеров/клиентов.

Если вы хотите использовать как домен, так и поддомены (только один уровень), добавьте две записи dnsName в SAN: одну для , dcrdev.comа другую для *.dcrdev.com.

Связанный контент