Intentaré que esto sea breve. Quiero que beta.example.com use mi servidor como servidor de correo. Veo que dovecot y postfix tienen solo una línea para el certificado. Entonces hice un certificado para mail.example.com que es completamente válido. Intenté usar Thunderbird para conectarme a mi servidor de correo (beta.example.com) y me dio una advertencia de dominio incorrecta que decía que el certificado pertenece a mail.example.com. ¿Dónde me equivoqué? El registro mx dice mail.example.com, entonces, ¿no debería saber que el certificado es para mail.example.com? Agregué una excepción, sin embargo, todavía falla (después de que me solicita mi contraseña). Miré mi servidor y parece que Dovecot está rechazando la conexión porque Thunderbird le está proporcionando datos de certificado incorrectos.
Respuesta1
Experimenta el propósito mismo de los certificados: evitar conectarse accidentalmente con un servidor que no es el que espera ( mail.example.comen lugar de beta.example.com). Debe configurar un certificado emitido para el dominio al que se conecta, es decir. Si el cliente de correo se conecta beta.example.com, necesita un certificado para beta.example.com.
Obtenga otro certificado para beta.example.com(o inclúyalo como nombre alternativo del sujeto) o apunte mail.example.coma la IP de beta.example.com.
Respuesta2
El cliente está configurado para conectarse a mail.example.com.
El servidor al que se conecta afirma (en el certificado) ser beta.example.com.
Como mail.example.comno es lo mismo que beta.example.com, el cliente se queja del desajuste.Esto es enteramente por diseño.
Para que esto funcione,debe configurar su servidor de correo para presentar un certificado que incluya un Nombre alternativo del sujeto que coincida con el nombre de host al que apunta el cliente.Cómo ese nombre de host termina resolviendose en una dirección IP no viene al caso.
Solía poner el nombre del host en el campo Nombre común del certificado, pero esta práctica está en desuso. Aún puedes poner el nombre del host como CN del certificado si lo deseas, pero para una mejor compatibilidad debestambiénPonlo como SAN. Creo que la mayoría de las CA incluirán la CN como SAN como un servicio para usted si no lo hace usted mismo en su CSR, pero existe el riesgo de que algunas no lo hagan; revisa tu certificado.
Si debe utilizar elmismo certificadopara Postfix y Dovecot, pero por alguna razón desea tenerdiferentes nombres de hostpublicado para los dos (digamos smtp.example.comy pop.example.com), entonces necesita un certificado que sea válido para ambos nombres de host involucrados. Esto se puede hacer con un certificado de múltiples nombres de host o un *.example.comcertificado comodín ().
También,Los RR DNS MX (intercambiador de correo) en realidad solo son relevantes para conexiones SMTP entrantes a un servidor de correo que maneja correo para un dominio en particular, donde el servidor de correo remoto inicialmente solo conoce el dominio del destinatario.Es perfectamente válido tener por ejemplo
example.com. MX 0 mail.example.com.
mail.example.com. CNAME beta.example.com.
beta.example.com. A 192.0.2.123
aunque no es realmente recomendable porque apuntar un RR a un RR no canónico puede ahogar a algunos solucionadores. Sin embargo, si el solucionador del sistema remoto lo acepta (la mayoría lo hace), lo anterior es efectivamente lo mismo que si hubiera tenido
example.com. MX 0 mail.example.com.
mail.example.com. A 192.0.2.123
En ambos casos, el MTA remoto (agente de transferencia de correo; en la actualidad, un servidor de correo que habla SMTP con otros servidores de correo) se conectará a mail.example.com (porque ese es el nombre de host del MX tal como se indica en el MX). RR) y, por lo tanto, esperará un certificado válido para mail.example.com.
Tu MUA no consultará los registros MXy no lo sabrá de ninguna manera; consultará los registros de dirección ( Ay AAAAen casos raros tal vez también A6; los RR A6 están en desuso, pero se usaron durante algún tiempo para IPv6) de cualquier nombre de host que le dé como entrante (POP/IMAP) o saliente (SMTP) servidor de correo.