Por Patricia Cifuentes

Encuentro que este tema está aún no muy claro para la mayoría de nuestros clientes, usualmente abren casos con Microsoft para que les ayudemos a crear la petición del certificado. Algo que nosotros como soporte es difícil recomendar ya que para dar recomendaciones es necesario tener conocimiento completo del ambiente de servidores y entender las necesidades del certificado. La configuración de los Certificados Digitales es diferente, para cada Organización, por lo que hablaremos de prácticas generales que pueden ser seguidas, para lograr la más segura y eficiente configuración de los certificados.

Primera duda….. Cuáles son los nombres que el certificado necesita?

Vuelvo a repetir…. Depende del ambiente y para que se necesita el certificado…

Por ejemplo, si lo necesitas para solo un CAS Server… O tal vez 2 o 3 o 4…

Allí ya tal vez necesitemos el certificado con mas nombres o URL’s.

Que es lo que recomendamos? Comenzaré por explicar algunas prácticas que no necesariamente aplican a todos los ambientes….

- Práctica #1 : Usar un certificado confiable de terceros

Lo recomendamos para prevenir que los clientes reciban el mensaje de advertencia donde tiene que aceptar que confían en el sitio que van acceder por el uso de certificados “no confiables”

clip_image002

 

El Certificado usado por tu servidor de Exchange, debe de ser generado por una entidad que tus clientes confían, esto es debido a que la mayoría de los clientes confían sus Certificados Raíz.

Hay varias entidades de terceros certificadoras que ofrecen certificados para Exchange. Puedes usar la consola de Exchange para generar la petición de Certificados, que es usada por la mayoría de las entidades que los generan.

 

- Práctica #2 : Usar certificados con SAN (Nombre Alternativo del Sujeto)

Dependiendo de la configuración de Exchange en tu organización, tu servidor de Exchange puede usar un Certificado que represente múltiples nombres de dominio.

Aunque se puede usar un certificado comodín como *.contoso.com, para resolver este problema, muchos clientes se sienten incómodos por los riesgos de tener un Certificado que puede ser usado para cualquier sub-dominio.

Una alternativa más segura es la de incluir cada uno de los dominios requeridos como SAN (Subject Alternative Name o Nombre Alternativo del Sujeto) en el certificado.

Por defecto , esta opción es usada cuando las peticiones de Certificados son hechas desde Exchange.

- Práctica #3 : Usar el Wizard para Certificados de Exchange 2010 para generar la petición de Certificados

Exchange tiene varios servicios que usan Certificados. Un error muy común, es el de generar la petición de Certificados, sin los nombres o la configuración correcta.

El wizard para Certificados en la consola de Exchange, te ayuda a incluir la lista correcta de nombres en la petición del Certificado, así como qué servicios serán utilizados con el Certificado, y basado en los servicios seleccionados, el wizard incluye los nombres que el Certificado debe tener para que pueda ser usado por esos servicios.

clip_image002[1]

Usando el Wizard de Certificados allí puedes definir “Host names” que serán usados por los diferentes servicios en tu organización. Por ejemplo aquí estamos definiendo nombres internos y externos para Outlook Web App y Exchange ActiveSync.

clip_image002[3]

- Práctica #4 : Usa los menos “Host Names” que sea posible

Los “Host Names” que debes incluir en tu Certificado de Exchange , son los “Host Names” usados por los cliente para conectarse a Exchange.

Uno de los pasos más importantes cuando se hace el requerimiento para un certificado es reducir el número de nombres “host” en el certificado. Para reducir la complexidad y el manejo del certificado y además no incluir nombres internos de los servidores en el certificado (Netbios o FQDN’s)

El siguiente ejemplo los explica:

Nombre de la Organización: Contoso :

Mail.contoso.com

Este “Host Name” cubre la mayoría de las conexiones a Exchange , incluyendo Microsoft Office Outlook, Outlook Web App, Outlook Anywhere, Offline Address Book, Exchange Web Services, POP3, IMAP4, SMTP, Exchange Control Panel, y ActiveSync.

Autodiscover.contoso.com

Este “Host Name” es usado por clientes que soportan Autodiscover , incluyendo Microsoft Office Outlook 2007 y versiones más recientes , Exchange ActiveSync, y clientes de Exchange Web Services .

Legacy.contoso.com

Este “Host Name” es requerido cuando hay coexistencia con Exchange 2003 o Exchange 2007.

Si tienes clientes con buzones tanto como en una version anterior de Exchange y Exchange 2010 , al configurar este “Host Name” , ayuda a que los usuarios no tengan que aprenderse una segunda URL durante el proceso de actualización de versiones.

 

Para mas información visite los siguientes articulos: