<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">вт, 11 сент. 2018 г. в 13:10, Gena Makhomed <<a href="mailto:gmm@csdoc.com">gmm@csdoc.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11.09.2018 6:21, Maxim Dounin wrote:<br>
<br>
>>> Кроме того, в некоторых случаях для проверки может хватить<br>
>>> сертификатов, уже присутствующих в цепочке сертификата (по идее<br>
>>> должно хватать issuer cert, которые есть в цепочке почти всегда,<br>
>>> но, к сожалению, соответствующие функции в OpenSSL, cкажем так,<br>
>>> оставляют желать - и это, собственно, основная причина, почему<br>
>>> ssl_stapling_verify не используется по умолчанию).<br>
>><br>
>> Но ведь SSL сертификаты - это обычные текстовые файлы.<br>
>> Например, если для сайта <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> сравнить два файла<br>
>><br>
>> /etc/letsencrypt/live/<a href="http://example.com/fullchain.pem" rel="noreferrer" target="_blank">example.com/fullchain.pem</a><br>
>> /etc/letsencrypt/live/<a href="http://example.com/chain.pem" rel="noreferrer" target="_blank">example.com/chain.pem</a><br>
>><br>
>> то видно что файл chain.pem равен файлу fullchain.pem<br>
>> плюс дополнительный сертификат сайта на самом верху.<br>
>><br>
>> Можно ли сделать для директивы ssl_trusted_certificate параметр auto<br>
>> который будет означать автоматическое получение файла chain.pem путем<br>
>> вырезания самого первого сертификата из файла fullchain.pem?<br>
>><br>
>> В таком случае можно было бы сделать значением по-умолчанию<br>
>> ssl_trusted_certificate auto; и ssl_stapling_verify on;<br>
>> И веб-сервер nginx тогда будет "Secure by default".<br>
>><br>
>> Хотя, проверка клиентских сертификатов и проверка ответов OCSP<br>
>> - это две совсем разные задачи, странно что для них используется<br>
>> в nginx одна и та же директива ssl_trusted_certificate.<br>
>><br>
>> Не лучше ли было бы для этих двух разных задач<br>
>> иметь и две разные директивы?<br>
<br>
> Лучше всего - сделать так, чтобы OpenSSL научился проверять<br>
> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного<br>
> root'а, а ровно так, как и должно быть по стандарту - с помощью<br>
> одного только сертификата issuer'а. Тогда проблема исчезнет.<br>
<br>
А разработчики OpenSSL разве знают об этой проблеме?<br>
На гитхабе <a href="https://github.com/openssl/openssl/issues" rel="noreferrer" target="_blank">https://github.com/openssl/openssl/issues</a><br>
я не нашел issue в которой бы описывалась эта проблема.<br></blockquote><div><br></div><div>а вы напишите им. я проверял, это работает<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Но даже если вдруг новые версии OpenSSL научатся проверять OCSP-ответы<br>
с помощью одного только сертификата issuer'а - проблема не исчезнет.<br>
<br>
Потому что останется огромное количество операционных систем,<br>
в которых будет установлена старая версия OpenSSL, например,<br>
CentOS/RHEL. Новые версии этой системы выходят очень редко.<br>
<br>
И потребуется как минимум 5-10 лет, прежде чем новые версии<br>
OpenSSL вытеснят старые версии OpenSSL из всех дистрибутивов.<br>
<br>
> Пытаться же изобретать костыли, чтобы решить проблему кривых<br>
> интерфейсов OpenSSL - это бессмысленная деятельность, на выходе<br>
> которой ничего кроме костылей получиться не может. Просто по<br>
> определению.<br>
<br>
Кроме OpenSSL есть и другие библиотеки, например, BoringSSL<br>
- там эта проблема тоже присутствует, насколько я понимаю?<br>
И разработчики BoringSSL тоже ничего не знают об этом?<br>
<br>
-- <br>
Best regards,<br>
Gena<br>
<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div></div>