☰

el nombre del certificado de seguridad no es válido o no coincide con el nombre del sitio

tag-icon • tag-icon ssl exchange-2013
el nombre del certificado de seguridad no es válido o no coincide con el nombre del sitio

Nuestro servidor Exchange ha estado funcionando con un certificado firmado internamente durante un tiempo. Hoy compré un certificado SSL confiable (wilcard) y lo instalé en el servidor.

El certificado se emite a *.example.no y no ofrece excepciones de seguridad cuando accedo a la interfaz web https://mail.example.no/owadesde el navegador web.

Ahora, cuando abro Outlook aparece este error de validación de certificado. Probé todas las soluciones estándar proporcionadas, que principalmente implicaban establecer la URL externa como URL interna.

  • FQDN interno:mx.example.local
  • FQDN externo:mail.example.no
  • Mensaje de error: Hay un problema con el certificado de seguridad del servidor proxy. El nombre del certificado de seguridad no es válido o no coincide con el nombre del sitio de destino mx.example.local. Outlook no puede conectarse al servidor proxy. (Código de error 10)

Lo que hice:

Set-WebServicesVirtualDirectory –Identity ‘mx\EWS (Default Web Site)’ –ExternalUrl https://mail.example.no/ews/exchange.asmx

Set-WebServicesVirtualDirectory -Identity "mx\EWS (Default Web Site)" –InternalUrl https://mail.example.no/EWS/Exchange.asmx

Set-OABVirtualDirectory -Identity “mx\OAB (Default Web Site)” -InternalURL https://mail.example.no/OAB

Set-ActiveSyncVirtualDirectory -Identity “mx\Microsoft-Server-ActiveSync (Default Web Site)” -InternalURL https://mail.example.no/Microsoft-Server-Activesync

Set-ClientAccessServer -Identity mx -AutodiscoverServiceInternalUri https://mail.example.no/autodiscover/autodiscover.xml

El resultado:

[PS] C:\>Get-WebServicesVirtualDirectory | Select InternalUrl, BasicAuthentication, ExternalUrl, Identity | Format-List

InternalUrl         : https://mail.example.no/ews/exchange.asmx
BasicAuthentication : True
ExternalUrl         : https://mail.example.no/ews/exchange.asmx
Identity            : mx\EWS (Default Web Site)

[PS] C:\>Get-OabVirtualDirectory | Select InternalUrl, ExternalUrl, Identity | Format-List

InternalUrl : https://mail.example.no/oab
ExternalUrl : https://mail.example.no/OAB
Identity    : mx\OAB (Default Web Site)

[PS] C:\>Get-ActiveSyncVirtualDirectory | Select InternalUrl, ExternalUrl, Identity | Format-List

InternalUrl : https://mail.example.no/Microsoft-Server-ActiveSync
ExternalUrl : https://mail.example.no/Microsoft-Server-ActiveSync
Identity    : mx\Microsoft-Server-ActiveSync (Default Web Site)

[PS] C:\>Get-ClientAccessServer | Select Fqdn, AutoDiscoverServiceInternalUri, Identity | Format-List

Fqdn                           : mx.example.local
AutoDiscoverServiceInternalUri : https://mail.example.no/autodiscover/autodiscover.xml
Identity                       : mx

Después de eso tengo

  • Reciclé el grupo de aplicaciones IIS MSExchangeAutoDiscoverAppPool (eso no hizo que el mensaje desapareciera, así que yo...)
  • Reinicié todo el servidor de correo (eso tampoco hizo que el mensaje desapareciera, así que...)
  • Entré en Panel de control -> Correo -> Cuentas de correo electrónico y elegí Reparar en mi cuenta (ya que estoy haciendo esta publicación, habrás adivinado que esto tampoco tuvo ningún efecto)
  • DNS vaciado de la computadora cliente (en caso de que se haya ignorado la URL de detección automática)
  • Reparada la cuenta de correo electrónico una vez más.
  • Intenté editar la cuenta y poner el FQDN público, mail.example.no, como dirección del servidor.
  • EDITAR: Intenté eliminar y volver a crear la cuenta. Se eliminó todo el perfil de correo, las carpetas %AppData%\Local\Outlook y %AppData%\Local\Outlook. Aún no hay éxito.

Me estoy quedando sin ideas ahora... cada sitio que he visitado en la web sugiere que haga lo que acabo de hacer y se espera que el resultado sea igual al mío...

ACTUALIZAR: Uno de mis usuarios ni siquiera puede iniciar sesión en Outlook desde su estación de trabajo. La cuenta está bien (el correo en el teléfono móvil y el cliente web funciona), pero Outlook sigue repitiendo la solicitud de contraseña y no sale del modo sin conexión.

ACTUALIZAR: Hice una verificación SSL en el sitio web de Digicert para ver si el certificado está instalado correctamente. El servidor pasó todas las comprobaciones, lo único que me advirtieron fue el uso del protocolo SSL 3.0: Soporte de protocolo TLS 1.1, TLS 1.0, SSL 3.0. SSL 3.0 es una versión de protocolo obsoleta con vulnerabilidades conocidas.

ACTUALIZACIÓN 150709:

Descargo de responsabilidad: ninguna dirección IP interna real resultó dañada al realizar esta actualización

  • Configuré una nueva zona de búsqueda directa en DNS, mail.example.nocon un registro en blanco (A) que apunta a 192.168.1.1, la dirección IP hipotética del servidor de correo.
  • En la zona de búsqueda inversa para 192.168.1.in-adds.arpa tengo un registro e (PTR) llamado 192.168.1.1 que apunta a mail.example.no
  • DescargadoHerramienta de nombres internos DigiCert® para Microsoft Exchange
  • Ejecuté la herramienta, las direcciones eran en su mayoría correctas, pero OWAVirtualDirectory ECPVirtualDirectory todavía hacía referencia a mx.example.local, así que las cambié a mail.example.no

búsquedanEl resultado parece prometedor:

D:\>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

D:\>nslookup mail.example.no
Server:  dc1.example.local
Address:  192.168.1.2

Name:    mail.example.no
Address:  192.168.1.1


D:\>nslookup 192.168.1.1
Server:  dc.example.local
Address:  192.168.1.2

Name:    mail.example.no
Address:  192.168.1.1

Outlook no.....

Pequeña prueba:

  1. Fui a Configuración de la cuenta -> Más configuraciones -> Conexión -> Configuración de proxy de Exchange.
  2. Cambió la URL de conexión ahttps://mail.example.no
  3. Se cambió el nombre principal permitido amsstd:*.example.no
  4. Outlook reiniciado. El error de certificado no aparece ahora pero noto que no estoy conectado...
  5. Configuración de cuenta una vez más, esta vez elegí Reparación automática
  6. Outlook reiniciado
  7. Ahora, si vuelvo a la configuración de Exchange Proxy, la URL interna ha regresado...

Respuesta1

El certificado del emisor externo deberá tener su FQDN interno como nombre alternativo del sujeto para poder trabajar con su detección automática local a la que los usuarios de LAN que usan Outlook intentan acceder mientras el certificado se encuentra en su IIS o Exchange.

De lo contrario, a los usuarios se les solicitará "No coincide el nombre del certificado SSL" y, en algunos casos, se les pedirá que escriban sus contraseñas una y otra vez.

Respuesta2

Estoy luchando contra este problema exacto. No tengo suficientes puntos para simplemente comentar.

Pero tengo curiosidad: ¿tiene configurado el proveedor de Outlook EXCH CertPrincipalName?

Get-OutlookProvider

Es típico que los certificados comodín necesiten configurar el proveedor EXPR. Pero descubro que es posible que también necesite configurar el proveedor EXCH para clientes RPC.

Set-OutlookProvider EXCH -CertPrincipalName msstd:*.domain.com

información relacionada