Certificados do Exchange não correspondem

Question

Ok, eu tenho dois subdomínios indo para minha caixa do Exchange no trabalho (Exchange 2007 no Server 2008). O subdomínio interno é exchange.company.com e o domínio externo é webmail.company.com. Nosso domínio do AD é o mesmo nome do domínio do nosso website. Nosso servidor DNS aponta internamente exchange.company.com para a caixa Exchange, assim como webmail.company.com. O Exchange.company.com não está apontando para nada no DNS externo.

Assim, para permitir que as pessoas acessem seus e-mails de fora e facilitem o contato com telefones e conexões, comprei um certificado SSL da GoDaddy outro dia e instalei-o. Infelizmente, o certificado GoDaddy aponta para webmail.company.com, e o Outlook de todos é direcionado para exchange.company.com. Portanto, as pessoas continuam recebendo um tipo de mensagem "O certificado é válido, mas o domínio para o qual ele está atribuído não corresponde ao domínio em que está". Não me lembro das palavras exatas.

De qualquer forma, minha pergunta é: como configurar um certificado (aquele distribuído pela CA confiável de dentro da minha empresa) para ser usado para MAPI e o outro para ser usado para o IIS? Ou, melhor ainda, se a máquina for acessada como webmail.company.com, use o GoDaddy, se for exchange.company.com, use o certificado interno da CA.

    

Answer 1

Como você disse em um comentário que não deseja usar um certificado curinga, precisa de 2 certificados SSL e 2 endereços IP no seu servidor Exchange.

Certificados SSL são vinculados a 1 por combinação de IP + Porta no IIS, portanto, ao adicionar um segundo IP ao servidor Exchange, você pode atribuir seu certificado SSL gerado internamente antes de comprar o novo, ou outro adquirido Certificado SSL referente a exchange.company.com, e atribua webmail.company.com ao novo endereço IP, novamente no IIS.

Você aponta seu encaminhamento de porta externa para o novo segundo endereço IP com o certificado SSL do webmail.company.com vinculado a ele.

É um pouco complicado, mas deve funcionar bem para você.

    

Answer 2

A melhor maneira e a melhor maneira de fazer isso é com um certificado UC, também conhecido como certificado SAN (Subject Alternative Names). AQUI é uma ótima informação sobre como / o que é uma SAN e como ela funciona.

Mas, basicamente, o certificado com vários nomes, provavelmente: nome do servidor netbios, FQDN do servidor local, seu URL de webmail e um URL de descoberta automática

Como nota adicional, tenho uma configuração semelhante em um dos meus servidores. Ele está executando o SharePoint e o Exchange 2007. Eu tenho um certificado SAN com o seguinte:

servername, servername.domain.local, autodiscover.domain.com, go.domain.com, internal.domain.com

Isso permite que meus clientes do Outlook se conectem ao Exchange sem avisos de certificado e também meus sites do SharePoint e OWA de dentro e de fora sem nenhum aviso também. Isso também faz com que meus clientes consigam se conectar usando o Outlook em Qualquer Lugar com a Descoberta Automática.

Provavelmente não é a resposta que você quer ouvir, mas jogar as duas certificações separadas em favor de uma SAN vai poupar uma tonelada de dor de cabeça quando se trata do IIS, a necessidade de vários endereços IP, cabeçalhos de host, etc. que você precisaria brincar com ele para que ele funcione do jeito que você quer.

    

Answer 3

Os curingas usados no POP3 e no IMAP como parte de uma implementação do Exchange podem ser complicados, embora isso possa ser feito. Se você olhar em volta deste site, você notará que as pessoas vão com os certificados UC quando se trata de trocar.

veja Certificados SSL Wildcard com o Exchange 2010?

Se você decidir usar curingas, poderá encontrar o SSLTools Manager para Windows útil em erros de solução de problemas, incluindo o nome 'temido' erro de incompatibilidade '.

    

Answer 4

A maneira mais fácil de realizar isso é usar os certificados SSL curinga embora estes sejam bastante caros. Isso permitirá que o certificado seja usado para * .company.com e você não precisará se preocupar com as configurações de certificado em sua infraestrutura do Exchange.

Outra maneira é publicar seu OWA através do ISA Server. Isso permitirá que você tenha um certificado diferente para o OWA externo. A comunicação entre o ISA e seu servidor OWA de back-end, no entanto, será sobre http (não criptografada).

    

Answer 5

Os certificados curinga são gratuitos, depois de ter passado a validação de $ 40 Classe 2 no link

Estou usando seus certificados em todos os meus servidores, incluindo o Exchange 2010.