Infelizmente, sua melhor opção é obter um certificado de UC, o que significa excluir o curinga e comprar um novo inteiramente. Veja minha resposta AQUI para uma pergunta semelhante.
anteriormente solicitamos um certificado ssl curinga de godaddy para nosso domínio principal. Uma das razões foi o novo servidor Exchange 2010 estabelecido. geralmente você precisa seguir os nomes incluídos no certificado:
com o certificado curinga, tudo isso é coberto (exceto o nome do host local). Durante a criação / importação do certificado SSL no Exchange 2010, a troca primeiro pergunta, se um certificado curinga é usado e, em seguida, encontra um erro - > devido ao certificado é um certificado curinga e não um certificado especialmente gerado para o FQDN, o SSL para POP e IMAP não pode ser fornecido.
não encontrei nenhuma solução alternativa ou solução para isso no google, então espero, talvez alguém aqui tenha uma resposta ou solução para mim! :)
o Exchange 2010 está sendo executado em uma empresa do Windows Server 2008 R2.
obrigado antecipadamente e os melhores cumprimentos, sise
Infelizmente, sua melhor opção é obter um certificado de UC, o que significa excluir o curinga e comprar um novo inteiramente. Veja minha resposta AQUI para uma pergunta semelhante.
Boo, certificados de UC são um ripoff maior do que os certificados normais e só são necessários principalmente por causa do NAT. Quando o IPv6 se torna amplamente usado e todos os computadores têm um endereço verdadeiro, isso será discutível, já que seu servidor não precisará resolver para um endereço diferente dentro e fora do firewall.
Isso pode ser facilmente tratado se você estiver usando um sistema DNS de duas faces que, para o mesmo nome de host, forneça endereços privados (RFC1918) a usuários internos e o endereço público do servidor a usuários externos. Por exemplo, mail.example.com de seus servidores internos retorna 10.0.0.11 e de um servidor externo retorna 208.65.70.82. Portanto, ao conectar-se ao seu servidor internamente, você ainda usaria mail.example.com.
Consulte o Artigo 940726 da Microsoft KB, que explica como alterar o URL interno de todos os serviços de troca para seja o mesmo que o URL externo. Ele cita especificamente essa "solução alternativa" para pessoas que "não podem" usar um certificado que suporte nomes alternativos de assunto. Para ser honesto, acho que essa configuração se tornará padrão na próxima uma ou duas versões do Exchange, já que o IPv6 se torna um lugar comum.
Também descobrimos que isso é ótimo para os usuários de dispositivos móveis, porque mail.example.com resolverá o mesmo servidor dentro do firewall como acontece fora, especialmente quando eles estão usando um protocolo como o IMAP com um cliente que não usa suporte a "Outlook Anywhere".
Para seus problemas de POP / IMAP, consulte Artigo 948896 da Microsoft KB . Basicamente você acabou de definir o X509CertificateName para o FQDN que os usuários estarão acessando o serviço de (com Set-ImapSettings -X509CertificateName mail.example.com ou através da GUI) e não especificamente atribuir o certificado para o serviço IMAP usando o comando Enable-ExchangeCertificate .
você pode usar um curinga para o imap e o pop. rtfm aqui: link
:)
Esteja ciente de que você pode usar curingas nos certificados de Unified Communications (UC ou SANS) para ter muitas opções e versatilidade. Já vi várias postagens em que as pessoas estão tendo problemas para fazer com que POP e SMTP funcionem com curinga no Exchange. Então, talvez usar um curinga dentro do certificado UC seja um bom compromisso.
Tags imap wildcard pop3 exchange-2010