En esta entrada vemos mejores prácticas y errores comunes a nivel de configuración de certificados en Exchange.
Partes anteriores:
Mejores prácticas a nivel de certificados para Exchange
1. Adquirir un certificado de una entidad certificadora (CA) externa. De las recomendadas para Exchange encontramos Godaddy, Digicert y Comodo entre otras.
2. Utilizar certificados con atributo de SAN (Subject Alternative Names). Esto nos permite utilizar un nombre principal en el certificado por ejemplo webmail.contoso.com y agregar otros en el campo de SAN como por ejemplo autodiscover.contoso.com, etc. Algunos proveedores lo comercializan como UCC (Unified Communications Certificate)
3. Si dentro del asistente de solicitud de certificado se sugieren nombres internos para el certificado es porque probablemente algún servicio no este correctamente configurado, en este caso editar los nombres a incluir y verificar que servicio esta utilizando un nombre incorrecto (en general el FQDN del servidor).
4. Minimizar la cantidad de nombres a utilizar en el certificado. Para esto podemos utilizar un Split DNS. La idea acá sería que en lugar de incluir nombres internos y externos en el certificado utilicemos un espacio de nombre unificado y que dependiendo de donde se consulte a nivel de DNS si se devuelve una IP privada (interna) o una pública (externa).
5. Utilizar el mismo certificado en todos los servidores con el rol de CAS. Se realiza el procedimiento de solicitud, procesamiento, etc en uno de los servidores y posteriormente se exporta junto a su llave privada y se importa en el resto de los servidores.
Por último algunos errores típicos de configuración
1. Dejar los servicios con URLs interna by default. Esto implica que utilizan el nombre de servidor en lugar de un nombre común como por ejemplo webmail.contoso.com.
2. Incluir el nombre netbios y FQDN de cada servidor Exchange en el certificado. Esto no es necesario, tendríamos que incluir únicamente los nombres asociados a los distintos servicios en uso.
3. Configuración de Autodiscover. Dependiendo del mecanismo seleccionado de autodiscover si es necesario afectar los certificados en uso cuando agregamos un nuevo dominio o no. Por ejemplo si utilizamos registros SRV no es necesario modificar el certificado, pero si deseamos que usuarios de un nuevo dominio utilicen “autodiscover.nuevodominio.com”, si lo es. El tema de autodiscover es bastante extenso y daría para una entrada entera en sí mismo por lo que dejo el link a un white paper de Microsoft que si bien fue hecho para Exchange 2010 la mayoría de los conceptos aplican a Exchange 2013 / 2016.
Por más información teórica y práctica sobre configuración de Exchange, Certificados y autodiscover, ver el siguiente recurso para miembros VIP del sitio (videos de entrenamiento):
Daniel says
Saludos, tengo un problema como remuevo un certificado que importe en Exchange 2013 por error, al importarlo directamente no aparece como disponible. Gracias
Aprendiendo Exchange says
Hola Daniel, en el EAC de Exchange 2013 no aparece entonces?
De ser así lo que podrías hacer es lo siguiente:
1. Abrir el shell de Exchange
2. Obtener información de los certificados en uso:
Get-ExchangeCertificate | fl
3. Copiar el Thumbprint del certificado a eliminar (asegurarse de tomar el correcto)
4. Eliminar el certificado:
Remove-ExchangeCertificate -Thumbprint «Pegar valor obtenido en paso 3»
Contame como te fue.
saludos!
daniel says
Gracias, lo solucione eliminandolo por el iis y pude crear una nueva solicitud e instalar el certificado correcto, tengo ahorita es un problema respecto que me muestra el analizador de Microsoft evaluando outlook anywhere el mensaje dice que el
servidor necesita cifrado»
Aprendiendo Exchange says
Hola Daniel, excelente que lo hayas resuelto. Te cuento para futuro que las tareas que tengan relación con certificados en gral se deben realizar con las herramientas de Exchange, de lo contrario se pueden generar varios temas.
Respecto a lo de outlook anywhere, tendrías que tener en cuenta lo siguiente:
Certificado válido (llave privada, nombres incluidos, confiable, etc)
Configuración SSL
Autenticación
Autodiscover en gral
Te dejo un link de configuración de Client Access donde se indican los comandos especificos para Outlook Anywhere en Exchange 2013:
http://technet.microsoft.com/en-us/library/hh529912%28v=exchg.150%29.aspx
Marcelo Sosa says
Hola Daniel, tengo windows server 2012 r2 como domain controller y a la vez servicio de entidad certificante, por otro lado tengo Exchange 2013. Tengo un certificado ya instalado que venció en 08/02/19 y que fue generado en su momento por la misma CA. Ahora debo generar uno nuevo utilizando la Entidad certificante, pero solo avanzo hasta la generación del archivo .req. Cuando pego el contenido del .req, selecciono ‘servidor web’ y presiono submit no avanza a la pantalla siguiente para descargar el certificado. ¿Qué puede estar ocurriendo? Por favor necesito ayuda. Muchas gracias.
Daniel Núñez Banega says
Hola Marcelo, asumiendo que todo este ok y hayas generado el REQ desde el servidor con Exchange, es posible que sea un tema con el navegador (entre otros). Una opción podría ser seguir el asistente de solicitud de certificado localmente desde el servidor donde tenés instalada la CA.
Victor Monjaras says
Que tal Daniel, felicidades por tu trabajo. Soy nuevo en esto de los SSL, y compramos uno en la compañía con GoDaddy para Exchange 2013. La instalación es nueva y en la instalación aparecen los certificados por default. Al descargar el certificado nuevo me da 3 archivos: los intermedios con extensión .p7b, y el otro que me aparece es uno con extensión .crt y un con extensión .pem. Al seguir las instrucciones de instalación solo se instala en el servidor local (mmc-certificates (local computer)), pero no me aparecen en el EAC de Exchange. ¿qué estoy haciendo mal?
Daniel Núñez Banega says
Buenas Victor, si bien hay muchas formas de instalar el certificado, la recomendada en este caso es generar la solicitud en Exchange (shell o EAC) y luego procesarla con los archivos que te devuelva el proveedor de Certificados con las propias herramientas de Exchange.
Al descargar los archivos del proveedor en general hay una opción que permite indicar el formato, en este paso habría que verificar que sea compatible con Exchange o IIS, por el archivo PEM me da la impresión de que es posible que no se haya descargado en el formato esperado.