Error de certificado SSL en programas de mail de PC (Outlook/Thunderbird)
Motivos y soluciones
Tags: Mail corporativo, Ayudas técnicas para e-mails, MS Outlook y Mozilla Thunderbird
Si Outlook o Thunderbird muestran alertas como “El nombre del servidor no coincide”, “El certificado no es de confianza” o “La conexión está cifrada con un certificado inválido”, no significa necesariamente que haya un ataque.
Aquí te explicamos las causas más comunes y cómo resolverlas de forma segura —tanto del lado del usuario como del servidor.
Síntomas típicos en Outlook/Thunderbird
Outlook: alerta por nombre de servidor no coincidente o certificado caducado.
Thunderbird: aviso de certificado no confiable o firmado por emisor desconocido.
También pueden aparecer errores intermitentes después de una migración de hosting, un cambio de DNS o una renovación de certificado.
Causas frecuentes
- Nombre común (CN) / SAN no coincidente: el certificado no cubre el host configurado en el cliente (ej.: se usa mail.midominio.com pero el cert es para server.midominio.com).
- Certificado vencido o revocado y/o cadena incompleta (intermedios faltantes).
- Servidor presenta TLS obsoleto (ej.: TLS 1.0/1.1) o suites no compatibles con el cliente.
- Antivirus/Firewall con “inspección SSL” intercepta la conexión y “re-firma” con un certificado propio.
- Portal cautivo/Proxy (red pública/empresa) que fuerza certificados de inspección.
- Hostname/HELO y rDNS mal configurados en el servidor (no coincide el FQDN presentado).
Esquema de cadena de certificados: raíz, intermedio y certificado del servidor con validación del nombre de host
Cadena correcta: Certificado del servidor + intermedios completos + raíz confiable en el sistema.
Diagnóstico rápido
Desde la PC del usuario
- Verificar que el servidor configurado en la cuenta sea exactamente el FQDN del certificado
(ej.: mail.midominio.com). - Probar la conexión con:
openssl s_client -connect mail.midominio.com:993 -servername mail.midominio.com -showcerts
# Revisar: CN/SAN, fechas de validez, cadena completa e identificación del emisor - Desactivar momentáneamente “inspección SSL” en antivirus/firewall y reintentar.
- Probar con otra red (tethering) para descartar proxy/portal cautivo.
En el servidor (Postfix/Dovecot)
- Comprobar rutas y permisos de la cadena de certificados y clave.
- Verificar soporte SNI si se atienden múltiples dominios.
- Test externo (IMAPS/POP3S/SMTPS):
openssl s_client -connect mail.midominio.com:465 -servername mail.midominio.com -starttls smtp -tlsextdebug
No agregues “excepciones permanentes” en el cliente salvo pruebas temporales: enmascaran el problema real y bajan la seguridad.
Soluciones del lado del usuario
- Usar el host correcto: en IMAP/POP/SMTP coloca exactamente el FQDN cubierto por el certificado.
- Eliminar certificados “interceptores” instalados por antivirus o redes corporativas, o desactivar la inspección SSL.
- Actualizar cliente de correo (Soporte TLS 1.2/1.3).
- Limpiar caché de credenciales/certificados y reiniciar el equipo antes de reintentar.
- Outlook (Windows): en “Configuración de cuenta > Servidor”, revisar puertos: IMAP 993/SSL, SMTP 465/SSL o 587/STARTTLS.
- Thunderbird: “Configuración de servidor > Seguridad de la conexión” = SSL/TLS; “Método de autenticación” = Contraseña normal.
Soluciones del lado del servidor (Postfix/Dovecot en AlmaLinux/CWP)
1) Certificado válido y cadena completa
/etc/ssl/private/ # claves (.key) - permisos 600
/etc/ssl/certs/ # cadenas (.pem)
# Ejemplo Dovecot
ssl = required
ssl_cert = </etc/ssl/certs/mail.midominio.com.fullchain.pem
ssl_key = </etc/ssl/private/mail.midominio.com.key
ssl_min_protocol = TLSv1.2
# Ejemplo Postfix (nuevo esquema con 'tls_server_sni_maps' si usas SNI)
smtpd_tls_cert_file = /etc/ssl/certs/mail.midominio.com.fullchain.pem
smtpd_tls_key_file = /etc/ssl/private/mail.midominio.com.key
smtpd_tls_security_level = may
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols = !SSLv2,!SSLv3
smtpd_tls_eecdh_grade = strong
2) Coincidencia FQDN / HELO / rDNS
- El FQDN del servidor (ej.: mail.midominio.com) debe ser el que presenta el certificado, el HELO y resolver a la IP del servidor.
- Registrar PTR/rDNS coherente con ese FQDN en el proveedor.
3) Renovación automática (ACME)
/root/.acme.sh/acme.sh --issue -d mail.midominio.com --nginx
# Instalar/actualizar y recargar servicios
systemctl reload postfix
systemctl reload dovecot
4) Intermedios y compatibilidad
- Fullchain.pem debe incluir el cert del servidor + intermedios.
- Forzar TLS 1.2/1.3 y suites modernas para compatibilidad amplia con Outlook y Thunderbird.
Con FQDN correcto, fullchain instalado, TLS 1.2/1.3 y rDNS/HELO alineados, los clientes dejan de pedir excepciones y se conectan sin alertas.
Preguntas frecuentes (FAQ)
¿Puedo usar server.midominio.com si mis usuarios configuran mail.midominio.com?
Sí, siempre que el certificado cubra ambos nombres (SAN) o que todos los clientes usen el mismo FQDN que cubre el certificado.
¿Por qué en la oficina falla y en mi casa no?
Redes corporativas o antivirus con inspección SSL insertan certificados propios. Al salir de esa red, la inspección no ocurre y el error desaparece.
¿Sirve agregar una excepción permanente?
No es recomendable. Es una medida temporal de diagnóstico. La solución pasa por corregir CN/SAN, cadena, TLS y configuración de red.
Para más información detallada, aguardamos tu contacto
Formas de pago
Realizamos Factura A y B
» TRANSF. MERCADOPAGO
» WESTERN UNION
¿Necesitas ayuda?
Nuestros expertos están listos para ayudarte