Страницы

Поиск по вопросам

пятница, 1 марта 2019 г.

Сайт на apache 2 при доступе по ip через https предупреждает о небезопасном соединении

Дано:
debian, apache2 на vps, ssl-сертификат и домен.
Сертификат вот так подключен в настройках apache
файл /etc/apache2/apache2.conf
DocumentRoot "/var/www/html" ServerName mydomain.ru ServerAlias www.mydomain.ru
# Other directives here SSLEngine on SSLCertificateFile /path/to/domain_name.crt SSLCertificateKeyFile /path/to/private.key SSLCertificateChainFile /path/to/chain.crt

DocumentRoot "/var/www/html" ServerName mydomain.ru ServerAlias www.mydomain.ru
# Other directives here

Сам домен ещё не до конца, видимо, прописался на dns серверах и я пробую к сайту через IP ходить.
Проблема:
В итоге я могу по адресам http://x.x.x.x и https://x.x.x.x попасть на сайт, но в случае https браузер жутко ругается на небезопасность соединения. При этом в информации о сертификате браузер говорит что всё ОК и сертификат этот связан с моим доменом.
Вопрос:
Так и должно быть и проблема исчезнет когда я буду на сайт ходить по имени домена вместо IP? Можно ли это починить чтобы я мог ходить по IP-адресу без ругани на безопасность?


Ответ

ответ частично основан на этом ответе

сертификат, соответствующий стандарту x.509, удостоверят «имя субъекта» (subject). наиболее интересно нам «общепринятое имя» (common name), являющееся частью «имени субъекта».
как правило, оно содержит fqdn. пример для сертификата, которым подтверждается аутентичность http-сервера, доступного по доменному имени ya.ru
$ : | openssl s_client -connect ya.ru:443 2>/dev/null | openssl x509 -noout -subject -nameopt RFC2253 subject=CN=ya.ru,ST=Russian Federation,L=Moscow,OU=ITO,O=Yandex LLC,C=RU
CN=ya.ru — вот это и есть подтверждаемое сертификатом «общепринятое имя» (common name, сокращённо cn) — ya.ru
с точки зерния стандарта «общепринятое имя», в общем, произвольно. и в применении к сертификатам, подтверждающим аутентичность http-сервера может, теоретически, содержать не доменное имя, а, например, ip-адрес: ведь он ничем не «хуже», чем любая другая произвольная строка символов. но на практике такое не встречается (хотя на сайте у какого-то из регистраторов я даже встечал упоминание возможности подтвердить сертификатом ip-адрес).
стоит упомянуть, что нынче одним сертификатом может подтверждаться целый набор доменных имён. пример с тем же сертификатом:
$ : | openssl s_client -connect ya.ru:443 2>/dev/null | openssl x509 -noout -text | grep DNS DNS:ya.ru, DNS:www.ya.ru, DNS:m.ya.ru

выданный же вам сертификат с вероятностью, равной единице, удоствоверяет именно доменное имя.
убедитесь сами:
$ cat файл.с.сертификатом | openssl x509 -noout -subject -nameopt RFC2253
поэтому вполне естественным является предупреждение от вашего http-клиента о небезопасности соединения — ведь строка какое-то.доменное.имя (которую он «видит» внутри сертификата) абсолютно не совпадает со строкой какой-то.ip-адрес (которую вы ввели в адресной строке клиента).

по поводу того, как же проверить сертификат (средствами http-клиента), если доменное имя пока не резолвится в нужный ip-адрес, посмотрите, например, этот ответ

Комментариев нет:

Отправить комментарий