Я пытаюсь настроить самозаверяющий сертификат с подстановочными знаками для использования 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/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
Crossdupe из https://stackoverflow.com/questions/3093112/certificateexception-no-name-matching-ssl-someurl-de-found .
Общее имя субъекта больше не контролирует сертификаты HTTPS.
AFAICT на самом деле нет стандартного высказывания, но Практика в течение нескольких лет такова, что браузеры и т. д. используют расширение SubjectAlternativeName (SAN), если оно присутствует, и CommonName (CN) в Subject, только если SAN отсутствует. В вашем сертификате присутствует SAN с dcrdev.com, так что только это соответствует.
Обновить: нашел в RFC2818 3.1 :
Если присутствует расширение subjectAltName типа dNSName, оно ДОЛЖНО использоваться в качестве идентификатора. В противном случае ДОЛЖНО использоваться (наиболее конкретное) поле Common Name в поле Subject сертификата. Хотя использование общего имени является существующей практикой, оно устарело, и центрам сертификации рекомендуется использовать вместо него dNSName.
Этот RFC был написан в мае 2000 года, но, насколько я помню, сертификаты, с которыми я столкнулся, начали использовать SAN только ближе к 2010 году. Последний март 2011 года. RFC6125 идентифицированный @JennyD (работает ли он в теле ответа?), является более общим лечением, но прямо говорит
Этот документ также не отменяет правила проверки идентичности службы, представленные в спецификациях для существующих протоколов приложений, опубликованных до этого документа, например, тех, которые приведены в Приложении B.
а приложение B включает RFC2818.
Базовые требования из Форум CA-Browser говорят, что центры сертификации должны выпуск сертификаты с SAN, в то время как Subject.CN устарел, хотя это не является прямым требованием для браузеров / клиентов.
Если вы хотите использовать и домен, и поддомены (только один уровень), поместите две записи dnsName в SAN, одну для dcrdev.com и один для *.dcrdev.com.