Ответ 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 является относительно недавним, и все еще существуют сертификаты и центры сертификации, которые выдают сертификаты, которые включают "основное" доменное имя в CN и альтернативные имена доменов в SAN. То есть исключив CN из проверки, если присутствует SAN, вы можете лишить какой-либо другой действующий сертификат.

Ответ 2

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

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

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

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

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

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

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

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

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

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

Ответ 3

Исходные требования CABForum

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

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

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

CABForum Baseline Requirements, v. 1.2.5 (по состоянию на 2 апреля 2015 г.), стр. 9-10:

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

EDIT: Ссылки из комментария @Bruno

RFC 2818: HTTP Over TLS, 2000, Раздел 3.1: Идентификатор сервера:

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

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

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