Re: параметр Exim, отвечающий за intermediate-сертификат

2016-02-06 Пенетрантность Artem Chuprina 
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.

Re: параметр Exim, отвечающий за intermediate-сертификат

2016-02-05 Пенетрантность Sohin Vyacheslav 


04.02.2016 19:07, Artem Chuprina пишет:
> Sohin Vyacheslav -> debian-russian@lists.debian.org  @ Thu, 4 Feb 2016 
> 13:06:55 +0200:
> 
>  >> А отношение к делу имеют tls_certificate и tls_privatekey.  И в
>  >> tls_certificate не надо класть private key.  У них, собственно, и
>  >> права-то обычно разные.  Сертификат - публичная информация, а секретный
>  >> ключ - отнюдь.  А вот оба сертификата - и свой, и промежуточный - как
>  >> раз надо, именно в этом порядке.

я убрал ключ из exim.crt и раскомментировал строку с exim.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 rootroot 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
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, которыми подписаны
> клиентские, что логично)
> 
в http://www.rldp.ru/exim/exim480r/glava38.htm также указано:
Если установлена опция tls_verify_certificates, она должна быть именем
файла или (только для OpenSSL, не для GnuTLS) каталогом, который как
ожидается содержит коллекцию серверных сертификатов.

имеется в виду не сертификат exim.crt, a ca-certificates.crt?


-- 
BW,
Сохин Вячеслав

Re: параметр Exim, отвечающий за intermediate-сертификат

2016-02-04 Пенетрантность Sohin Vyacheslav 


04.02.2016 12:37, Artem Chuprina пишет:
> А отношение к делу имеют tls_certificate и tls_privatekey.  И в
> tls_certificate не надо класть private key.  У них, собственно, и
> права-то обычно разные.  Сертификат - публичная информация, а секретный
> ключ - отнюдь.  А вот оба сертификата - и свой, и промежуточный - как
> раз надо, именно в этом порядке.

упс! поторопился, попробую исправить... отпишусь...
Спс!

-- 
BW,
Сохин Вячеслав

Re: параметр Exim, отвечающий за intermediate-сертификат

2016-02-04 Пенетрантность Artem Chuprina 
Sohin Vyacheslav -> debian-russian@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> $ 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> ВСЕМ огромное спасибо! особенно Артёму Чуприне и Магунову Владимиру!

Re: параметр Exim, отвечающий за intermediate-сертификат

2016-02-04 Пенетрантность Sohin Vyacheslav 


04.02.2016 08:30, Artem Chuprina пишет:
> Sohin Vyacheslav -> debian-russian@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,
Сохин Вячеслав

Re: параметр Exim, отвечающий за intermediate-сертификат

2016-02-04 Пенетрантность Artem Chuprina 
Sohin Vyacheslav -> debian-russian@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 rootroot 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, которыми подписаны
клиентские, что логично)

Re: параметр Exim, отвечающий за intermediate-сертификат

2016-02-03 Пенетрантность Artem Chuprina 
Sohin Vyacheslav -> debian-russian@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, на клиенте
точно есть и установлен как доверенный?

Re: параметр Exim, отвечающий за intermediate-сертификат

2016-02-03 Пенетрантность Tim Sattarov 
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...
>
Попробуй объединить оба сертификата в один файл, один после другого
(сначала intermediate, потом конечный)
(а, вижу что уже пробовал, это единственный способ указания всей цепочки)
> при подключении по telnet к 465 порту в логе Exim ошибка:
> TLS error ... (gnutls_handshake): An unexpected TLS packet was received.
тестировать  SSL/TLS соединения телнетом сложно :)
попробуй
openssl s_client -connect server:port

Тимур

Re: параметр Exim, отвечающий за intermediate-сертификат

2016-02-03 Пенетрантность Victor Wagner 
On Wed, 3 Feb 2016 19:36:48 +0300
Eugene Berdnikov  wrote:

> On Wed, Feb 03, 2016 at 06:14:19PM +0300, Artem Chuprina wrote:

>  Конечно же gnutls такое слияние понимает. Вообще, серверу должно быть
>  без разницы, что внутри этого файла: он его содержимое сливает
> клиенту, а клиент уже парсит и раскладывает на цепочки сертификатов.

Это не так. Сервер должен перепаковать эти сертификаты в сообщения
проткола TLS, который весь из себя бинарный, и сертификаты в нем,
естественно, ходят в формате DER.

Если клиент показывает на экране сертификат в формате PEM, то это
значит уже клиент выполнил base64-кодирование полученного от сервера
сертификата, и дописал -BEGIN CERTIFICATE- и 
-END CERTIFICATE

Re: параметр Exim, отвечающий за intermediate-сертификат

2016-02-03 Пенетрантность Eugene Berdnikov 
On Wed, Feb 03, 2016 at 06:14:19PM +0300, Artem Chuprina wrote:
> Sohin Vyacheslav -> debian-russian@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 такое слияние понимает. Вообще, серверу должно быть
 без разницы, что внутри этого файла: он его содержимое сливает клиенту,
 а клиент уже парсит и раскладывает на цепочки сертификатов.

 Но я знаю такую засаду: любимый Ру-Центром Comodo выдаёт сертификаты,
 которые с виду PEM, только последняя строчка не терминируется "\n".
 Поэтому склеивать их катом нельзя, хотя каждый сертификат по отдельности
 openssl считает валидным. :)
-- 
 Eugene Berdnikov

Re: параметр Exim, отвечающий за intermediate-сертификат

2016-02-03 Пенетрантность Artem Chuprina 
Sohin Vyacheslav -> debian-russian@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(0003)

 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(0003)
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
---
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 +


А в твоем случае он оттуда ни байта не прочел.  Он попытался сразу туда
что-то записать (что-то - это, вероятно, ClientHello), и получил write
error.  Причем именно write error, а не непротокольное сообщение, как
было бы в случае, если бы на 465 порту просто не ждали TLS.

Re: параметр Exim, отвечающий за intermediate-сертификат

2016-02-03 Пенетрантность Artem Chuprina 
Sohin Vyacheslav -> debian-russian@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
 >> И еще: а корневой сертификат, которым подписан intermediate, на клиенте
 >> точно есть и установлен как доверенный?
 >> 
 SV> имеется в виду на почтовом клиенте?

На клиенте, которым ты тестируешь TLS.  Если ты тестируешь telnet-ssl,
то про него должен знать openssl или сам telnet-ssl.  Если openssl
c_client - то openssl (он, впрочем, с недоверенным и сам соединится,
просто пожалуется на недоверенность).  Если gnutls-cli - то gnutls.  Ну
и разумеется, потом, когда ты будешь пытаться отдать туда почту почтовым
клиентом, на почтовом клиенте или на общесистемном уровне для той
библиотеки, которой пользуется этот клиент.

Re: параметр Exim, отвечающий за intermediate-сертификат

2016-02-03 Пенетрантность Sohin Vyacheslav 


03.02.2016 17:14, Artem Chuprina пишет:
> Начать с того, что если это реально telnet, а не специальный telnet с
> функцией TLS, то такая ошибка и должна быть.  На 465 порту ожидается
> TLS-хендшейк, а вовсе не протокол telnet или SMTP.
> 

нужен пакет telnet-ssl?

> Собственно, по идее, если проблема с сертификатами сервера, то ругаться
> должен клиент.  Если клиент не ругается, а ругается сервер, то проблема,
> скорее всего, не в сертификатах.
> 
>  SV> пробовал объединить сертификаты
>  SV> # cat /etc/ssl/domain.com.certificate /etc/ssl/intermediate.certificate
>  >>> /etc/exim4/exim.crt
> 
> А они при этом в формате PEM (Base64) или DER (бинарный)?  Впрочем,
> такое сливание понимает openssl, за gnutls уверенности нет.
> 

PEM
> И еще: а корневой сертификат, которым подписан intermediate, на клиенте
> точно есть и установлен как доверенный?
> 
имеется в виду на почтовом клиенте?

-- 
BW,
Сохин Вячеслав

RE: параметр Exim, отвечающий за intermediate-сертификат

2016-02-03 Пенетрантность Магунов Владимир 
По-видимости нужен параметр tls_verify_certificates.

Владимир.

-Original Message-
From: Sohin Vyacheslav [mailto:in.s...@yandex.ua] 
Sent: Wednesday, February 03, 2016 4:54 PM
To: debian-russian@lists.debian.org
Subject: параметр Exim, отвечающий за intermediate-сертификат

День добрый,

при использовании не-самоподписанного, а коммерческого сертификата присутствуют 
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,
Сохин Вячеслав

Re: параметр Exim, отвечающий за intermediate-сертификат

2016-02-03 Пенетрантность Sohin Vyacheslav 


03.02.2016 18:59, Tim Sattarov пишет:
> тестировать  SSL/TLS соединения телнетом сложно :)
> попробуй
> openssl s_client -connect server:port

$ openssl s_client -connect server:465
CONNECTED(0003)

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,
Сохин Вячеслав