Exchange 2010 híbrido, SMTP, certificados SSL y nombres alternativos de sujeto
En cada servidor Exchange necesita certificados SSL para fines de autenticación, validación y cifrado. Para SMTP puede utilizar el certificado autofirmado. Exchange 2010 utiliza TLS oportunista, por lo que el certificado autofirmado servirá en este escenario. Si necesita configurar la seguridad del dominio (TLS mutuo) en Exchange, necesita un certificado SSL de terceros adecuado para ello.
La comunicación SMTP entre Office 365 y Exchange en un escenario híbrido es un ejemplo de TLS mutuo o seguridad de dominio. Se necesita un certificado SSL de terceros adecuado en su servidor Exchange.
Siempre tuve la impresión de que TLS mutuo solo puede usar el nombre común del certificado, que en mi caso es CN=webmail.inframan.nl. Después de una publicación de blog anterior hubo una discusión interesante (ver los comentarios de esta publicación de blog en particular) sobre esto, así que ahora es el momento de hacer algunas pruebas.
Originalmente tenía un certificado SSL Digicert con nombre común CN=webmail.inframan.nl y una entrada de nombre alternativo del sujeto autodiscover.webmail.com. Durante el HCW entré en webmail.inframan.nl y seleccioné el certificado adecuado.
Ya era hora de renovar mi certificado SSL, así que agregué una entrada SAN adicional o365mail.inframan.nl.
Cuando ejecuto nuevamente el Asistente de configuración híbrida en mi servidor Exchange 2010, selecciono el certificado SSL adecuado:
E ingresó el FQDN adicional o365mail.inframan.nl:
Al validar el conector, tiene éxito, pero cuando miras de cerca todavía usa el antiguo FQDN webmail.inframan.nl.
Esperaría el nuevo FQDN aquí, pero aparentemente el HCW no reconfigura el conector de recepción de Office 365 en mi Exchange 2010. Todavía está configurado para webmail.inframan.nl:
Entonces, después de cambiarlo a o365mail.inframan.nl:
El proceso de validación nuevamente se realiza correctamente, pero ahora utiliza el FQDN o365mail.inframan.nl (y la entrada SAN en el certificado SSL) para el flujo de correo de Office 365 a Exchange 2010:
Entonces, a diferencia de mi creencia anterior, no necesita un certificado SSL separado para un FQDN adicional, pero también puede usar una entrada SAN adicional en su certificado SSL existente.
Puede encontrar más información sobre los requisitos de certificados para implementaciones híbridas aquí: https://technet.microsoft.com/en-us/library/hh563848(v=exchg.141)
¿Por qué quieres usar esto en primer lugar?
Usar uno o dos servidores Exchange 2010 no tiene sentido, pero también tengo un cliente que tiene 28 servidores Exchange 2010 ejecutándose con 40 000 buzones de correo, y aquí queremos separar el tráfico SMTP de Office 365 del tráfico SMTP normal. Al observar los certificados, es más fácil mantener solo un certificado SSL con una entrada SAN adicional que un certificado SSL adicional con un solo nombre de dominio.
Un agradecimiento especial a 'Trekveer Harry' por indicarme esta dirección ?