Upload
pablodg1980
View
29
Download
0
Embed Size (px)
DESCRIPTION
eBook -- Exchange 2013
Citation preview
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 [email protected] 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