вт, 11 сент. 2018 г. в 0:38, Gena Makhomed <g...@csdoc.com>: > On 10.09.2018 16:04, Maxim Dounin wrote: > > >> Если с помощью Let's Encrypt сделать SSL-сертификат > >> для домена,например, example.com то в файле > >> /etc/letsencrypt/live/example.com/README > >> будет такая информация: > >> > >> `chain.pem` : used for OCSP stapling in Nginx >=1.3.7. > >> > >> Чтобы nginx использовал файл chain.pem для OCSP stapling > >> необходимо прописать в конфиге > >> > >> ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; > >> ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; > >> ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem; > >> > >> ssl_stapling on; > >> ssl_stapling_verify on; > >> resolver 8.8.8.8 1.1.1.1 9.9.9.9 ipv6=off; > >> > >> я правильно понимаю? > > > Just a side note: использование сторонних DNS-серверов - это > > плохое решение. Цитируя документацию: > > > : Для предотвращения DNS-спуфинга рекомендуется использовать > > : DNS-серверы в защищённой доверенной локальной сети. > > Разве сервера 8.8.8.8, 1.1.1.1 и 9.9.9.9 подвержены атаке DNS spoofing? > https://en.wikipedia.org/wiki/DNS_spoofing > > >> Смущает тот факт, что если закомментировать > >> в конфиге директиву ssl_trusted_certificate > >> - никаких предупреждений не выводится во время > >> тестирования конфигурации и никаких сообщений > >> не пишется в лог во время systemctl reload nginx > > > Верификация OCSP-ответов - происходит только в момент собственно > > получения этих ответов. Соответственно каких-либо ошибок в логе > > стоит ожидать только после того, как к соответствующему server'у > > будет установлено первое соединение с запросом stapling'а. > > Но если в конфиге нет директивы ssl_trusted_certificate то директива > ssl_stapling_verify on; сейчас работать не сможет в 100% случаев? > > > Кроме того, в некоторых случаях для проверки может хватить > > сертификатов, уже присутствующих в цепочке сертификата (по идее > > должно хватать issuer cert, которые есть в цепочке почти всегда, > > но, к сожалению, соответствующие функции в OpenSSL, cкажем так, > > оставляют желать - и это, собственно, основная причина, почему > > ssl_stapling_verify не используется по умолчанию). > > Но ведь SSL сертификаты - это обычные текстовые файлы. > Например, если для сайта example.com сравнить два файла > > /etc/letsencrypt/live/example.com/fullchain.pem > /etc/letsencrypt/live/example.com/chain.pem > > то видно что файл chain.pem равен файлу fullchain.pem > плюс дополнительный сертификат сайта на самом верху. > > Можно ли сделать для директивы ssl_trusted_certificate параметр auto > который будет означать автоматическое получение файла chain.pem путем > вырезания самого первого сертификата из файла fullchain.pem? > > В таком случае можно было бы сделать значением по-умолчанию > ssl_trusted_certificate auto; и ssl_stapling_verify on; > И веб-сервер nginx тогда будет "Secure by default". > > Хотя, проверка клиентских сертификатов и проверка ответов OCSP > - это две совсем разные задачи, странно что для них используется > в nginx одна и та же директива ssl_trusted_certificate. > > Не лучше ли было бы для этих двух разных задач > иметь и две разные директивы? > > Например, > ssl_trusted_certificate - только для проверки клиентских сертификатов > и ssl_stapling_trusted_certificate - только для проверки ответов OCSP > > и уже для директивы ssl_stapling_trusted_certificate > сделать значение по-умолчанию равное auto? > > IMHO это был бы практически идеальный вариант, > поскольку будет работать предсказуемым образом > вне зависимости от имени и версии используемой > при сборке nginx SSL-библиотеки. > > >> Насколько я понимаю, ssl_stapling_verify on > >> следует включать всегда, потому что общение > >> с OCSP сервером происходит по протоколу HTTP? > >> По крайней мере, в самом сертификате написано: > >> OCSP: URI: http://ocsp.int-x3.letsencrypt.org > > > Да, общение с OCSP-сервером происходит по HTTP. Но на самом деле > > это мало влияет на то, следует ли использовать ssl_stapling_verify > > или нет - самому nginx'у всё равно, что написано в OCSP-ответе. > > Вопрос в первую очередь в поведении браузеров. > > > Когда я последний углублялся в тему - Firefox остро реагировал на > > некорректные OCSP-ответы в стаплинге, не пытаясь самостоятельно > > перезапросить OCSP-ответ с OCSP-сервера, и это естественным > > образом приводило к тому, что подсунув серверу некорректный > > OCSP-ответ - можно было выключить его для всех пользователей > > Firefox'а[1]. Что, впрочем, не мешало Apache не иметь даже > > возможности для верификации OCSP-ответов. Не в курсе, изменилось > > ли с тех пор что-нибудь. > > > > [1] https://trac.nginx.org/nginx/ticket/425#comment:2 > > То есть, ssl_stapling_verify on; в nginx следует включать всегда > и нет никаких разумных причин, почему системный администратор > может захотеть сделать ssl_stapling_verify off; для своего сайта? >
у клиентов может быть неправильное время (например, они так могут делать при вводе документов в 1С) если вы им отдадите ocsp stapling, то с точки зрения браузера сертификат невалиден, и почему-то браузеры так запрограммированы, что кнопки "игнорировать, покажите мне уже сайт" у клиента не будет. > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru