Re: параметр Exim, отвечающий за intermediate-сертификат
Sohin Vyacheslav -> debian-russian@lists.debian.org @ Fri, 5 Feb 2016 12:56:28 +0200:
>> >> А отношение к делу имеют tls_certificate и tls_privatekey. И в
>> >> tls_certificate не надо класть private key. У них, собственно, и
>> >> права-то обычно разные. Сертификат - публичная информация, а секретный
>> >> ключ - отнюдь. А вот оба сертификата - и свой, и промежуточный - как
>> >> раз надо, именно в этом порядке.
SV> я убрал ключ из exim.crt и раскомментировал строку с exim.key в
SV> exim4.conf => всё так-же работает, визуально в логе ничего не изменилось...
SV> в http://www.rldp.ru/exim/exim480r/glava38.htm указано:
SV> tls_certificate =/some/file/name
SV> tls_privatekey =/some/file/name
SV> Это может быть один и тот же файл, если в нём содержатся сертификат и ключ.
Да. Но поскольку степень их публичности разная, делать так вряд ли полезно.
>> В моем случае я пользуюсь собственным CA, и у меня нет промежуточного,
>> но разница должна быть исключительно в содержимом файла, на который
>> указывает tls_certificate.
>>
>> А глядя на конфиг на ноутбуке (на ноуте, в отличие от сервера, он у меня
>> не ручной, а сконфигурированный через дебиановскую систему), я наблюдаю,
>> что дефолты будут такие:
>>
>> tls_advertise_hosts = *
>> tls_certificate = /etc/exim4/exim.crt
>> tls_privatekey = /etc/exim4/exim.key
>> tls_verify_certificates = /etc/ssl/certs/ca-certificates.crt
>>
>> (требовать клиентских сертификатов он при этом не будет, поскольку
>> tls_verify_hosts и tls_try_verify_hosts не выставлены; но тут видно, что
>> tls_verify_certificates - это набор сертификатов CA, которыми подписаны
>> клиентские, что логично)
>>
SV> в http://www.rldp.ru/exim/exim480r/glava38.htm также указано:
SV> Если установлена опция tls_verify_certificates, она должна быть именем
SV> файла или (только для OpenSSL, не для GnuTLS) каталогом, который как
SV> ожидается содержит коллекцию серверных сертификатов.
SV> имеется в виду не сертификат exim.crt, a ca-certificates.crt?
Точно не exim.crt (разве что ты собираешься принимать себя самого как
сетевого клиента). Но вот насчет ca-certificates - вопрос мутный. В
переводе слово "сереверных" - гонево. Речь идет про _клиентские_
сертификаты. В оригинальной документации сказано
The contents of the certificate are verified by comparing it with a list of expected certificates.
These may be the system default set (depending on library version),
an explicit file or, depending on library version, a directory, identified by tls_verify_certificates.
Что, с одной стороны, как бы делает вид, что по списку проверяется
именно сертификат, предъявленный клиентом, а не то, что он подписан
одним из этих CA, и в этом есть логика - мало ли кто что подписал. С
другой - ни одна из двух используемых библиотек TLS не имеет system
default set именно сертификатов самих агентов. Имеет system default set
только сертификатов CA, возможо, только корневых и самоподписанных.
Дебиановский дефолт тут может оказаться не аргументом.
Но я все же подозреваю, что это - сертификаты CA, то есть дефолтны
дебиановский конфиг делается правильно. В норме никто не проверяет сами
сертификаты серверов, проверяют только подпись достаточно доверенного
CA.
Reply to: