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.
