Meu servidor exim está configurado para solicitar um certificado de cliente quando uma conexão é feita. Eu configurei uma ACL (no estágio rcpt) para registrar ou adicionar um cabeçalho resp. do resultado da verificação do certificado:
warn
encrypted = *
! verify = certificate
#condition = ${if def:tls_in_peerdn {yes}{no}} # -> newer versions of exim use $tls_in_peerdn!
condition = ${if def:tls_peerdn {yes}{no}}
add_header = X-TLS-Client-Certificate: invalid (${tls_peerdn})
log_message = Invalid TLS client certificate presented (${tls_peerdn}).
warn
encrypted = *
! verify = certificate
condition = ${if def:tls_peerdn {no}{yes}}
log_message = No TLS client certificate presented.
warn
verify = certificate
add_header = X-TLS-Client-Certificate: valid
condition = false
Infelizmente, nenhuma mensagem que vejo já foi verificada como válida. A verificação de nenhum certificado funciona.
eu configurei
tls_try_verify_hosts = *
Portanto, a verificação ocorre e (usando o Debian, ela é incluída na configuração padrão) as âncoras de confiança são configuradas e acessíveis:
tls_verify_certificates = /etc/ssl/certs/ca-certificates.crt
Testando com ...
openssl s_client -CAfile /etc/ssl/certs/ca-certificates.crt -verify 4 -connect mailserver.dom.tld:25 -starttls smtp -cert /etc/ssl/letsencrypt/fullchain.pem -key /etc/ssl/letsencrypt/privkey.pem
... do servidor para si mesmo usando a mesma chave que o servidor usa, inclusive os certificados intermediários na ordem correta não fornecem um resultado de verificação válido.
O que estou perdendo?
O valor para o parâmetro -CAfile deve ser seu Let's encrypt's chain.pem e o valor para -cert cert.pem:
openssl s_client -CAfile /etc/ssl/letsencrypt/chain.pem -verify 4 \
-connect mailserver.dom.tld:25 -starttls smtp \
-cert /etc/ssl/letsencrypt/cert.pem \
-key /etc/ssl/letsencrypt/privkey.pem
Por isso, seu certificado será validado pelo seu servidor.
Se o seu servidor estiver usando a configuração padrão, ele deverá estar usando o certificado auto-assinado snakeoil . Isso é adequado e aceitável para estabelecer conexões TLS nas conexões de entrada e saída. No entanto, falhará na validação. Você precisará usar um certificado de uma autoridade confiável para passar pela validação.
Você está fornecendo aos clientes certificados que eles podem usar no lugar de um login? Diferente de seus usuários fornecidos com certificados de usuário, eu esperaria que os certificados do cliente falhassem com frequência. Muitos servidores usam um certificado auto-assinado ou têm outros problemas que causam falhas de validação.
O Exim não solicitará um certificado de cliente, a menos que você defina tls_verify_hosts ou tls_try_verify_hosts . Os certificados são bem abordados na seção Conexões SMTP criptografadas do Documentação do Exim.
Muitas organizações têm dificuldade em configurar corretamente o DNS para uso de STMP. O DKIM é particularmente problemático e a maioria dos signatários que encontro falha na validação. Tenho pouca esperança de que muitos sites tenham configurado seus servidores com os certificados válidos corretos.
Após a recente restrição de conexões com o TLS v1.0 e superior, tive que parar de anunciar STARTTLS para vários servidores. Ainda não recorri a tentar validar certificados TLS para quaisquer clientes. Se eu fizer isso, no máximo, contará para sua pontuação de spam. Eu posso ativar o seletor de log tls_peerdn para investigar se algum site pode passar pela validação.
O SMTP sobre TLS está crescendo, mas longe do padrão. Os sites que o utilizam são sites que são confiáveis por outros meios.
UPDATE: verifiquei meus registros e, até o momento, apenas dois remetentes passaram pela validação. A maioria dos clientes não validou.
Eu tentei validar meu certificado:
openssl.client.net , o que não deve passar pela valiação do rDNS. O comando de teste que usei foi:
echo quit | openssl s_client -cert fullchain.pem -key privkey.pem \
-starttls smtp -connect mail.systemajik.com:587 -debug 2>&1 | less