Tengo un servidor doméstico y actualicé la unidad del sistema a un SSD como lo había estado en una combinación de USB y HDD para /home y /var. Debido a que el USB estaba en una versión anterior de Debian, realicé una instalación nueva, que también me actualizó a la versión 4.95 de EXIM, anteriormente estaba en 4.94.2.
A pesar de la misma configuración de smarthost, para usar el servidor SMTP de mi ISP, ya no usa TLS y da un error de validación.
/var/log/exim4/mainlog:
2022-04-12 03:30:25 1ne6I7-000AHw-MF TLS session: (certificate verification failed): delivering unencrypted to H=<DOMAIN> [<IP>] (not in hosts_require_tls)
El correo todavía se acepta sin cifrar, pero ahora mi ISP marca el correo de trabajos cron como spam. El único cambio es que los mensajes tienen un Receivedencabezado que pasó de ser with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2)a simplemente with esmtp (Exim 4.95). Entonces, es de suponer que esa diferencia es lo que hace que se le preste mayor atención.
Había estado usando la misma clave autofirmada y el mismo certificado (con una marca de tiempo de 2013) que en la instalación anterior. También intenté generar un nuevo par con una falta de efecto similar.
Después de buscar consejos en línea, se sugirió utilizar una configuración letsencrypt para poder validarla. Ya lo uso, pero provocó el mismo comportamiento en EXIM.
Esta es mi configuración
/etc/exim4/update-exim4.conf.conf:
dc_eximconfig_configtype='smarthost'
dc_other_hostnames='<LOCAL DOMAIN>'
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='<ISP DOMAIN>:587'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'
/etc/exim4/etc/exim4/conf.d/main/00_local_settings:
MAIN_TLS_ENABLE = yes
MAIN_TLS_CERTIFICATE = /etc/letsencrypt/live/<LOCAL DOMAIN>/fullchain.pem
MAIN_TLS_PRIVATEKEY = /etc/letsencrypt/live/<LOCAL DOMAIN>/privkey.pem
/etc/letsencrypt/archive/<DOMINIO LOCAL>/*15.*
-rw-r--r-- 1 root Debian-exim 1870 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/cert15.pem
-rw-r--r-- 1 root Debian-exim 3749 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/chain15.pem
-rw-r--r-- 1 root Debian-exim 5619 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/fullchain15.pem
-rw------- 1 root Debian-exim 1708 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/privkey15.pem
También tengo /etc/exim4/passwd.clientun archivo con mis datos de inicio de sesión SMTP y que obviamente funciona para enviar correo.
es un dominio que apunta a la dirección IP de mi casa.
Las entradas de las claves letsencrypt en 00_local_settings apuntan a sus enlaces simbólicos que van a las versiones actuales. En aquellos, cambié la propiedad del grupo para que EXIM pueda ver la clave privada, pero deje los permisos en paz.
Mi configuración de trabajo anterior era la misma, pero con los archivos autofirmados exim.crty exim.keyen /etc/exim4, y sin las dos últimas líneas en mi archivo 00_local_settings.
También intenté copiar los archivos letsencrypt /etc/exim4y nombrarlos exim.certy exim.keycon los mismos permisos de 640 y nada en 00_local_settings pero no cambió nada.
Lo que es particularmente molesto es que como prueba final simplemente eliminé las claves sin configuración para que vieran qué pasaba. Recibí el mismo error, por lo que no puedo decir si hay un problema con las claves que he usado o simplemente ni siquiera las veo.
Respuesta1
Continué investigando y encontré una especie de respuesta. No tenía claro de qué certificado se estaba verificando, había asumido el mío pero me di cuenta de que podría ser el del servidor SMTP remoto.
Agregar la entrada a continuación para /etc/exim4/etc/exim4/conf.d/main/00_local_settingsdeshabilitar la verificación permite utilizar TLS.
REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS = !*
Esto se puede confirmar en el encabezado del mensaje que ahora muestra que se recibió.with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95)
Supongo que esto es lo que estaba sucediendo antes y que Debian o Exim cambiaron el valor predeterminado para requerir verificación desde mi configuración inicial.
Presumiblemente, si el servidor remoto utiliza un certificado autogenerado, ¿no se puede verificar?