Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
параметр Exim, отвечающий за intermediate-сертификат
210 views
Skip to first unread message
Sohin Vyacheslav
Feb 3, 2016, 9:00:05 AM2/3/16
to
День добрый,
при использовании не-самоподписанного, а коммерческого сертификата
присутствуют 3 файла:
domain.com.certificate.key
domain.com.certificate
и intermediate.certificate
для Dovecot указал в /etc/dovecot/conf.d/10-ssl.conf:
ssl_cert_file = /etc/dovecot/domain.com.crt
ssl_key_file = /etc/dovecot/domain.com.key
ssl_ca_file = /etc/dovecot/intermediate.crt
а для Exim не нахожу в документации параметра относительно
intermediate.certificat...
сейчас в exim4.conf:
tls_on_connect_ports = 465
tls_advertise_hosts = *
tls_certificate = /etc/exim4/exim.crt
tls_privatekey = /etc/exim4/exim.key
при подключении по telnet к 465 порту в логе Exim ошибка:
TLS error ... (gnutls_handshake): An unexpected TLS packet was received.
пробовал объединить сертификаты
# cat /etc/ssl/domain.com.certificate /etc/ssl/intermediate.certificate
>> /etc/exim4/exim.crt
рестартанул Exim, но ошибка та же:
TLS error ... (gnutls_handshake): An unexpected TLS packet was received.
может существует какой-то особый параметр для этого "intermediate"
сертификата?
--
BW,
Сохин Вячеслав
при использовании не-самоподписанного, а коммерческого сертификата
присутствуют 3 файла:
domain.com.certificate.key
domain.com.certificate
и intermediate.certificate
для Dovecot указал в /etc/dovecot/conf.d/10-ssl.conf:
ssl_cert_file = /etc/dovecot/domain.com.crt
ssl_key_file = /etc/dovecot/domain.com.key
ssl_ca_file = /etc/dovecot/intermediate.crt
а для Exim не нахожу в документации параметра относительно
intermediate.certificat...
сейчас в exim4.conf:
tls_on_connect_ports = 465
tls_advertise_hosts = *
tls_certificate = /etc/exim4/exim.crt
tls_privatekey = /etc/exim4/exim.key
при подключении по telnet к 465 порту в логе Exim ошибка:
TLS error ... (gnutls_handshake): An unexpected TLS packet was received.
пробовал объединить сертификаты
# cat /etc/ssl/domain.com.certificate /etc/ssl/intermediate.certificate
>> /etc/exim4/exim.crt
рестартанул Exim, но ошибка та же:
TLS error ... (gnutls_handshake): An unexpected TLS packet was received.
может существует какой-то особый параметр для этого "intermediate"
сертификата?
--
BW,
Сохин Вячеслав
Магунов Владимир
Feb 3, 2016, 9:50:03 AM2/3/16
to
По-видимости нужен параметр tls_verify_certificates.
Владимир.
Владимир.
Artem Chuprina
Feb 3, 2016, 10:20:03 AM2/3/16
to
Sohin Vyacheslav -> debian-...@lists.debian.org @ Wed, 3 Feb 2016 15:54:02 +0200:
SV> День добрый,
SV> при использовании не-самоподписанного, а коммерческого сертификата
SV> присутствуют 3 файла:
SV> domain.com.certificate.key
SV> domain.com.certificate
SV> и intermediate.certificate
SV> для Dovecot указал в /etc/dovecot/conf.d/10-ssl.conf:
SV> ssl_cert_file = /etc/dovecot/domain.com.crt
SV> ssl_key_file = /etc/dovecot/domain.com.key
SV> ssl_ca_file = /etc/dovecot/intermediate.crt
SV> а для Exim не нахожу в документации параметра относительно
SV> intermediate.certificat...
SV> сейчас в exim4.conf:
SV> tls_on_connect_ports = 465
SV> tls_advertise_hosts = *
SV> tls_certificate = /etc/exim4/exim.crt
SV> tls_privatekey = /etc/exim4/exim.key
SV> при подключении по telnet к 465 порту в логе Exim ошибка:
SV> TLS error ... (gnutls_handshake): An unexpected TLS packet was received.
Начать с того, что если это реально telnet, а не специальный telnet с
функцией TLS, то такая ошибка и должна быть. На 465 порту ожидается
TLS-хендшейк, а вовсе не протокол telnet или SMTP.
Собственно, по идее, если проблема с сертификатами сервера, то ругаться
должен клиент. Если клиент не ругается, а ругается сервер, то проблема,
скорее всего, не в сертификатах.
SV> пробовал объединить сертификаты
SV> # cat /etc/ssl/domain.com.certificate /etc/ssl/intermediate.certificate
>>> /etc/exim4/exim.crt
А они при этом в формате PEM (Base64) или DER (бинарный)? Впрочем,
такое сливание понимает openssl, за gnutls уверенности нет.
И еще: а корневой сертификат, которым подписан intermediate, на клиенте
точно есть и установлен как доверенный?
SV> День добрый,
SV> при использовании не-самоподписанного, а коммерческого сертификата
SV> присутствуют 3 файла:
SV> domain.com.certificate.key
SV> domain.com.certificate
SV> и intermediate.certificate
SV> для Dovecot указал в /etc/dovecot/conf.d/10-ssl.conf:
SV> ssl_cert_file = /etc/dovecot/domain.com.crt
SV> ssl_key_file = /etc/dovecot/domain.com.key
SV> ssl_ca_file = /etc/dovecot/intermediate.crt
SV> а для Exim не нахожу в документации параметра относительно
SV> intermediate.certificat...
SV> сейчас в exim4.conf:
SV> tls_on_connect_ports = 465
SV> tls_advertise_hosts = *
SV> tls_certificate = /etc/exim4/exim.crt
SV> tls_privatekey = /etc/exim4/exim.key
SV> при подключении по telnet к 465 порту в логе Exim ошибка:
SV> TLS error ... (gnutls_handshake): An unexpected TLS packet was received.
Начать с того, что если это реально telnet, а не специальный telnet с
функцией TLS, то такая ошибка и должна быть. На 465 порту ожидается
TLS-хендшейк, а вовсе не протокол telnet или SMTP.
Собственно, по идее, если проблема с сертификатами сервера, то ругаться
должен клиент. Если клиент не ругается, а ругается сервер, то проблема,
скорее всего, не в сертификатах.
SV> пробовал объединить сертификаты
SV> # cat /etc/ssl/domain.com.certificate /etc/ssl/intermediate.certificate
>>> /etc/exim4/exim.crt
А они при этом в формате PEM (Base64) или DER (бинарный)? Впрочем,
такое сливание понимает openssl, за gnutls уверенности нет.
И еще: а корневой сертификат, которым подписан intermediate, на клиенте
точно есть и установлен как доверенный?
Eugene Berdnikov
Feb 3, 2016, 11:40:05 AM2/3/16
to
On Wed, Feb 03, 2016 at 06:14:19PM +0300, Artem Chuprina wrote:
> Sohin Vyacheslav -> debian-...@lists.debian.org @ Wed, 3 Feb 2016 15:54:02 +0200:
> Sohin Vyacheslav -> debian-...@lists.debian.org @ Wed, 3 Feb 2016 15:54:02 +0200:
> SV> пробовал объединить сертификаты
> SV> # cat /etc/ssl/domain.com.certificate /etc/ssl/intermediate.certificate
> >>> /etc/exim4/exim.crt
>
> А они при этом в формате PEM (Base64) или DER (бинарный)? Впрочем,
> такое сливание понимает openssl, за gnutls уверенности нет.
Конечно же gnutls такое слияние понимает. Вообще, серверу должно быть
> SV> # cat /etc/ssl/domain.com.certificate /etc/ssl/intermediate.certificate
> >>> /etc/exim4/exim.crt
>
> А они при этом в формате PEM (Base64) или DER (бинарный)? Впрочем,
> такое сливание понимает openssl, за gnutls уверенности нет.
без разницы, что внутри этого файла: он его содержимое сливает клиенту,
а клиент уже парсит и раскладывает на цепочки сертификатов.
Но я знаю такую засаду: любимый Ру-Центром Comodo выдаёт сертификаты,
которые с виду PEM, только последняя строчка не терминируется "\n".
Поэтому склеивать их катом нельзя, хотя каждый сертификат по отдельности
openssl считает валидным. :)
--
Eugene Berdnikov
Victor Wagner
Feb 3, 2016, 12:00:04 PM2/3/16
to
On Wed, 3 Feb 2016 19:36:48 +0300
Eugene Berdnikov <b...@protva.ru> wrote:
> On Wed, Feb 03, 2016 at 06:14:19PM +0300, Artem Chuprina wrote:
> Конечно же gnutls такое слияние понимает. Вообще, серверу должно быть
> без разницы, что внутри этого файла: он его содержимое сливает
> клиенту, а клиент уже парсит и раскладывает на цепочки сертификатов.
Это не так. Сервер должен перепаковать эти сертификаты в сообщения
Eugene Berdnikov <b...@protva.ru> wrote:
> On Wed, Feb 03, 2016 at 06:14:19PM +0300, Artem Chuprina wrote:
> Конечно же gnutls такое слияние понимает. Вообще, серверу должно быть
> без разницы, что внутри этого файла: он его содержимое сливает
> клиенту, а клиент уже парсит и раскладывает на цепочки сертификатов.
проткола TLS, который весь из себя бинарный, и сертификаты в нем,
естественно, ходят в формате DER.
Если клиент показывает на экране сертификат в формате PEM, то это
значит уже клиент выполнил base64-кодирование полученного от сервера
сертификата, и дописал -----BEGIN CERTIFICATE----- и
-----END CERTIFICATE----
Tim Sattarov
Feb 3, 2016, 12:10:03 PM2/3/16
to
On 03/02/16 08:54 AM, Sohin Vyacheslav wrote:
> День добрый,
>
> при использовании не-самоподписанного, а коммерческого сертификата
> присутствуют 3 файла:
> domain.com.certificate.key
> domain.com.certificate
> и intermediate.certificate
>
> для Dovecot указал в /etc/dovecot/conf.d/10-ssl.conf:
> ssl_cert_file = /etc/dovecot/domain.com.crt
> ssl_key_file = /etc/dovecot/domain.com.key
> ssl_ca_file = /etc/dovecot/intermediate.crt
>
> а для Exim не нахожу в документации параметра относительно
> intermediate.certificat...
>
Попробуй объединить оба сертификата в один файл, один после другого
> День добрый,
>
> при использовании не-самоподписанного, а коммерческого сертификата
> присутствуют 3 файла:
> domain.com.certificate.key
> domain.com.certificate
> и intermediate.certificate
>
> для Dovecot указал в /etc/dovecot/conf.d/10-ssl.conf:
> ssl_cert_file = /etc/dovecot/domain.com.crt
> ssl_key_file = /etc/dovecot/domain.com.key
> ssl_ca_file = /etc/dovecot/intermediate.crt
>
> а для Exim не нахожу в документации параметра относительно
> intermediate.certificat...
>
(сначала intermediate, потом конечный)
(а, вижу что уже пробовал, это единственный способ указания всей цепочки)
> при подключении по telnet к 465 порту в логе Exim ошибка:
> TLS error ... (gnutls_handshake): An unexpected TLS packet was received.
тестировать SSL/TLS соединения телнетом сложно :)
> TLS error ... (gnutls_handshake): An unexpected TLS packet was received.
попробуй
openssl s_client -connect server:port
Тимур
Sohin Vyacheslav
Feb 3, 2016, 12:50:02 PM2/3/16
to
03.02.2016 18:59, Tim Sattarov пишет:
> тестировать SSL/TLS соединения телнетом сложно :)
> попробуй
> openssl s_client -connect server:port
$ openssl s_client -connect server:465
> попробуй
> openssl s_client -connect server:port
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 295 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
--
BW,
Сохин Вячеслав
sergio
Feb 3, 2016, 12:50:04 PM2/3/16
to
On 03/02/16 19:59, Tim Sattarov wrote:
>> TLS error ... (gnutls_handshake): An unexpected TLS packet was received.
> тестировать SSL/TLS соединения телнетом сложно :)
> попробуй
> openssl s_client -connect server:port
Для этого есть swaks.
>> TLS error ... (gnutls_handshake): An unexpected TLS packet was received.
> тестировать SSL/TLS соединения телнетом сложно :)
> попробуй
> openssl s_client -connect server:port
--
sergio
Sohin Vyacheslav
Feb 3, 2016, 1:00:03 PM2/3/16
to
03.02.2016 19:39, sergio пишет:
> Для этого есть swaks.
$ swaks -a -tls -q AUTH -s domain:465 -au username
Password:
=== Trying domain:465...
=== Connected to domain.com.
<** Timeout (30 secs) waiting for server respon
-> QUIT
*** Remote host closed connection unexpectedly.
в логе Exim - та же TLS ошибка:
(gnutls_handshake): An unexpected TLS packet was received.
--
BW,
Сохин Вячеслав
Sohin Vyacheslav
Feb 3, 2016, 1:00:03 PM2/3/16
to
03.02.2016 17:14, Artem Chuprina пишет:
> Начать с того, что если это реально telnet, а не специальный telnet с
> функцией TLS, то такая ошибка и должна быть. На 465 порту ожидается
> TLS-хендшейк, а вовсе не протокол telnet или SMTP.
>
нужен пакет telnet-ssl?
> функцией TLS, то такая ошибка и должна быть. На 465 порту ожидается
> TLS-хендшейк, а вовсе не протокол telnet или SMTP.
>
> Собственно, по идее, если проблема с сертификатами сервера, то ругаться
> должен клиент. Если клиент не ругается, а ругается сервер, то проблема,
> скорее всего, не в сертификатах.
>
> SV> пробовал объединить сертификаты
> SV> # cat /etc/ssl/domain.com.certificate /etc/ssl/intermediate.certificate
> >>> /etc/exim4/exim.crt
>
> А они при этом в формате PEM (Base64) или DER (бинарный)? Впрочем,
> такое сливание понимает openssl, за gnutls уверенности нет.
>
> И еще: а корневой сертификат, которым подписан intermediate, на клиенте
> точно есть и установлен как доверенный?
>
имеется в виду на почтовом клиенте?
> точно есть и установлен как доверенный?
>
--
BW,
Сохин Вячеслав
Artem Chuprina
Feb 4, 2016, 1:10:04 AM2/4/16
to
Sohin Vyacheslav -> debian-...@lists.debian.org @ Wed, 3 Feb 2016 19:51:36 +0200:
>> Для этого есть swaks.
SV> $ swaks -a -tls -q AUTH -s domain:465 -au username
-tlsc, а не -tls.
SV> Password:
SV> === Trying domain:465...
SV> === Connected to domain.com.
SV> <** Timeout (30 secs) waiting for server respon
SV> -> QUIT
SV> *** Remote host closed connection unexpectedly.
SV> в логе Exim - та же TLS ошибка:
SV> (gnutls_handshake): An unexpected TLS packet was received.
>> Для этого есть swaks.
SV> $ swaks -a -tls -q AUTH -s domain:465 -au username
-tlsc, а не -tls.
SV> Password:
SV> === Trying domain:465...
SV> === Connected to domain.com.
SV> <** Timeout (30 secs) waiting for server respon
SV> -> QUIT
SV> *** Remote host closed connection unexpectedly.
SV> в логе Exim - та же TLS ошибка:
SV> (gnutls_handshake): An unexpected TLS packet was received.
Artem Chuprina
Feb 4, 2016, 1:20:03 AM2/4/16
to
Sohin Vyacheslav -> debian-...@lists.debian.org @ Wed, 3 Feb 2016 19:54:48 +0200:
>> Начать с того, что если это реально telnet, а не специальный telnet с
>> функцией TLS, то такая ошибка и должна быть. На 465 порту ожидается
>> TLS-хендшейк, а вовсе не протокол telnet или SMTP.
SV> нужен пакет telnet-ssl?
Для отладки лучше взять openssl s_client, он как раз отладочный механизм.
А так хоть браузером можно. HTTP, конечно, не получится, но TLS-то пройдет.
>> Собственно, по идее, если проблема с сертификатами сервера, то ругаться
>> должен клиент. Если клиент не ругается, а ругается сервер, то проблема,
>> скорее всего, не в сертификатах.
>>
>> SV> пробовал объединить сертификаты
>> SV> # cat /etc/ssl/domain.com.certificate /etc/ssl/intermediate.certificate
>> >>> /etc/exim4/exim.crt
>>
>> А они при этом в формате PEM (Base64) или DER (бинарный)? Впрочем,
>> такое сливание понимает openssl, за gnutls уверенности нет.
>>
SV> PEM
На клиенте, которым ты тестируешь TLS. Если ты тестируешь telnet-ssl,
то про него должен знать openssl или сам telnet-ssl. Если openssl
c_client - то openssl (он, впрочем, с недоверенным и сам соединится,
просто пожалуется на недоверенность). Если gnutls-cli - то gnutls. Ну
и разумеется, потом, когда ты будешь пытаться отдать туда почту почтовым
клиентом, на почтовом клиенте или на общесистемном уровне для той
библиотеки, которой пользуется этот клиент.
>> Начать с того, что если это реально telnet, а не специальный telnet с
>> функцией TLS, то такая ошибка и должна быть. На 465 порту ожидается
>> TLS-хендшейк, а вовсе не протокол telnet или SMTP.
Для отладки лучше взять openssl s_client, он как раз отладочный механизм.
А так хоть браузером можно. HTTP, конечно, не получится, но TLS-то пройдет.
>> Собственно, по идее, если проблема с сертификатами сервера, то ругаться
>> должен клиент. Если клиент не ругается, а ругается сервер, то проблема,
>> скорее всего, не в сертификатах.
>>
>> SV> пробовал объединить сертификаты
>> SV> # cat /etc/ssl/domain.com.certificate /etc/ssl/intermediate.certificate
>> >>> /etc/exim4/exim.crt
>>
>> А они при этом в формате PEM (Base64) или DER (бинарный)? Впрочем,
>> такое сливание понимает openssl, за gnutls уверенности нет.
>>
>> И еще: а корневой сертификат, которым подписан intermediate, на клиенте
>> точно есть и установлен как доверенный?
>>
SV> имеется в виду на почтовом клиенте?
>> точно есть и установлен как доверенный?
>>
На клиенте, которым ты тестируешь TLS. Если ты тестируешь telnet-ssl,
то про него должен знать openssl или сам telnet-ssl. Если openssl
c_client - то openssl (он, впрочем, с недоверенным и сам соединится,
просто пожалуется на недоверенность). Если gnutls-cli - то gnutls. Ну
и разумеется, потом, когда ты будешь пытаться отдать туда почту почтовым
клиентом, на почтовом клиенте или на общесистемном уровне для той
библиотеки, которой пользуется этот клиент.
Artem Chuprina
Feb 4, 2016, 1:40:02 AM2/4/16
to
Sohin Vyacheslav -> debian-...@lists.debian.org @ Wed, 3 Feb 2016 19:43:24 +0200:
>> тестировать SSL/TLS соединения телнетом сложно :)
>> попробуй
>> openssl s_client -connect server:port
SV> $ openssl s_client -connect server:465
SV> CONNECTED(00000003)
SV> write:errno=104
SV> ---
SV> no peer certificate available
SV> ---
SV> No client certificate CA names sent
SV> ---
SV> SSL handshake has read 0 bytes and written 295 bytes
SV> ---
SV> New, (NONE), Cipher is (NONE)
SV> Secure Renegotiation IS NOT supported
SV> Compression: NONE
SV> Expansion: NONE
SV> ---
Есть мнение, что сервер вообще как-то криво сконфигурирован. Потому что
в случае, когда все сконфигурировано нормально, но не удается проверить
цепочку, openssl s_client успешно соединяется, но рассказывает, что не
поверил в сертификат:
zsh% openssl s_client -connect nest:465
CONNECTED(00000003)
depth=0 O = lasgalen.net, CN = nest.lasgalen.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 O = lasgalen.net, CN = nest.lasgalen.net
verify error:num=27:certificate not trusted
verify return:1
depth=0 O = lasgalen.net, CN = nest.lasgalen.net
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/O=lasgalen.net/CN=nest.lasgalen.net
i:/O=lasgalen.net/OU=CA/CN=lasgalen.net CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID+jCCAuKgAwIBAgIBFzANBgkqhkiG9w0BAQUFADA+MRUwEwYDVQQKDAxsYXNn
YWxlbi5uZXQxCzAJBgNVBAsMAkNBMRgwFgYDVQQDDA9sYXNnYWxlbi5uZXQgQ0Ew
HhcNMTQwMzIxMDkwOTE0WhcNMjYwMzIyMDkwOTE0WjAzMRUwEwYDVQQKDAxsYXNn
YWxlbi5uZXQxGjAYBgNVBAMMEW5lc3QubGFzZ2FsZW4ubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0o/A8hQHLsHiCQlOViJfurP314DK5BDE+ks/
5P5LtDKUv89P/Dcm7a5fq0acgb5Ybt8H2xoSw9q3L2SKTZvLPIfA9e+maORaqjaG
xe0QauUfSRWLXvDJcbruOEGT3b8wAR2qOXBNpBADYwFemrOTWT1SpnONg7qsnSkV
Eouq/ftd7tr7WeYb0JzoZVbob5qZa6bQ4Vdq0ixKEsoX5FkRlXfI+QM8VoJpDwYl
K47EPdvjN8S4BPZzqHS6zb1v0zHI8gSod9wp/8QJsLzg/a5Z/5r9igOo3uhLfisD
5y4JXvf0sSPi23/EULOFK6R1p0poLozaTt//hoZ/5lJkNlAOBwIDAQABo4IBDDCC
AQgwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBkAwHQYDVR0OBBYEFMU2CJbq
yIgkTodU9FZIcj0QMxYeMG4GA1UdIwRnMGWAFEf2+K42gXJEQbeCMWKLNkuJecPm
oUKkQDA+MRUwEwYDVQQKDAxsYXNnYWxlbi5uZXQxCzAJBgNVBAsMAkNBMRgwFgYD
VQQDDA9sYXNnYWxlbi5uZXQgQ0GCCQDG9M5kShSwUzATBgNVHSUEDDAKBggrBgEF
BQcDATBEBgNVHREEPTA7ghFuZXN0Lmxhc2dhbGVuLm5ldIITamFiYmVyLmxhc2dh
bGVuLm5ldIIRbWFpbC5sYXNnYWxlbi5uZXQwDQYJKoZIhvcNAQEFBQADggEBAC1d
PCquISWG8RYK1R4xYWPeJgIt1Exii1V64EUxGpsv/m/IAvdJ3JtiaWQ+QIn8sYn2
0cQX+cf9rP9auTPK5rM2QY38uOKQHeTyEipx/aAQNlYvqh03QnmVJiRcpMzUocxN
Xo7LcT8MS3SHNGoPOyn1LTMmBGfxId2/xgbQqoA6xlM1759adMq4lm33bAbRlMHp
w8/k1km5n+p0GYRIs/Y8GlDszF7+DGQjswl5wJsTnhI519GWwZu8CBmvN8TqRovH
iDWdE59RYTREoPcAp/dymGYvWuhV8YkoeYAZ259zjEugdNhPnob6fJ1OrVGlHEp3
gAKBKAVxjZLdlacIURY=
-----END CERTIFICATE-----
subject=/O=lasgalen.net/CN=nest.lasgalen.net
issuer=/O=lasgalen.net/OU=CA/CN=lasgalen.net CA
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : DHE-RSA-AES256-SHA256
Session-ID: 7B70E3ED421D2C29F9C9FC4EC1CB6C048925798D40DC57C3D5C8A5626B779BB5
Session-ID-ctx:
Master-Key: 399C5ADC57DDEA1825CD4A40A19A7C3B17B4A29FE706DF874C3533BA31452D484492614B724DBF9DC137D6C769101336
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1454566892
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
220 nest.lasgalen.net ESMTP Exim 4.80 Thu, 04 Feb 2016 06:21:33 +0000
А в твоем случае он оттуда ни байта не прочел. Он попытался сразу туда
что-то записать (что-то - это, вероятно, ClientHello), и получил write
error. Причем именно write error, а не непротокольное сообщение, как
было бы в случае, если бы на 465 порту просто не ждали TLS.
>> тестировать SSL/TLS соединения телнетом сложно :)
>> попробуй
>> openssl s_client -connect server:port
SV> CONNECTED(00000003)
SV> write:errno=104
SV> ---
SV> no peer certificate available
SV> ---
SV> No client certificate CA names sent
SV> ---
SV> SSL handshake has read 0 bytes and written 295 bytes
SV> ---
SV> New, (NONE), Cipher is (NONE)
SV> Secure Renegotiation IS NOT supported
SV> Compression: NONE
SV> Expansion: NONE
SV> ---
Есть мнение, что сервер вообще как-то криво сконфигурирован. Потому что
в случае, когда все сконфигурировано нормально, но не удается проверить
цепочку, openssl s_client успешно соединяется, но рассказывает, что не
поверил в сертификат:
zsh% openssl s_client -connect nest:465
CONNECTED(00000003)
depth=0 O = lasgalen.net, CN = nest.lasgalen.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 O = lasgalen.net, CN = nest.lasgalen.net
verify error:num=27:certificate not trusted
verify return:1
depth=0 O = lasgalen.net, CN = nest.lasgalen.net
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/O=lasgalen.net/CN=nest.lasgalen.net
i:/O=lasgalen.net/OU=CA/CN=lasgalen.net CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIID+jCCAuKgAwIBAgIBFzANBgkqhkiG9w0BAQUFADA+MRUwEwYDVQQKDAxsYXNn
YWxlbi5uZXQxCzAJBgNVBAsMAkNBMRgwFgYDVQQDDA9sYXNnYWxlbi5uZXQgQ0Ew
HhcNMTQwMzIxMDkwOTE0WhcNMjYwMzIyMDkwOTE0WjAzMRUwEwYDVQQKDAxsYXNn
YWxlbi5uZXQxGjAYBgNVBAMMEW5lc3QubGFzZ2FsZW4ubmV0MIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0o/A8hQHLsHiCQlOViJfurP314DK5BDE+ks/
5P5LtDKUv89P/Dcm7a5fq0acgb5Ybt8H2xoSw9q3L2SKTZvLPIfA9e+maORaqjaG
xe0QauUfSRWLXvDJcbruOEGT3b8wAR2qOXBNpBADYwFemrOTWT1SpnONg7qsnSkV
Eouq/ftd7tr7WeYb0JzoZVbob5qZa6bQ4Vdq0ixKEsoX5FkRlXfI+QM8VoJpDwYl
K47EPdvjN8S4BPZzqHS6zb1v0zHI8gSod9wp/8QJsLzg/a5Z/5r9igOo3uhLfisD
5y4JXvf0sSPi23/EULOFK6R1p0poLozaTt//hoZ/5lJkNlAOBwIDAQABo4IBDDCC
AQgwCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBkAwHQYDVR0OBBYEFMU2CJbq
yIgkTodU9FZIcj0QMxYeMG4GA1UdIwRnMGWAFEf2+K42gXJEQbeCMWKLNkuJecPm
oUKkQDA+MRUwEwYDVQQKDAxsYXNnYWxlbi5uZXQxCzAJBgNVBAsMAkNBMRgwFgYD
VQQDDA9sYXNnYWxlbi5uZXQgQ0GCCQDG9M5kShSwUzATBgNVHSUEDDAKBggrBgEF
BQcDATBEBgNVHREEPTA7ghFuZXN0Lmxhc2dhbGVuLm5ldIITamFiYmVyLmxhc2dh
bGVuLm5ldIIRbWFpbC5sYXNnYWxlbi5uZXQwDQYJKoZIhvcNAQEFBQADggEBAC1d
PCquISWG8RYK1R4xYWPeJgIt1Exii1V64EUxGpsv/m/IAvdJ3JtiaWQ+QIn8sYn2
0cQX+cf9rP9auTPK5rM2QY38uOKQHeTyEipx/aAQNlYvqh03QnmVJiRcpMzUocxN
Xo7LcT8MS3SHNGoPOyn1LTMmBGfxId2/xgbQqoA6xlM1759adMq4lm33bAbRlMHp
w8/k1km5n+p0GYRIs/Y8GlDszF7+DGQjswl5wJsTnhI519GWwZu8CBmvN8TqRovH
iDWdE59RYTREoPcAp/dymGYvWuhV8YkoeYAZ259zjEugdNhPnob6fJ1OrVGlHEp3
gAKBKAVxjZLdlacIURY=
-----END CERTIFICATE-----
subject=/O=lasgalen.net/CN=nest.lasgalen.net
issuer=/O=lasgalen.net/OU=CA/CN=lasgalen.net CA
---
No client certificate CA names sent
---
SSL handshake has read 2346 bytes and written 653 bytes
No client certificate CA names sent
---
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : DHE-RSA-AES256-SHA256
Session-ID: 7B70E3ED421D2C29F9C9FC4EC1CB6C048925798D40DC57C3D5C8A5626B779BB5
Session-ID-ctx:
Master-Key: 399C5ADC57DDEA1825CD4A40A19A7C3B17B4A29FE706DF874C3533BA31452D484492614B724DBF9DC137D6C769101336
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1454566892
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
220 nest.lasgalen.net ESMTP Exim 4.80 Thu, 04 Feb 2016 06:21:33 +0000
А в твоем случае он оттуда ни байта не прочел. Он попытался сразу туда
что-то записать (что-то - это, вероятно, ClientHello), и получил write
error. Причем именно write error, а не непротокольное сообщение, как
было бы в случае, если бы на 465 порту просто не ждали TLS.
Sohin Vyacheslav
Feb 4, 2016, 4:30:03 AM2/4/16
to
04.02.2016 08:30, Artem Chuprina пишет:
> Sohin Vyacheslav -> debian-...@lists.debian.org @ Wed, 3 Feb 2016 19:43:24 +0200:
> SV> $ openssl s_client -connect server:465
после того, как добавил в exim4.conf параметр tls_verify_certificates =
/etc/exim4/exim.crt и пересоздал сам файл сертификата:
-----BEGIN PRIVATE KEY-----
...........................
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
...........................
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...........................
-----END CERTIFICATE-----
где последний-intermediate сертификат, всё заработало!
и через
$ openssl s_client -connect server:465
и через
% gnutls-cli -p 465 server
и через
$ swaks -a -tlsc -q AUTH -s server:465 -au username
ВСЕМ огромное спасибо! особенно Артёму Чуприне и Магунову Владимиру!
--
BW,
Сохин Вячеслав
Artem Chuprina
Feb 4, 2016, 5:40:03 AM2/4/16
to
Sohin Vyacheslav -> debian-...@lists.debian.org @ Thu, 4 Feb 2016 11:28:38 +0200:
>> SV> $ openssl s_client -connect server:465
SV> после того, как добавил в exim4.conf параметр tls_verify_certificates =
SV> /etc/exim4/exim.crt
Эээ, точно? tls_verify_certificates, судя по описанию, относится к
требованию сертификата от клиента, причем очень сурово относится - если
клиент не предоставляет клиенского сертификата, ему говорят "до
свидания". К собственному сертификату exim не имеет отношения.
А отношение к делу имеют tls_certificate и tls_privatekey. И в
tls_certificate не надо класть private key. У них, собственно, и
права-то обычно разные. Сертификат - публичная информация, а секретный
ключ - отнюдь. А вот оба сертификата - и свой, и промежуточный - как
раз надо, именно в этом порядке.
SV> и пересоздал сам файл сертификата:
SV> -----BEGIN PRIVATE KEY-----
SV> ...........................
SV> -----END PRIVATE KEY-----
SV> -----BEGIN CERTIFICATE-----
SV> ...........................
SV> -----END CERTIFICATE-----
SV> -----BEGIN CERTIFICATE-----
SV> ...........................
SV> -----END CERTIFICATE-----
SV> где последний-intermediate сертификат, всё заработало!
SV> и через
SV> % gnutls-cli -p 465 server
SV> и через
SV> $ swaks -a -tlsc -q AUTH -s server:465 -au username
SV> ВСЕМ огромное спасибо! особенно Артёму Чуприне и Магунову Владимиру!
>> SV> $ openssl s_client -connect server:465
SV> /etc/exim4/exim.crt
Эээ, точно? tls_verify_certificates, судя по описанию, относится к
требованию сертификата от клиента, причем очень сурово относится - если
клиент не предоставляет клиенского сертификата, ему говорят "до
свидания". К собственному сертификату exim не имеет отношения.
А отношение к делу имеют tls_certificate и tls_privatekey. И в
tls_certificate не надо класть private key. У них, собственно, и
права-то обычно разные. Сертификат - публичная информация, а секретный
ключ - отнюдь. А вот оба сертификата - и свой, и промежуточный - как
раз надо, именно в этом порядке.
SV> и пересоздал сам файл сертификата:
SV> -----BEGIN PRIVATE KEY-----
SV> ...........................
SV> -----END PRIVATE KEY-----
SV> -----BEGIN CERTIFICATE-----
SV> ...........................
SV> -----END CERTIFICATE-----
SV> -----BEGIN CERTIFICATE-----
SV> ...........................
SV> -----END CERTIFICATE-----
SV> где последний-intermediate сертификат, всё заработало!
SV> и через
SV> $ openssl s_client -connect server:465
SV> и через
SV> % gnutls-cli -p 465 server
SV> и через
SV> $ swaks -a -tlsc -q AUTH -s server:465 -au username
SV> ВСЕМ огромное спасибо! особенно Артёму Чуприне и Магунову Владимиру!
Sohin Vyacheslav
Feb 4, 2016, 6:20:02 AM2/4/16
to
04.02.2016 12:37, Artem Chuprina пишет:
> А отношение к делу имеют tls_certificate и tls_privatekey. И в
> tls_certificate не надо класть private key. У них, собственно, и
> права-то обычно разные. Сертификат - публичная информация, а секретный
> ключ - отнюдь. А вот оба сертификата - и свой, и промежуточный - как
> раз надо, именно в этом порядке.
упс! поторопился, попробую исправить... отпишусь...
> tls_certificate не надо класть private key. У них, собственно, и
> права-то обычно разные. Сертификат - публичная информация, а секретный
> ключ - отнюдь. А вот оба сертификата - и свой, и промежуточный - как
> раз надо, именно в этом порядке.
Спс!
--
BW,
Сохин Вячеслав
Artem Chuprina
Feb 4, 2016, 12:10:04 PM2/4/16
to
Sohin Vyacheslav -> debian-...@lists.debian.org @ Thu, 4 Feb 2016 13:06:55 +0200:
>> А отношение к делу имеют tls_certificate и tls_privatekey. И в
>> tls_certificate не надо класть private key. У них, собственно, и
>> права-то обычно разные. Сертификат - публичная информация, а секретный
>> ключ - отнюдь. А вот оба сертификата - и свой, и промежуточный - как
>> раз надо, именно в этом порядке.
SV> упс! поторопился, попробую исправить... отпишусь...
SV> Спс!
Собственно, у меня часть, отвечающая за tls, выглядит так:
tls_advertise_hosts = *
tls_certificate = /etc/ssl/certs/lasgalen.nest.crt
tls_privatekey = /etc/exim4/lasgalen.nest.key
tls_on_connect_ports = 465
Права на эти файлы
-r-------- 1 Debian-exim root 1679 Oct 31 2014 /etc/exim4/lasgalen.nest.key
-rw-r--r-- 1 root root 4824 Mar 23 2014 /etc/ssl/certs/lasgalen.nest.crt
Плюс еще момент в аутентификации:
begin authenticators
dovecot_login:
driver = dovecot
public_name = LOGIN
server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
server_socket = /var/run/dovecot/auth-client
server_set_id = $auth1
dovecot_plain:
driver = dovecot
public_name = PLAIN
server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
server_socket = /var/run/dovecot/auth-client
server_set_id = $auth1
Типа, если у нас нету TLS, даже не пытаться предлагать аутентификацию.
В моем случае я пользуюсь собственным 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, которыми подписаны
клиентские, что логично)
>> А отношение к делу имеют tls_certificate и tls_privatekey. И в
>> tls_certificate не надо класть private key. У них, собственно, и
>> права-то обычно разные. Сертификат - публичная информация, а секретный
>> ключ - отнюдь. А вот оба сертификата - и свой, и промежуточный - как
>> раз надо, именно в этом порядке.
SV> Спс!
Собственно, у меня часть, отвечающая за tls, выглядит так:
tls_advertise_hosts = *
tls_certificate = /etc/ssl/certs/lasgalen.nest.crt
tls_privatekey = /etc/exim4/lasgalen.nest.key
tls_on_connect_ports = 465
Права на эти файлы
-r-------- 1 Debian-exim root 1679 Oct 31 2014 /etc/exim4/lasgalen.nest.key
-rw-r--r-- 1 root root 4824 Mar 23 2014 /etc/ssl/certs/lasgalen.nest.crt
Плюс еще момент в аутентификации:
begin authenticators
dovecot_login:
driver = dovecot
public_name = LOGIN
server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
server_socket = /var/run/dovecot/auth-client
server_set_id = $auth1
dovecot_plain:
driver = dovecot
public_name = PLAIN
server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
server_socket = /var/run/dovecot/auth-client
server_set_id = $auth1
Типа, если у нас нету TLS, даже не пытаться предлагать аутентификацию.
В моем случае я пользуюсь собственным CA, и у меня нет промежуточного,
но разница должна быть исключительно в содержимом файла, на который
указывает tls_certificate.
А глядя на конфиг на ноутбуке (на ноуте, в отличие от сервера, он у меня
не ручной, а сконфигурированный через дебиановскую систему), я наблюдаю,
что дефолты будут такие:
tls_advertise_hosts = *
tls_certificate = /etc/exim4/exim.crt
tls_privatekey = /etc/exim4/exim.key
(требовать клиентских сертификатов он при этом не будет, поскольку
tls_verify_hosts и tls_try_verify_hosts не выставлены; но тут видно, что
tls_verify_certificates - это набор сертификатов CA, которыми подписаны
клиентские, что логично)
Sohin Vyacheslav
Feb 5, 2016, 6:00:03 AM2/5/16
to
04.02.2016 19:07, Artem Chuprina пишет:
> Sohin Vyacheslav -> debian-...@lists.debian.org @ Thu, 4 Feb 2016 13:06:55 +0200:
>
> >> А отношение к делу имеют tls_certificate и tls_privatekey. И в
> >> tls_certificate не надо класть private key. У них, собственно, и
> >> права-то обычно разные. Сертификат - публичная информация, а секретный
> >> ключ - отнюдь. А вот оба сертификата - и свой, и промежуточный - как
> >> раз надо, именно в этом порядке.
я убрал ключ из exim.crt и раскомментировал строку с exim.key в
>
> >> А отношение к делу имеют tls_certificate и tls_privatekey. И в
> >> tls_certificate не надо класть private key. У них, собственно, и
> >> права-то обычно разные. Сертификат - публичная информация, а секретный
> >> ключ - отнюдь. А вот оба сертификата - и свой, и промежуточный - как
> >> раз надо, именно в этом порядке.
exim4.conf => всё так-же работает, визуально в логе ничего не изменилось...
в http://www.rldp.ru/exim/exim480r/glava38.htm указано:
tls_certificate =/some/file/name
tls_privatekey =/some/file/name
Это может быть один и тот же файл, если в нём содержатся сертификат и ключ.
> Права на эти файлы
>
> -r-------- 1 Debian-exim root 1679 Oct 31 2014 /etc/exim4/lasgalen.nest.key
> -rw-r--r-- 1 root root 4824 Mar 23 2014 /etc/ssl/certs/lasgalen.nest.crt
>
> Плюс еще момент в аутентификации:
>
> begin authenticators
>
> dovecot_login:
> driver = dovecot
> public_name = LOGIN
> server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
> server_socket = /var/run/dovecot/auth-client
> server_set_id = $auth1
>
> dovecot_plain:
> driver = dovecot
> public_name = PLAIN
> server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
> server_socket = /var/run/dovecot/auth-client
> server_set_id = $auth1
>
> Типа, если у нас нету TLS, даже не пытаться предлагать аутентификацию.
>
спасибо, добавил строку условия server_advertise_condition = ${if
> Плюс еще момент в аутентификации:
>
> begin authenticators
>
> dovecot_login:
> driver = dovecot
> public_name = LOGIN
> server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
> server_socket = /var/run/dovecot/auth-client
> server_set_id = $auth1
>
> dovecot_plain:
> driver = dovecot
> public_name = PLAIN
> server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
> server_socket = /var/run/dovecot/auth-client
> server_set_id = $auth1
>
> Типа, если у нас нету TLS, даже не пытаться предлагать аутентификацию.
>
eq{$tls_cipher}{}{no}{yes}} в аутентификаторы
> В моем случае я пользуюсь собственным 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, которыми подписаны
> клиентские, что логично)
>
Если установлена опция tls_verify_certificates, она должна быть именем
файла или (только для OpenSSL, не для GnuTLS) каталогом, который как
ожидается содержит коллекцию серверных сертификатов.
имеется в виду не сертификат exim.crt, a ca-certificates.crt?
--
BW,
Сохин Вячеслав
Artem Chuprina
Feb 6, 2016, 5:20:03 PM2/6/16
to
Sohin Vyacheslav -> debian-...@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.
>> >> А отношение к делу имеют tls_certificate и tls_privatekey. И в
>> >> tls_certificate не надо класть private 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> Если установлена опция 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.
0 new messages