Qué nombres debo tener en un certificado de Exchange 2010?

La respuesta es como en muchas otras ocasiones, “depende”.

Depende de si tengo múltiples sitios con Exchange, de la cantidad de dominios SMTP que soporte y si existen usuarios utilizando SMTP primarios de estos distintos dominios. Adicionalmente esto puede variar en función al mecanismo utilizado para el servicio de Autodiscover.

Si tengo varios servidores con el rol de CAS voy a querer incluir en el certificado el nombre “balanceadoque redireccione el tráfico HTTPS, POP o IMAP a uno u otro (sea por utilizar Round Robin con DNS o una VIP si utilizo NLB, HLB o similar).

Este caso se da usualmente cuando requiero alta disponibilidad. Incluso con un único servidor esto sería una buena práctica. /* En este caso VIP hace referencia a una dirección IP virtual, NLB a balancear la carga mediante el servicio de Windows Load Balancing y HLB a balanceador por hardware, usualmente este último costoso para pequeñas o mediana empresas. En adición existen virtual appliances a un costo muy accesible*/

A continuación vamos a ver algunos de los escenarios más comunes.


Escenario A (no recomendado)

Organización con un único servidor de Exchange con los roles de una instalación típica

Datos:

  • FQDN de la zona DNS del dominio interno: contoso.local
  • FQDN de la zona DNS externa: contoso.com
  • FQDN del servidor: mail01.contoso.local
  • URL externa de autodiscover: autodiscover.contoso.com
  • URL de servicios web (externo): Webmail.contoso.com
  • URL de servicios web (interno): Mail01.contoso.local
  • Dominio SMTP primario de los usuarios: contoso.com

Nombres a incluir en el certificado:

  • Webmail.contoso.com
  • Autodiscover.contoso.com
  • Mail01.contoso.local      

Si bien este escenario es bastante común en pequeñas empresas, se debe tener en cuenta que no es recomendado utilizar nombres internos en un certificado público, de hecho en un tiempo esto ya no se podrá hacer. Una de las alternativas podría ser utilizar un Split DNS o múltiples certificados, uno emitido por una CA interna y para los nombres accesibles desde internet otro por una CA externa. Hay que tener en cuenta que a mayor cantidad de certificados, mayor cantidad de sitios web, mayor complejidad de administración,etc.

Actualización 1/2015: Al momento de escribir este artículo, el escenario A era no recomendado pero posible. Actualmente ya no se pueden solicitar certificados públicos con nombres internos. La alternativa podría ser crear múltiples sitios web; 1 orientado a clientes internos incluyendo el certificado con los nombres internos y otro con el certificado público. Dependiendo del producto utilizado para publicar los servicios de Exchange pueden haber otras opciones, de cualquier modo el escenario donde se utilizan nombres internos no es recomendado.

Adicionalmente no se recomienda utilizar los mismos FQDNs para el servidor de acceso de clientes RPC (RPC Client Access) y los servicios web (en este caso mail01.contoso.local). Entre otras cosas esto puede derivar en problemas al migrar a Exchange 2013.

About Daniel Núñez Banega

Consultor IT especializado en Microsoft Exchange, Active Directory y Microsoft 365.
Principales Certificaciones: Microsoft Certified Trainer | Microsoft Certified Solutions Expert | Microsoft Certified Systems Engineer | Microsoft Certified Systems Administrator | Microsoft Certified IT Professional | Microsoft Certified Technology Specialist | Microsoft 365 Certified: Enterprise Administrator Expert | Microsoft 365 Certified: Security Administrator Associate | Microsoft Certified: Cybersecurity Architect Expert | Comptia Pentest+ | EC-Council Certified Ethical Hacker Master

Reader Interactions

Comments

  1. Joan Garcia says

    Hola, en el caso de tener varios certificados, uno emitido por el servidor local y otro emitido para las conexiones externas de owa, que roles debemos asignar a cada certificado? Muchas gracias

    • Aprendiendo Exchange says

      Hola Joan, el tema es que podemos usar 1 certificado por sitio web. Para utilizar 2 certificados; 1 emitido por una CA interna y otro por una entidad externa, es necesario crear un sitio adicional y configurar la publicación externa para que vaya al sitio con el certificado externo asociado y los registros DNS internos para que vayan al sitio con el certificado interno.

      Lo ideal sería no utilizar nombres internos, utilizar un único sitio web y configurar el DNS interno para que resuelva el nombre «externo» (internamente) a la IP privada del servidor. Esto se puede hacer utilizando un split DNS o pinpoint DNS.

      saludos!
      daniel

  2. rafael rondon says

    hola, tengo un problema ya que tengo trabajando perfectamente OWA, ACTIVE SYNC
    todos con un mismo certificado emitido localmente, intento configurar outlook anywhere y no funciona ni interno ni externo, internamente queda pidiendo usuario y clave y no autentifica, externamente con autodiscover pide usuario y clave y el TMG da el sigueinte error 12309 The server requires authorization to fulfill the request. Access to the Web server is denied. Contact the server administrator, usando la configuracion manul el TMG no toma la regla y la conexion es cerrada

    muchas gracias por adelantado

  3. Victor Vivas says

    Buenos Días, en el caso de que el cliente outlook, muestre una alerta en de certificado en reiteradas ocasiones, debido a que el nombre del servidor no esta incluido, ya que es es un dominio .local, podría crear un certificado interno solo a ese rol? ya configure un DNS SPLIT y el OWA trabaja sin inconvenientes, el certificado esta firmado por un tercero.

    Muchas Gracias de antemano
    Saludos

  4. salvador de la fuente says

    hola daniel

    he cargado un certificado publico para mi servidor «mail.publico.com» y mis usuarios fuera de la empresa todo bien, pero mis usuarios locales al abrir outlook les aparece el mensaje: el nombre del certificado seguridad no es valido o no coincide con el nombre del sitio y hace referencia al nombre del servidor «Exchange2016.local» pincho ver certificado y muestra el certificado emitido para el dominio publico

    hay alguna manera de emitir un certificado para los usuarios locales ?, emití un nuevo certificado con la ca. interna pero al momento de asignarle iss soluciona mi problema interno pero ahora aparece error en los usuarios externos, por lo cual mantengo el iss en el certificado publico que es el que mas usuarios concurren

  5. Hugo says

    Hola Daniel, he adquirido el certificado «UCC SSL estándar hasta 5» para renovar en exchange server 2010, pero aun está pendiente la verificación del código hacia el autodiscover y demás, que es lo que tengo que hacer con el código que que me aparece al lado del autodiscover en la la web de goddady ? en donde tengo que validarlo para que la petición sea exitosa ? Gracias de antemano.

    • Daniel Núñez Banega says

      Hola Hugo, no me queda claro el código al que haces referencia pero en el sitio del proveedor te indica las distintas formas de verificar la propiedad del dominio. Esto puede ser mediante correo entre otros mecanismos que dependen del proveedor. Saludos

  6. Pablo says

    Hola Hugo, a ver si me puedes ayudar, tenemos un servidor Exchange 2010 donde tenemos 4 dominios de correo en el servidor y queremos solicitar un certificado público para que se pueda realizar la configuración del correo en los nuevos terminales móviles donde ya no deja certificados autofirmados como puede ser en los últimos iphone. No tengo claro que tipo de certificado tengo que solicitar y con que nombres para realizar el archivo CSR, me refiero a que tendré que solicitar el ceritificado para los nombres mail.dominio1.com, mail.dominio2.com, mail. dominio3.com y mail.dominio3.com, lo que no tengo claro es si también tengo que solicitar los autodiscover.dominio1.com, autodiscover.dominio2.com, autodiscover.dominio3.com, autodiscover.dominio4.com, tampoco si tendría que añadir el acceso owa, ese acceso es común para todos los dominios. Como puedes ver no lo tengo muy claro. Muchas gracias!!

  7. Pablo says

    Hola Daniel, perdona, que en la pregunta anterior te llamé Hugo, lo siento :-(, acaba de leer la respuesta que le dabas a Hugo y me he liado.

    • Daniel Núñez Banega says

      Hola Pablo, recién veo lo de Hugo :).
      Respecto a tu consulta, para la configuración automática de dispositivos lo que se necesita es definir el mecanismo a utilizar para autodiscover, el resto de los nombres son opcionales (mail.dominio1.com, mail.dominio2.com), salvo que quieras que cada usuario de un dominio de correo tenga una URL específica de acceso a por ejemplo OWA o incluso para configuración manual de Autodiscover.

      El tema es extenso como para darte una respuesta definitiva ya que depende de la configuración que tengas en la organización y de los requerimientos específicos, te dejo algunos artículos del sitio donde se ve en más profundidad:
      https://aprendiendoexchange.com/outlook-el-nombre-del-certificado-de-seguridad-no-es-valido
      https://aprendiendoexchange.com/7-errores-trabajando-con-exchange
      https://aprendiendoexchange.com/certificados-en-exchange-2013
      https://aprendiendoexchange.com/split-dns-con-exchange

      • Pablo says

        Muchas gracias Daniel, la verdad es que es complicado, después de leer toda la documentación que me has facilitado, finalmente he solicitado un SSL-Multidominio SAN con los dominios mail.domino, con los autodiscocer.dominio y con el owa que es común para todos los dominios de correo, la duda estaba entre SSL-Multidomino o Wildcard. A ver si finalmente acierto… ese mucha diferencia de precio.

        • Daniel Núñez Banega says

          Excelente Pablo, respecto al tema de usar certificado de tipo wildcard o multidominio va a depender entre otras cosas si todos los nombres que pensabas incluir se encuentran dentro de un mismo dominio o si usas varios diferentes. Por lo que contabas en el comentario anterior entiendo que la opción sería multidominio.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *