Daniel Núñez BanegaMCSE / MCSA / MCITP / MCTS

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 1

Contenido

Introducción ............................................................................................................................. 2

Selección de tipo de certificado ......................................................................................... 3

Certificado Auto firmado vs Interno vs Público ........................................................... 4

Certificado auto firmado (self signed) ............................................................... 4

Certificado interno .................................................................................................. 4

Certificado Público o externo ............................................................................... 5

Conclusión de tipo de certificado ........................................................................ 7

Flujo de decisión ...................................................................................................................... 8

Configuración de certificados ............................................................................................. 9

Es realmente necesario cambiar el certificado predeterminado? ............. 9

Solicitar un nuevo certificado .......................................................................................... 11

Generar el CSR (Certificate Signing Request) ................................................. 11

Procesar la solicitud con una entidad certificadora .................................... 16

Completar la solicitud pendiente ...................................................................... 18

Habilitar el certificado a nivel de servicios de Exchange ............................ 19

Exportar certificado de Exchange ................................................................................... 21

Importar certificado ............................................................................................................ 22

Mejores prácticas y errores comunes ............................................................................ 24

Errores típicos de configuración ........................................................................ 25

Próximos pasos ...................................................................................................................... 26

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 2

Introducción El tema de certificados en Exchange se encuentra dentro de los que genera

mayor confusión. Hay mucha información sobre este tema particular y en

muchos casos opiniones muy variadas.

El tomar una decisión incorrecta tendría un impacto directo en el usuario,

desde advertencias y errores de certificados1 hasta incluso no poder acceder

al servicio.

En este ebook vamos a ver qué tipo de certificado utilizar y cuáles son las

tareas más comunes en Exchange 2013 incluyendo:

Selección de tipo de certificado

Solicitud de certificado

Instalación y configuración

Exportación

Importación

Recomendaciones

Errores comunes

1 http://aprendiendoexchange.com/outlook-el-nombre-del-certificado-de-seguridad-no-es-valido

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 3

Selección de tipo de

certificado Para asegurar el acceso a los servicios de Exchange podemos utilizar 3 tipos

de certificados:

1. Certificado Auto firmado. Al instalar Exchange 2010 o Exchange 2013

se genera automáticamente un certificado auto firmado (self signed)

habilitado para IIS, POP, IMAP y SMTP. Este certificado incluye los

nombres de host y FQDN del servidor, ej: servidor1,

servidor1.dominio.local

2. Certificado interno. Este certificado es emitido por una CA interna.

Esta CA podría estar integrada con Active Directory (tipo de CA

Enterprise) o puede ser “Stand alone”, es decir no integrada.

3. Certificado público o externo. Este tipo de certificado es el que en

general se recomienda para cualquier servicio expuesto hacia

internet. Para obtener un certificado público es necesario una entidad

certificadora externa como Godaddy, Digicert o Comodo entre otras.

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 4

Certificado Auto firmado vs

Interno vs Público Veamos las características más relevantes de cada caso.

Certificado auto firmado (self signed)

El certificado auto firmado habilita a que de forma predeterminada los

servicios de Exchange sean accedidos de forma segura.

Este certificado cumple con la función básica pero presenta los siguientes

inconvenientes:

1. Los clientes no confían en el certificado. Este certificado fue emitido

por el propio servidor y la evaluación sobre que es o no confiable se

basa en si la entidad que emitió el certificado se encuentra dentro de

las raíces emisoras de confianza del cliente.

2. Dependiendo del tipo de acceso, los clientes en algunos casos podrían

aceptar las advertencias y acceder al servicio mientras que en otros

esto no sería posible.

En organizaciones sin requerimientos específicos de acceso desde Internet,

el administrador podría optar por distribuir la llave pública del certificado y si

bien no sería la mejor opción podría ser suficiente para el acceso interno.

Certificado interno

El certificado interno en primera instancia implica contar con una CA

(Certificate Authority) o instalarla para este propósito.

Utilizar un certificado emitido por una CA interna puede tener varias

ventajas, al menos frente al certificado auto firmado:

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 5

1. Es posible emitir un certificado con nombres específicos, por ejemplo

“mail.dominio.com”, “mail.dominio.local”, etc.

2. Dependiendo de si la CA se encuentra integrada con Active Directory,

los clientes unidos al dominio confiarían de forma predeterminada.

Acá el tema es que pasa con el acceso externo? Específicamente que

sucedería al acceder al correo desde un dispositivo móvil o un equipo no

unido al dominio?

En este caso los usuarios van a encontrarse con errores de certificados.

Para corregir la situación sería necesario acceder al equipo e instalar la raíz

emisora de confianza (CA interna). Como alternativa se le puede indicar al

usuario (si tiene los permisos necesarios) y esto podría funcionar en una

infraestructura chica pero no resultaría escalable. En el caso puntual de

dispositivos móviles dependiendo de la versión podría presentar la opción de

que el usuario acepte confiar directamente en la CA.

Existe la posibilidad de crear múltiples sitios web y de este modo poder

utilizar más de un certificado; en este caso un certificado interno incluyendo

el nombre del servidor y otro utilizando el nombre público por ejemplo

webmail.dominio.com (emitido por una CA externa). En internet pueden

encontrar tutoriales explicando el proceso pero en general esta no es una

práctica recomendada ya que implica mayor complejidad, configuración,

mantenimiento e igualmente requiere un certificado público.

Certificado Público o externo

Dentro de los certificados públicos, existen varios tipos, el que usualmente se

requiere para Exchange es el de tipo SAN (Subject Alternative Names) o UCC

(Unified Communications Certificate), dependiendo el proveedor el nombre

exacto. Este tipo de certificado nos permite utilizar múltiples nombres.

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 6

Adicionalmente están los certificados de tipo wildcard (*), estos habilitan a

utilizar cualquier nombre dentro de un dominio específico (subdominios).

El certificado público a diferencia del auto firmado y del interno tiene un

costo directo al momento de la compra y en función al tipo, cantidad de

nombres y tiempo el precio.

A la fecha de este ebook, el costo por un certificado con 4 nombres en

Digicert2 es de U$S 299 al año, disminuyendo hasta U$S 239 si se compra con

un vencimiento a 3 años, es decir que por un certificado con 4 nombres con

una vigencia de 3 años queda un total aproximado de U$S 719. En el caso de

los escenarios anteriores el cálculo no es tan simple y en general a largo

plazo terminan siendo más costosos a nivel administrativo.

El certificado público es ideal ya que entre otras cosas puede ser utilizado

interna como externamente. Este certificado sería confiable en clientes

internos, externos, dispositivos móviles, etc de forma predeterminada.

A tener en consideración que actualmente no es posible incluir nombres

internos en certificados públicos y si bien no se consideraba una buena

práctica era algo relativamente común de encontrar. Dada esta situación y

considerando que en la configuración de Exchange debemos definir URLs

internas y externas, es necesario un mecanismo que habilite a configurar los

servicios con nombres válidos y que estos puedan ser utilizados desde la red

interna e Internet.

Para cumplir con este requerimiento podemos utilizar Split DNS o PinPoint

DNS3. Este tipo de configuración nos permite utilizar los mismos nombres

interna y externamente resolviendo a una IP privada o pública dependiendo

desde donde consulta el cliente.

2 https://www.digicert.com/es/ssl-tls-comunicaciones-unificadas.htm 3 http://aprendiendoexchange.com/split-dns-con-exchange

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 7

Conclusión de tipo de certificado

El certificado auto firmado nos habilita a contar con una instalación segura

de forma predeterminada, sin embargo el hecho de que no sea confiable y

solo incluya los nombres internos del servidor no lo hacen un candidato ideal

para producción.

El certificado interno puede ser una buena opción si no accedemos desde

internet o no se considera problemático que los usuarios reciban

advertencias sobre seguridad. Claramente esto no es recomendado.

El certificado público cumple con las prácticas recomendadas por Microsoft4:

Es confiable

No incluiría el nombre de los servidores

Mediante split DNS podemos minimizar la cantidad de nombres

Dentro de los certificados públicos se recomienda de tipo SAN/UCC. Los

certificados de tipo wildcard implican un riesgo muchas veces innecesario ya

que habilitan a asegurar cualquier subdominio, de cualquier modo es muy

utilizado y si ya existe uno en la organización, de cumplir con los

requerimientos de diseño puede ser una opción viable.

4 https://technet.microsoft.com/en-us/library/dd351044(v=exchg.150).aspx

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 8

Flujo de decisión

Complementando la información, en el diagrama de flujo se detalla el

proceso de decisión de tipo de certificado en base a requerimientos

puntuales. Si bien la recomendación en general es utilizar un certificado

público pueden haber escenarios específicos donde esto no sea 100%

necesario.

En base a la información presentada y el resultado del flujo evaluar la mejor

opción:

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 9

Configuración de

certificados Como vimos en la primer parte del ebook, con la instalación de Exchange

20135 se genera automáticamente un certificado auto firmado (self signed).

Este certificado se denomina “Microsoft Exchange” y viene habilitado para IIS,

POP, IMAP y SMTP.

Es realmente necesario cambiar el certificado

predeterminado? El tema principal es que como vimos, los clientes no confían en el certificado

y esto deriva en ventanas y carteles molestos alertando sobre la seguridad.

Los errores indicados varían dependiendo del cliente, en caso de Outlook

2013 y OWA encontraríamos los siguientes:

Outlook:

El certificado de seguridad ha sido emitido por una compañia que no es de

confianza. Vea el certificado para determinar si desea que esta entidad

emisora de certificados sea de confianza

The security certificate was issued by a company you have not chosen to

trust. View the certificate to determine whether you want to trust the

certifying authority.

5 http://aprendiendoexchange.com/como-instalar-exchange-2013

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 10

OWA:

There is a problem with this website´s security certificate

Importante: Los errores en relación a confianza también se presentan con

certificados emitidos por algunas CA públicas, por este motivo es

importante seleccionar una CA que sea lo más “confiable” posible en el

sentido de que venga predeterminada en los principales sistemas.

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 11

Solicitar un nuevo certificado

Independientemente del tipo de certificado a utilizar el procedimiento en

Exchange es similar en todos los casos:

1. Generar la solicitud de certificado (CSR) en Exchange

2. Procesar la solicitud con una entidad certificadora interna o externa

3. Completar la solicitud pendiente en Exchange con el archivo devuelto

por la CA

4. Habilitar el certificado para que los servicios de Exchange puedan

utilizarlo

Generar el CSR (Certificate Signing Request)

Para generar la solicitud de certificado utilizando el EAC (Exchange Admin

Center) de Exchange 2013:

1. Ingresar al EAC: “HTTPS://ServidorCAS/ECP”, donde “ServidorCAS” es el

nombre del servidor Exchange 2013 con el rol de CAS)

2. Hacer clic en Servidores y luego Certificados

Nota: El certificado auto firmado con el que interactúan los clientes es el

que se llama Microsoft Exchange. Los otros 2 se recomienda no

modificarlos.

3. Hacer clic en “+” y seleccionar Crear una solicitud para un certificado

desde una entidad de certificación:

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 12

4. Especificar un nombre descriptivo y hacer clic en Siguiente:

5. Si es una solicitud para certificado de tipo comodín (wildcard) activar la

casilla, de lo contrario hacer clic en siguiente:

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 13

6. Hacer clic en Examinar y seleccionar el servidor donde realizar la

solicitud:

7. Seleccionar los servicios en uso y definir los nombres a utilizar en el

certificado. La información que viene auto completada es en base a la

configuración de las propiedades de URL interna, externa de cada uno de

los servicios web (las URLs configuradas son de vital importancia para que

todo funcione según lo esperado):

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 14

Nota: En general conviene utilizar Split DNS 6de tal forma de utilizar los

mismos nombres interna y externamente minimizando la cantidad en el

certificado. De cualquier modo esto depende de cada escenario específico,

hay varios factores que pueden afectar los nombres requeridos.

8. En información de la organización completar cada uno de los campos y

hacer clic en Siguiente:

6 http://aprendiendoexchange.com/split-dns-con-exchange

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 15

9. Especificar una ruta UNC válida para guardar la solicitud. Ej:

\\servidor\temp\cert.req

10. Finalizar el asistente y verificar que la solicitud figure como Pedido

Pendiente:

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 16

A partir de este momento estaríamos en condiciones de enviar la solicitud

sea a una entidad certificadora interna o a una externa.

Procesar la solicitud con una entidad

certificadora En caso de procesar el certificado con una CA interna, continuar el

procedimiento de lo contrario ir directamente al punto siguiente (Completar

la solicitud):

1. Abrir Internet Explorer (u otro navegador) y escribir la URL de la entidad

certificadora: Https://CA/Certsrv

2. En la ventana de bienvenida hacer clic en Request a Certificate y luego en

advanced certificate request

3. Hacer clic en Submit a certificate request by using a base-64-encoded

CMC or PKCS #10 file…

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 17

4. Abrir con el bloc de notas el archivo con extensión REQ y copiamos todo

el texto

5. En la ventana de Submit a Certificate Request, en el cuadro de Saved

Request pegamos el texto del REQ. En Certificate Template seleccionamos

Web Server y hacemos clic en Submit

6. Seleccionar Base 64 encoded y clic en Download certificate

7. Guardar el archivo .CER

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 18

Completar la solicitud pendiente

Con el archivo devuelto por la entidad certificadora procedemos a completar

la solicitud pendiente:

1. Ir al EAC – Servidores – Certificados. Hacer clic en completo (completar

solicitud)

2. En Completar pedido pendiente ingresar la ruta al archivo CER (la

extensión puede variar) utilizando el formato UNC (\\servidor\recurso).

Aceptar para finalizar

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 19

Habilitar el certificado a nivel de servicios de

Exchange Para utilizar el nuevo certificado primero debemos habilitarle servicios:

1. En el EAC – Servidores – Certificados, seleccionamos el certificado y

hacemos clic en Modificar (el icono que parece un lápiz)

2. Seleccionar los servicios que deseamos utilizar. Por ejemplo si los clientes

utilizan únicamente OWA, Outlook Anywhere y Activesync con seleccionar

IIS es suficiente. Guardar los cambios.

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 20

Luego de esto los clientes Outlook no deberían presentar más ventanas

relacionadas a certificados y si vamos por OWA y hacemos clic sobre el

certificado deberíamos ver algo similar a la siguiente imagen:

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 21

Exportar certificado de

Exchange Una vez instalado el certificado para Exchange 2013 y teniendo en cuenta el

tiempo que involucra el proceso de solicitud, especialmente cuando se trata

de una entidad emisora pública es recomendable realizar un respaldo y

almacenarlo en un lugar seguro.

El respaldo de este certificado nos sería de utilidad frente a cualquiera de los

siguientes escenarios:

1. Caso de reinstalación o reconstrucción del servidor

2. Para instalar el mismo certificado en varios servidores balanceados

Por fuera estaría quedando error humano, pero es real y esto nos cubre

frente a cualquier eventualidad por lo que ejecutar este procedimiento nos

puede ahorrar un buen rato a futuro.

Para respaldar el certificado de Exchange debemos exportarlo junto a su

llave privada:

1. Ingresar al EAC de Exchange 2013 (“HTTPS://ServidorCAS/ECP”, donde

“ServidorCAS” es el nombre del servidor Exchange 2013 con el rol de CAS)

2. Ir a Servidores –> Certificados y seleccionar el certificado a exportar.

3. Hacer clic en el icono “…” y hacer clic en Exportar certificado de Exchange

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 22

4. Especificar la ruta donde almacenar el archivo PFX y hacer clic

en Aceptar. La ruta debe ser en formato UNC

(\\Servidor\recurso\archivo.pfx)

Importar certificado

Algunos motivos por los cuales podría necesitar importar un certificado:

1. Instalación de un mismo certificado en múltiples servidores (por ejemplo,

servidores balanceados)

2. Restauración de certificado

Para importar un certificado en Exchange 2013:

1. Ingresar al EAC de Exchange 2013 (“HTTPS://ServidorCAS/ECP”, donde

“ServidorCAS” es el nombre del servidor Exchange 2013 con el rol de CAS)

2. Ir a Servidores –> Certificados

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 23

3. Hacer clic en el icono “…” y hacer clic en Importar certificado de Exchange

4. Especificar la ubicación del PFX previamente exportado. Se debe utilizar

ruta en formato UNC (\\servidor\recurso\archivo.pfx)

5. Seleccionar el servidor al cual importar el certificado y clic en Finalizar

Por último habilitar los servicios que correspondan al certificado.

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 24

Mejores prácticas y errores

comunes

Recapitulo las prácticas recomendadas más relevantes:

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.

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 qué servicio está 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 utilizar un espacio de

nombre unificado.

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

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 25

Errores típicos de configuración

A continuación algunos errores típicos a nivel de configuración:

1. Dejar los servicios con las URLs internas predeterminadas. 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 debería ser 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 por lo que dejo en pie de

página el enlace al White paper7 de Microsoft (si bien fue hecho para

Exchange 2010 los conceptos aplican a 2013).

7 http://technet.microsoft.com/en-us/library/jj591328(v=exchg.141).aspx

© 2 0 1 5 T o d o s l o s d e r e c h o s r e s e r v a d o s P á g i n a | 26

Próximos pasos

Por último dejo un link a un artículo dedicado a la resolución de errores de

certificados en Outlook, en este post se incluye un diagrama de flujo para

resolución de problemas comunes incluyendo errores de confianza y de

nombres entre otros:

http://aprendiendoexchange.com/outlook-el-nombre-del-certificado-de-

seguridad-no-es-valido

Ahora, si te gusto el ebook quisiera que hagas lo siguiente:

1. Enviarme un mail a admin@aprendiendoexchange.com contándome

2. Compartir el siguiente enlace al menos con un colega:

http://aprendiendoexchange.com/guia-certificados-exchange-2013

3. Dejar un comentario en la página principal del ebook:

http://aprendiendoexchange.com/guia-certificados-exchange-2013