Recentemente, migramos do Exchange 2003 para 2010. Metade dos nossos usuários do Outlook está usando o Outlook do servidor de terminal, que está no mesmo domínio que o Exchange. A outra metade dos Outlook está instalada em laptops que não estão no domínio. Eles geralmente usam o OpenVPN para se conectar ao Exchange (e também a outros serviços), mas ocasionalmente, quando estão localizados em algum lugar onde há a maioria das portas de saída bloqueadas (principalmente hotéis), eles usam o Outlook Anywhere.
Temos dois certificados: um para 'ourexchangeserver', auto-assinado e outro para '* .ourexternaldomain.tld', assinado pela StartCom.
Ao abrir o EMC > Configuração do servidor > Certificados do Exchange, podemos atribuir serviços IMAP, POP, SMTP e IIS a um determinado certificado.
O problema é que o RPC também parece usar esse mesmo certificado. Portanto, quando atribuímos o certificado curinga ao IIS, podemos acessar o OWA externamente sem nenhum alerta de segurança, mas os Outlooks exibem um alerta de segurança de que o nome do host é inválido (não corresponde ao campo emitido no certificado apresentado).
Quando atribuímos o certificado autoassinado ao IIS, ocorre o contrário: os Outlook não reclamam, mas o navegador exibe o mesmo alerta de segurança ao visitar o OWA.
Meu provedor de certificado (StartCom) não me permite gerar um certificado emitido para um host com parte de domínio ausente ou inexistente.
Seria possível configurar o Exchange 2010 com esses 2 certificados para que o OWA apresentasse o certificado público e o tráfego RPC fosse coberto pelo certificado auto-assinado?
As respostas habituais para este problema são:
Os certificados especiais têm vários Nomes Alternativos de Assunto, para que possam ser válidos para uma variedade de nomes. Presumivelmente, seus nomes internos e externos para seus serviços OWA e RPC.
Tags exchange