Это сценарий ...
$ openssl x509 -subject -noout -in cert.crt
subject= /CN=example.org
$ curl -I "https://example.org"
HTTP/1.1 200 OK
$ dig example.org
example.org. 60 IN A 192.0.2.1
$ dig foo.example.org
foo.example.org. 60 IN CNAME example.example2.com.
example.example2.com. 60 IN A 192.0.2.1
$ curl -I "https://foo.example.org"
HTTP/1.1 200 OK
$ curl -I "https://example.example2.com"
curl: (51) Unable to communicate securely with peer: requested domain name does not match the server's certificate.
Когда псевдоним foo.example.org используется Я не вижу CNAME example.example2.com. Так что на самом деле не имеет значения, что CNAME не соответствует имени сертификата.
Но кто-то спросил меня, какое из трех имен должен использоваться. Я ответил, что можно использовать все три, кроме example.example2.com для SSL.
Мне это кажется странным с точки зрения конечного пользователя. Сертификат говорит мне example.org является доверенным именем, но записи организации в домене example.org скажите мне, что ненадежное имя - в другом домене - это каноническое (официальное) имя.
Также, example.org и example2.com есть записи SOA. Имена с поддоменами не будут содержать записей SOA. Я не уверен, имеет ли запись SOA какое-либо отношение к тому, что следует считать разумным каноническим именем.
Прежде всего, чтобы не возникло путаницы в отношении самой проверки сертификата, DNS не является фактором в процессе проверки имени субъекта сертификата.
Клиенту HTTPS не нужно знать или заботиться о том, были ли CNAME записи, обнаруженные в процессе разрешения имен. Он использует только IP-адрес, которому соответствует имя хоста URL, чтобы установить соединение, а затем напрямую сравнивает имя хоста URL и имя (имена) субъекта при проверке действительности сертификата, представленного сервером.
Что касается вопроса «какое из трех имен следует использовать?» владелец сервиса / сайта избавит себя от головной боли, если он просто выберет одно имя, которое следует использовать, и даст всем понять, что нужно использовать это имя.
Если речь идет о веб-сайте, обычно настраивают перенаправление HTTP для любых запросов к альтернативным именам, перенаправляя эти запросы на предпочтительное имя (это было бы довольно красноречиво относительно того, какое имя предпочтительнее).
Если речь идет об API или другом сервисе, где перенаправления на самом деле не работают, предпочтительное имя, вероятно, по крайней мере указано в описании / документации сервиса.
Можно было бы также разумно ожидать, что предпочтительное имя имеет действующий сертификат, так что клиенты могут использовать HTTPS (очень норма).
Я намеренно избегаю термина «каноническое имя», чтобы четко отделить эти рассуждения от CNAME тип записи.
Без дополнительных знаний любой CNAME запись, которую вы видите, можно только предположить, что это ссылка на другое имя, которое владелец домена хочет, чтобы преобразователь следовал для завершения поиска.
Аспект "канонического имени" в этом в значительной степени утрачен, поскольку CNAME записи обычно используются в качестве взлома для обеспечения косвенного доступа общего назначения (часто в местах, где SRV теоретически имеет смысл, но там, где нет клиентов SRV-сознавать, как и в случае с обычными клиентами HTTP / HTTPS).