SSL - Как общие имена (CN) и альтернативные имена субъектов (SAN) работают вместе?

Question

Предполагая, что свойство Subject Alternative Name (SAN) сертификата SSL содержит два DNS-имени

1. domain.tld
2. host.domain.tld

но для общего имени (CN) установлено только одно из: CN=domain.tld.

• Имеет ли эта настройка особое значение или какие-либо преимущества [dis] по сравнению с настройкой обоих CN?
• Что происходит на стороне сервера, если запрашивается другой, host.domain.tld?

EDIT:

Как недавно узнал из ответа Юджина, что поведение отличается от реализации, я хочу получить более конкретную информацию: как OpenSSL 0.9.8b + обрабатывает данный сценарий?

Answer 1

Это зависит от реализации, но общее правило состоит в том, что домен проверяется по всем SAN и общему имени. Если домен там найден, то сертификат в порядке для подключения.

RFC 5280 , раздел 4.1.2.6 гласит: «Имя субъекта МОЖЕТ быть перенесено в поле субъекта и / или расширение subjectAltName». Это означает, что имя домена должно быть проверено как по расширению SubjectAltName, так и по свойству Subject (а именно, это параметр общего имени) сертификата. Эти два места дополняют друг друга, а не дублируют его. И SubjectAltName является подходящим местом для добавления дополнительных имен, таких как www .domain.com или www2 .domain.com

Обновление: согласно RFC 6125 , опубликованному в 2011 году, валидатор должен сначала проверить SAN, а если SAN существует, то CN не должен проверяться. Обратите внимание, что RFC 6125 является относительно новым и все еще существуют сертификаты и CA, которые выпускают сертификаты, которые включают в себя «основное» доменное имя в CN и альтернативные доменные имена в SAN. То есть исключив CN из проверки, если SAN присутствует, вы можете отказать в каком-либо другом действительном сертификате.

Answer 2

Чтобы быть абсолютно правильным, вы должны поместить все имена в поле SAN.

Поле CN должно содержать имя субъекта, а не имя домена, но когда Netscape обнаружил эту вещь SSL, они не смогли определить его самый большой рынок. Просто для URL сервера не было определено поле сертификата.

Это было решено, чтобы поместить домен в поле CN, и в настоящее время использование поля CN устарело, но все еще широко используется. CN может содержать только одно доменное имя.

Общие правила для этого: CN - укажите здесь свой основной URL (для совместимости) SAN - поместите здесь весь свой домен, повторите CN, потому что он там не в нужном месте, но используется для этого ...

Если вы нашли правильную реализацию, ответы на ваши вопросы будут следующими:

• Имеет ли эта настройка особое значение или какие-либо преимущества [dis] по сравнению с настройкой обоих CN? Вы не можете установить оба CN, потому что CN может содержать только одно имя. Вы можете сделать с двумя простыми сертификатами CN вместо одного сертификата CN + SAN, но для этого вам нужно 2 IP-адреса.

• Что происходит на стороне сервера, если запрашивается другой, host.domain.tld? Не имеет значения, что происходит на стороне сервера.

Короче говоря: Когда клиент браузера подключается к этому серверу, браузер отправляет зашифрованные пакеты, которые зашифрованы с помощью открытого ключа сервера. Сервер расшифровывает пакет, и если сервер может расшифровать, то он был зашифрован для сервера.

Сервер ничего не знает от клиента до расшифровки, потому что только IP-адрес не шифруется через соединение. Вот почему вам нужно 2 IP для 2 сертификатов. (Забудьте о SNI, сейчас слишком много опыта.)

На стороне клиента браузер получает CN, затем SAN, пока все они не будут проверены. Если для сайта совпадает одно из имен, то проверка URL была выполнена браузером. (я не говорю о проверке сертификата, конечно, в сети каждый раз отправляется множество запросов ocsp, crl, aia и ответов.)

Answer 3

Базовые требования CABForum

Я вижу, что никто еще не упомянул раздел в Базовых требованиях.Я чувствую, что они важны.

Q: SSL - Как общие имена (CN) и альтернативные имена субъектов (SAN) работают вместе?
A: Не за что.Если есть SAN, то CN можно игнорировать.- По крайней мере, если программное обеспечение, выполняющее проверку, очень строго соответствует Базовым требованиям CABForum.

(Таким образом, это означает, что я не могу ответить на «Изменить» на ваш вопрос. Только оригинальный вопрос.)

Базовые требования к CABForum, v. 1.2.5 (по состоянию на 2 апреля 2015 г.), стр. 9-10 :

9.2.2 Тема выделенаИмя Поля
a.Поле общего имени субъекта
Поле сертификата: subject: commonName (OID 2.5.4.3)
Обязательно / необязательно: Устаревшее (не рекомендуется, но не запрещено)
Содержание: Если присутствует, это поле ДОЛЖНО содержать один IP-адрес или Полное доменное имя, которое является одним из значений, содержащихся в расширении subjectAltName Сертификата (см. Раздел 9.2.1).

РЕДАКТИРОВАТЬ: Ссылки из комментария @ Бруно

RFC 2818: HTTP через TLS , 2000, Раздел 3.1: СерверИдентичность :

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

RFC 6125: Представление и проверкаИдентификация службы приложений на основе домена в инфраструктуре открытых ключей Интернета с использованием сертификатов X.509 (PKIX) в контексте безопасности транспортного уровня (TLS) , 2011, Раздел 6.4.4: Проверка общих имен :

[...] тогда и только тогда, когда представленные идентификаторы не включают в себя DNS-ID, SRV-ID, URI-ID или любые типы идентификаторов, специфичные для приложения, поддерживаемые клиентом,тогда клиент МОЖЕТ в качестве последней инстанции проверить строку, форма которой соответствует форме полного доменного имени DNS в поле Common Name предметного поля (т. е. CN-ID).