Вопросы Теги

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

Я пытаюсь настроить сам подписанный Wildcard-сертификат для использования Apache, обычно это довольно просто, я просто определил subjectalternate имя с корневым доменом и указываю *.dcrdev.com в поле общего названия. Однако кажется, что это не работает - когда я пытаюсь получить доступ к сайту в хроме или протестировать его в плитах, они сообщают о несоответствиях URL при доступе к любому субдомену, таких как www.dcrdev.com или subdomain1.dcrdev.com. Я не уверен, почему, когда я просматриваю информацию о сертификате в хроме, это показывает общее название *.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/emailAddress=webmaster@dcrdev.com
        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/emailAddress=administrator@dcrdev.com
        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/emailAddress=webmaster@dcrdev.com
        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
задан 14 October 2015 в 11:45
1 ответ

Перекрестие https://stackoverflow.com/questions/3093112/certificateexception-no-name-matching-ssl-someurl-de-found .

Subject Common Name больше не контролирует сертификаты HTTPS.

AFAICT на самом деле нет стандартного утверждения, но практика уже несколько лет такова, что браузеры и т. Д. Используют расширение SubjectAlternativeName (SAN), если оно присутствует, а CommonName (CN) в Subject - только при отсутствии SAN. В вашем сертификате присутствует SAN с dcrdev.com , поэтому соответствует только это.

обновление: найдено в RFC2818 3.1 :

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

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

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

и приложении B содержится RFC2818.

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

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

5
ответ дан 3 December 2019 в 17:05

Теги

Похожие вопросы