Isso depende do que você deseja e dos detalhes da sua configuração.
Serviço smtpd : Um certificado tem um Nome Comum (CN) como você sabe, mantendo o domínio para o qual ele é válido. Diga isso example.com
e *.example.com
, como um caso típico de certificados destinados à web.
Se o nome do host do servidor de email for mail.example.com
(o domínio no registro MX é importante aqui), o certificado fornecido pelo servidor de email é válido para example.com
, incluindo subdomínios e a validação (se concluída) é bem-sucedida. Se o nome do host do servidor de e-mail (aquele no registro MX) não corresponder (por exemplo, externalservice.example.net
), ele falhará.
No caso de um certificado autoassinado, esperamos que o CN corresponda ao FQDN, mas definitivamente não é assinado por um certificado confiável.
Assim, ambas as variantes podem estar falhando. Certifique-se de que o FQDN do servidor de email corresponda ao CN do certificado (ou o contrário). Além disso, forneça a cadeia de certificados para as CAs raiz. Veja os documentos para isso.
Mas, infelizmente, é muito comum usar assinaturas auto-assinadas, desatualizadas ou não confiáveis para servidores de e-mail. Apenas uma minoria dos servidores de email em operação possui certificados válidos. Recentemente, vi uma pesquisa que mostra que apenas 5% ou menos têm certificado válido, mas não consigo encontrá-lo no momento. Ligará mais tarde quando eu encontrar.
No caso do serviço envio , a validação é mais importante, pois os usuários reais se conectam ao serviço e podem receber um aviso de certificado. Os MUAs comparam o domínio configurado para mensagens recebidas e enviadas com o CommonName usado. O mesmo que para smtp aplica-se aqui, mas os usuários irão reclamar, se receberem avisos trust , ou as conexões falharem. Como você tem um certificado curinga, pode usar com segurança smtp.example.com
como nome do host para esse tipo de tarefa. Sem um curinga, não é tão fácil.