Как система Enterprise Linux с openssl 1.0.1+ проверяет, что CN=hostnameзначение в сертификате соответствует серверу, на котором он находится? Использует ли она обычный старый обратный DNS-поиск по IP-адресу адаптера, который прослушивает это веб-приложение SSL? Использует ли она какую-либо библиотечную функцию gethostname? Будет ли она читать файл /etc/hosts? Играет ли nsswitch.conf какую-либо роль?
Обновлять: После разговора с кем-то еще, похоже, что все это делается на стороне браузера/клиента. Пока хостовая часть URL соответствует значению CN в сертификате, который установлен для этого приложения, браузер счастлив, верно?
решение1
Да, то, что вы описали, технически верно, но есть еще кое-что. Браузер определяет, что CN хоста правильный, основываясь на нескольких индикаторах.
Основным признаком является то, что хост, обслуживающий SSL-сертификат трафика HTTPS, обслуживается из правильного домена, а также что цепочка подписей сертификата также верна на основе CA (центра сертификации), который выдал и подписал сертификат.
Вы можете использовать openssl's, s_clientчтобы получить представление о том, какие операции вперед и назад будет выполнять ваш браузер.
Пример
$ openssl s_client -connect encrypted.google.com:443 < /dev/null | head -10
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com
verify return:1
CONNECTED(00000003)
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
i:/C=US/O=Google Inc/CN=Google Internet Authority G2
1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
...
...
DONE
Если вы используете эту команду, вы увидите CN, который использовался при генерации SSL-сертификатов:
$ openssl s_client -connect encrypted.google.com:443 < /dev/null|& grep "CN.*google"
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
Таким образом, браузер подтвердит, что имя хоста, обслуживающее этот сертификат, входит в иерархию, CN=...включенную в сертификат.
СНИ
Раньше вам приходилось иметь определенный IP-адрес, выделенный для имени хоста каждого сервера SSL, который вы хотели использовать через HTTPS. Однако теперь это не так благодаря SNI (Server Name Indication).
выдержка
Это работает очень хорошо, когда на сайте установлен один сертификат SSL на IP-адрес (раньше это было жестким требованием). С помощью Server Name Indication (SNI) веб-сервер может иметь несколько сертификатов SSL, установленных на одном IP-адресе. Браузеры с поддержкой SNI будут указывать имя хоста сервера, к которому они пытаются подключиться, во время первоначального процесса установления связи. Это позволяет веб-серверу определить правильный сертификат SSL для использования при подключении.
Опять же, используя opensslвы можете смоделировать действия вашего браузера в этом сценарии:
$ openssl s_client -connect someserver:443 -servername sslsite-example.com
выдержка
Согласование SSL должно происходить до отправки HTTP-запроса на удаленный сервер. Это означает, что браузер и сервер должны выполнить обмен сертификатами ранее в процессе, и браузер не получит возможности указать, к какому сайту он пытается обратиться. SNI исправляет это, разрешая тип заголовка Host: обмена во время процесса согласования SSL.