dovecot confundir o certificado do site com o mail cert

Question

Vou tentar resumir isso. Quero que o beta.example.com use meu servidor como um servidor de e-mail. Eu vejo que dovecot e postfix tem apenas uma linha para um certificado. Então eu fiz um certificado para mail.example.com que é completamente válido. Eu tentei usar thunderbird para se conectar ao meu servidor de email (beta.example.com) e me deu um aviso de domínio incorreto dizendo que o certificado pertence a mail.example.com. Onde eu estraguei tudo? O registro mx diz mail.example.com, então não deveria saber que o certificado é para mail.example.com? Eu adicionei uma exceção no entanto, ele ainda falha (depois de solicitar minha senha). Eu olhei para o meu servidor e parece que o dovecot está rejeitando a conexão porque o thunderbird está fornecendo dados inválidos.

    

Answer 1

Você enfrenta o propósito dos certificados: evitar conectar-se acidentalmente a um servidor que não é o esperado ( mail.example.com em vez de beta.example.com ). Você deve configurar um certificado emitido para o domínio ao qual você se conecta, por exemplo. se o cliente de e-mail se conectar a beta.example.com , você precisará de um certificado para beta.example.com .

Obtenha outro certificado para beta.example.com (ou inclua-o como nome alternativo de assunto) ou use mail.example.com para o IP de beta.example.com .

    

Answer 2

O cliente está configurado para se conectar a mail.example.com .

O servidor que se conecta a declarações (no certificado) é beta.example.com .

Como mail.example.com não é a mesma coisa que beta.example.com , o cliente reclama da incompatibilidade. Isso é inteiramente por design.

Para que isso funcione, você precisa configurar seu servidor de e-mail para apresentar um certificado que inclua um Nome alternativo sujeito que corresponda ao nome do host para o qual o cliente está apontado. Como esse nome do host termina sendo resolvido para um endereço IP está além do ponto.

Costumava colocar o nome do host no campo Common Name do certificado, mas esta prática está sendo reprovada. Você ainda pode colocar o nome do host como CN do certificado, se quiser, mas para melhor compatibilidade, é necessário também colocá-lo como SAN. Acredito que a maioria das CAs colocará o CN como uma SAN como um serviço para você, caso você não o faça no seu CSR, mas há o risco de que alguns não o façam; verifique seu certificado.

Se você deve usar o mesmo certificado para o Postfix e o Dovecot, mas por algum motivo você quer que nomes de host diferentes sejam publicados para os dois (digamos smtp.example.com e pop.example.com ), então você precisa de um certificado que seja válido para ambos os nomes de host envolvidos. Isso pode ser feito com um certificado de vários nomes de host ou com um certificado curinga ( *.example.com ).

Além disso, MX (mail exchanger) RRs DNS são realmente relevantes somente para conexões SMTP de entrada para um servidor de correio que manipula mensagens para um domínio específico, onde o servidor de correio remoto inicialmente conhece apenas o domínio do destinatário. É perfeitamente válido ter, por exemplo,

example.com. MX 0 mail.example.com.
mail.example.com. CNAME beta.example.com.
beta.example.com. A 192.0.2.123

embora não seja realmente recomendado, porque apontar um RR para um RR não canônico pode fazer com que alguns resolvedores engasguem. No entanto, se o resolvedor do sistema remoto aceitar (a maioria faz), o acima é efetivamente o mesmo que se você tivesse

example.com. MX 0 mail.example.com.
mail.example.com. A 192.0.2.123

Em ambos os casos, o MTA remoto (agente de transferência de e-mail; nos dias de hoje, um servidor de e-mail falando SMTP para outros servidores de e-mail) estará se conectando a mail.example.com (porque esse é o nome do host do MX fornecido no MX RR), e assim estará esperando um certificado que seja válido para mail.example.com.

Seu MUA não estará consultando os registros MX e não saberá de nenhuma maneira; ele consultará o endereço ( A , AAAA e, em casos raros, talvez também A6 ; os RRs A6 foram preteridos, mas foram usados por algum tempo para IPv6) registros de qualquer nome de host fornecido como entrada ( POP / IMAP) ou de saída (SMTP).