On 11.09.2018 6:21, Maxim Dounin wrote:

>>> Кроме того, в некоторых случаях для проверки может хватить
>>> сертификатов, уже присутствующих в цепочке сертификата (по идее
>>> должно хватать 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.
>>
>> Не лучше ли было бы для этих двух разных задач
>> иметь и две разные директивы?

> Лучше всего - сделать так, чтобы OpenSSL научился проверять
> OCSP-ответы не полной цепочкой сертификатов вплоть до доверенного
> root'а, а ровно так, как и должно быть по стандарту - с помощью
> одного только сертификата issuer'а. Тогда проблема исчезнет.

А разработчики OpenSSL разве знают об этой проблеме?
На гитхабе https://github.com/openssl/openssl/issues
я не нашел issue в которой бы описывалась эта проблема.

Но даже если вдруг новые версии OpenSSL научатся проверять OCSP-ответы
с помощью одного только сертификата issuer'а - проблема не исчезнет.

Потому что останется огромное количество операционных систем,
в которых будет установлена старая версия OpenSSL, например,
CentOS/RHEL. Новые версии этой системы выходят очень редко.

И потребуется как минимум 5-10 лет, прежде чем новые версии
OpenSSL вытеснят старые версии OpenSSL из всех дистрибутивов.

> Пытаться же изобретать костыли, чтобы решить проблему кривых
> интерфейсов OpenSSL - это бессмысленная деятельность, на выходе
> которой ничего кроме костылей получиться не может. Просто по
> определению.

Кроме OpenSSL есть и другие библиотеки, например, BoringSSL
- там эта проблема тоже присутствует, насколько я понимаю?
И разработчики BoringSSL тоже ничего не знают об этом?

--
Best regards,
Gena

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru