Recomendaciones sobre el uso de certificados digitales para acceso cliente – Parte 2| Exchange Server 2013

En el artículo previo, hicimos una introducción a los certificados digitales viendo su definición, los diferentes tipos que existen y el uso que le da a ellos Exchange Server.

En esta parte, analizaremos las recomendaciones y mejores prácticas para la implementación del certificado digital en Exchange.

Prácticas recomendadas

Utilizar certificados digitales de terceros

Con el objetivo de evitar los carteles de advertencia en dispositivos móviles, equipos fuera de nuestro dominio de Active Directory y cualquier error que pueda generarse por problemas de confianza con la Root de nuestra infraestructura PKI, se recomienda utilizar certificados de terceros los cuales como indicamos en el artículo previo, están distribuidas sus Root en todos o la mayoría de los equipos y dispositivos móviles que salen de fábrica.

Usar certificados del tipo SAN

Exchange utiliza diversos nombres DNS los cuales dan soporte a la infraestructura de correo, tanto sea para el acceso cliente, el autodescubrimiento y las plataformas de coexistencia durante el proceso de migración. Es por eso que se utilizan certificado SAN (también llamados multidominios), siendo estos capaces de soportar múltiples dominios o nombres alternativos. Si bien esto puede remediar se mediante la utilización de un certificado wilcard, donde por ejemplo se utiliza el dominio *nicolasgranata.com, esto puede tener implicancias de seguridad que no son deseadas por ciertas empresas como la utilización de cualquier subdominio para ofrecer un determinando servicio (Al margen de que son más costosos).

Utilizar la menor cantidad de nombres posibles

Si bien este punto va a depender de la cantidad de dominios SMTP primarios que soportemos en nuestra plataforma de Exchange, se recomienda utilizar la menor cantidad de nombres DNS posibles.

Esto permite ahorrar dinero en la compra de certificados digitales SAN y también simplificar nuestra implementación, evitando utilizar nombres de servidores internos en los certificados, lo cual no es una práctica recomendada.

En efecto, los 3 nombres DNS típicos de una organización que deberíamos usar son los siguientes:

  • mail.nicolagranata.com: utilizado para cubrir todas las conexiones hacia Exchange, por ejemplo OWA, Active Sync, IMAP, POP, Exchange Web Service, Exchange Admin Center o Control Panel, OAB, etc.
  • autodiscover.nicolasgranata.com: utilizado para soportar el servicio de auto descubrimiento de los clientes Outlook mediante Outlook Anywhere, Exchange Web Servicies y Active Sync.
  • legacy.nicolasgranata.com: requerido como URL adicional en migraciones de Exchange 2007 a 2010 y Exchange 2007 a 2013. Por lo que solo se utilizaría en ambientes de coexistencia.

En base a este acercamiento, se deben configurar las URLs tanto internas como externas de los directorios virtuales de Exchange con los mismos nombres.

Ahora entramos en un ambiente de muchas empresas:

El dominio que utilizan para Active Directory es interno, no puede ser resuelto en forma externa por ningún servidor de nombres, por ejemplo nicolasgranata.local, y el dominio público que utilizan como SMTP primario y URLs de Exchange Server no pueden ser resultas en forma interna y son reenviadas hacia los servidores de nombres DNS externos.

Para ambos escenarios existe una solución recomendada, la cual nos permite utilizar certificados digitales de terceros manteniendo las mejores prácticas.

Esta solución se denomina SPLIT DNS.

Split DNS y SSL

La técnica de SPLIT DNS, nos permite configurar diversas direcciones IP para un mismo nombre de host que responden dependiendo de donde provenga la petición.

Esto nos brinda la posibilidad de reducir la cantidad de nombres DNS a utilizar en el certificado digital para la configuración de Exchange, haciendo más simple la implementación y menos costoso el certificado.

Imaginemos el siguiente escenario:

  • 1 servidor Exchange Server 2013 multirol con IP 192.168.0.45
  • 1 implementación de Active Directory Domain Services, la cual aloja el servidor de Exchange.
  • El nombre FQDN de Active Directory es nicolasgranata.local
  • Las URL de acceso cliente de Exchange apuntan en forma externa a:
    • mail.nicolasgranata.com –> 10.0.0.31 (Imaginemos que es una IP pública)
    • autodiscover.nicolasgranata.com –> cname que apunta a mail.nicolasgranata.com

En forma interna, el controlador de dominio el cual también debe ser servidor DNS tiene creada dos zonas autoritativas:

  • nicolasgranata.local: utilizada para la resolución de nombres DNS de Active Directory.
  • nicolasgranata.com: utilizada para la resolución de los registros externos de dicho dominio.

En la zona nicolasgranata.com creada en Active Directory, tenemos cargados todos los registros públicos pero apuntados a las IP internas de los servidores que están en mi red y brindan servicio, como puede ser un IIS con una web institucional o el servidor Exchange. A su vez debo cargar todos los nombres de host de la zona con su correspondiente IP publica, para los servicios no tenga los servicios en mi red pero que requieran ser resueltos en forma interna.

Por ejemplo:

  • mail.nicolasgranata.com –> 192.168.0.45
  • autodiscover.nicolasgranata.com –> 192.168.0.45

Un equipo externo que quiera conectarse a OWA, resolverá la IP publica 10.0.0.31 para el nombre de host mail.nicolasgranata.com, en cambio uno conectado a la red del dominio de Active Directory, resolverá la IP interna 192.168.0.45.

En este sentido, podemos observar como configuramos dos IP para el mismo nombre de host, brindando simplicidad a la implementación, reduciendo costos de certificado digital ya que solo utilizamos dos nombres de host y manteniendo las prácticas recomendadas.

Generar el certificado desde el panel de administración de Exchange

Es recomendado generar el request o petición del certificado digital desde el panel de administración de Exchange, con el objetivo de no olvidarnos de agregar ningún nombre para los servicios de Exchange ya que el asistente nos guiara a través de la creación del mismo de forma intuitiva y fácil.

Conclusión

En este artículo y el previo, vimos los conceptos de certificado digital, para que se utilizan y prácticas recomendadas las cuales nos permitirán simplificar infraestructuras, ahorrar dinero y evitar los posibles problemas causados por los certificados digitales, sobre todo en la conexión de dispositivos móviles.

¡Saludos!

Advertisements

One thought on “Recomendaciones sobre el uso de certificados digitales para acceso cliente – Parte 2| Exchange Server 2013

Add yours

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: