El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Mobile & Remote Access (MRA) es una solución de implementación para la capacidad Jabber de red privada virtual (VPN). Esta solución permite a los usuarios finales conectarse a recursos empresariales internos desde cualquier lugar del mundo. Esta guía se ha escrito para ofrecer a los ingenieros que solucionan problemas de la solución Collaboration Edge la capacidad de identificar y resolver rápidamente los problemas más comunes a los que se enfrentan los clientes durante la frase de implementación.
Cisco recomienda que tenga conocimiento sobre estos temas:
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
Este síntoma puede ser causado por una amplia gama de problemas, algunos de los cuales se describen aquí.
Para que un cliente Jabber pueda iniciar sesión correctamente con MRA, se debe crear un registro SRV de la frontera de colaboración específico y se debe tener acceso a él externamente. Cuando se inicia un cliente Jabber inicialmente, realiza consultas DNS SRV:
Si el cliente Jabber se inicia y no recibe una respuesta SRV para _cisco-uds y _cuplogin y recibe una respuesta para _collab-edge, utiliza esta respuesta para intentar ponerse en contacto con Expressway-E enumerado en la respuesta SRV.
El registro SRV _collab-edge debe indicar el nombre de dominio completamente calificado (FQDN) de Expressway-E con el puerto 8443. Si el SRV _collab-edge no se crea, o no está disponible externamente, o si está disponible, pero el puerto 8443 no es accesible, entonces el cliente Jabber no puede iniciar sesión.
Puede confirmar si el registro SRV_de borde de Collaboration es resoluble y el puerto TCP 8443 se puede alcanzar mediante el verificador SRV en Collaboration Solutions Analyzer (CSA).
Si el puerto 8443 no es accesible, esto podría deberse a un dispositivo de seguridad (Firewall) que bloquea el puerto o a una configuración incorrecta de la puerta de enlace predeterminada (GW) o de las rutas estáticas en Exp-E.
Después de que el cliente Jabber haya recibido una respuesta para _collab-edge, se pone en contacto con Expressway con Transport Layer Security (TLS) a través del puerto 8443 para intentar recuperar el certificado de Expressway para configurar TLS para la comunicación entre el cliente Jabber y Expressway.
Si Expressway no tiene un certificado firmado válido que contenga el FQDN o el dominio de Expressway, esto falla y el cliente Jabber no puede iniciar sesión.
Si se produce este problema, el cliente debe utilizar la herramienta Solicitud de firma de certificados (CSR) en Expressway, que incluye automáticamente el FQDN de Expressway como nombre alternativo del sujeto (SAN).
Nota: MRA requiere una comunicación segura entre Expressway-C y Expressway-E, y entre Expressway-E y los terminales externos.
La siguiente tabla con los requisitos de certificado de Expressway por función se puede encontrar en la Guía de implementación de MRA:
Después de que el cliente Jabber establezca correctamente una conexión segura con Expressway-E, solicita su configuración de borde (get_edge_config). Esta configuración de borde contiene los registros SRV para _cuplogin y _cisco-uds. Si los registros SRV _cisco-uds no se devuelven en la configuración de borde, el cliente Jabber no puede continuar con el inicio de sesión.
Para corregir esto, asegúrese de que Expressway-C cree registros SRV _cisco-uds internamente y pueda resolverlos.
Puede encontrar más información sobre los registros DNS SRV en la Guía de implementación de MRA para X8.11.
Este es también un síntoma común si se encuentra en un dominio dual. Si se ejecuta en un dominio doble y encuentra que el cliente Jabber no está siendo devuelto ningún servicio de datos de usuario (UDS), debe confirmar que los registros SRV _cisco-uds se crean en el DNS interno con el dominio externo.
Nota: Después de la versión X12.5 de Expressway, ya no es necesario agregar un registro SRV _cisco-UDS al DNS interno. Para obtener más información sobre esta mejora, consulte la Guía de implementación de acceso remoto y móvil a través de Cisco Expressway (X12.5).
Si el controlador de interfaz de red (NIC) de Expressway-E está configurado incorrectamente, esto puede hacer que el servidor de la plataforma de comunicaciones extensible (XCP) no se actualice. Si Expressway-E cumple estos criterios, probablemente se encuentre con este problema:
Para corregir este problema, cambie la opción Use Dual Network Interfaces a No.
La razón por la que esto es un problema es que Expressway-E escucha la sesión XCP en la interfaz de red incorrecta, lo que hace que la conexión falle/se agote el tiempo de espera. Expressway-E escucha en el puerto TCP 7400 para la sesión XCP. Puede verificar esto si utiliza el netstat
desde el VCS como root.
Si el nombre de host/dominio del servidor Expressway-E en la configuración de la página DNS no coincide con lo recibido en la respuesta SRV _collab-edge, el cliente Jabber no puede comunicarse con Expressway-E. El cliente Jabber utiliza el elemento xmppEdgeServer/Address en la respuesta get_edge_config para establecer la conexión XMPP a Expressway-E.
Este es un ejemplo de cómo se ve xmppEdgeServer/Address en la respuesta get_edge_config de Expressway-E al cliente Jabber:
<xmppEdgeServer>
<server>
<address>examplelab-vcse1.example.com</address>
<tlsPort>5222</tlsPort>
</server>
</xmppEdgeServer>
Para evitar esto, asegúrese de que el registro _collab-edge SRV coincida con el nombre de host/nombre de dominio de Expressway-E. Para esto se ha registrado el Id. de error de Cisco CSCuo83458 y se agregó soporte parcial en el Id. de error de Cisco CSCuo82526.
Los registros de Jabber para Windows muestran lo siguiente:
2014-11-22 19:55:39,122 INFO [0x00002808] [very\WebexCasLookupDirectorImpl.cpp(134)]
[service-discovery] [WebexCasLookupDirectorImpl::makeCasLookupWhenNetworkIs
Available] - makeCasLookupForDomain result is 'Code: IS_WEBEX_CUSTOMER; Server:
http://loginp.webexconnect.com;
Url: http://loginp.webexconnect.com/cas/FederatedSSO?org=example.com';;;.2014-11-22
19:55:39,122 INFO [0x00002808] [overy\WebexCasLookupDirectorImpl.cpp(67)]
[service-discovery] [WebexCasLookupDirectorImpl::determineIsWebexCustomer] -
Discovered Webex Result from server. Returning server result.2014-11-22 19:55:39,122
DEBUG [0x00002808] [ery\WebexCasLookupUrlConfigImpl.cpp(102)]
[service-discovery] [WebexCasLookupUrlConfigImpl::setLastCasUrl] - setting last_cas_
lookup_url : http://loginp.webexconnect.com/cas/FederatedSSO?org=example.com2014-11-22
19:55:39,123 DEBUG [0x00002808] [pters\config\ConfigStoreManager.cpp(286)]
[ConfigStoreManager] [ConfigStoreManager::storeValue] - key : [last_cas_lookup_url]
value : [http://loginp.webexconnect.com/cas/FederatedSSO?org=example.com]2014-11-22
19:55:39,123 DEBUG [0x00002808] [common\processing\TaskDispatcher.cpp(29)]
[TaskDispatcher] [Processing::TaskDispatcher::enqueue] - Enqueue ConfigStore::persist
Values - Queue Size: 02014-11-22 19:55:39,123 DEBUG [0x00002808] [pters\config\ConfigStore
Manager.cpp(140)]
[ConfigStoreManager] [ConfigStoreManager::getValue] - key : [last_cas_lookup_url]
skipLocal : [0] value: [http://loginp.webexconnect.com/cas/FederatedSSO?org=example.com]
success: [true] configStoreName: [LocalFileConfigStore]
Los intentos de inicio de sesión se dirigen a WebEx Connect.
Para obtener una resolución permanente, debe ponerse en contacto con WebEx para que el sitio se cierre.
Solución Aternativa
A corto plazo, puede utilizar una de estas opciones para excluirla de la búsqueda.
<?xml version="1.0" encoding="utf-8"?>
<config version="1.0">
<Policies>
<ServiceDiscoveryExcludedServices>WEBEX<
/ServiceDiscoveryExcludedServices>
</Policies>
</config>
msiexec.exe /i CiscoJabberSetup.msi /quiet CLEAR=1 AUTHENTICATOR=CUP EXCLUDED_SERVICES=WEBEX
Nota: La segunda opción no funciona para los dispositivos móviles.
ciscojabber://provision?ServiceDiscoveryExcludedServices=WEBEX
Puede encontrar más detalles sobre la detección de servicios de UC y cómo excluir algunos servicios en Implementación in situ para Cisco Jabber 12.8.
Si desplaza a Status > Unified Communications y ve el mensaje de error, "Configured but with errors. Provisioning server: Waiting for traversal server info."
para los registros de Unified CM y el servicio IM&P, los servidores DNS internos configurados en Expressway-C tienen dos registros A DNS para Expressway-E. La razón detrás de varios registros DNS A para Expressway-E podría ser que el usuario afectado se mudara de una sola NIC con NAT estática habilitada en Expressway-E a una NIC dual con NAT estática activada, o viceversa, y se olvidó de eliminar el registro DNS A apropiado en los servidores DNS internos. Por lo tanto, cuando utilice la utilidad de búsqueda de DNS en Expressway-C y resuelva el FQDN de Expressway-E, observará dos registros A de DNS.
Solución
Si la NIC de Expressway-E está configurada para una sola NIC con NAT estática:
ipconfig /flushdns
).Si la NIC de Expressway-E está configurada para NIC dual con NAT estática habilitada:
ipconfig /flushdns
).El cliente puede utilizar Microsoft DirectAccess en el mismo equipo que el cliente Jabber. Cuando intenta iniciar sesión de forma remota, esto puede interrumpir el MRA. DirectAccess obligará a las consultas DNS a tunelizarse en la red interna como si el PC estuviera utilizando una VPN.
Nota: Jabber sobre MRA no admite Microsoft DirectAccess. Cualquier solución de problemas es el mejor esfuerzo. La configuración de DirectAccess es responsabilidad del administrador de la red.
Algunos clientes han tenido éxito al bloquear todos los registros DNS en la tabla de directivas de resolución de nombres de Microsoft DirectAccess. DirectAccess no debe procesar estos registros (Jabber debe poder resolverlos a través de DNS público cuando utiliza MRA):
A partir de la versión X8.8, Expressway/VCS requiere la creación de entradas DNS inversas y de reenvío para ExpE, ExpC y todos los nodos CUCM.
Para conocer todos los requisitos, vea Prerrequisitos y Dependencias de Software en las Notas de Versión x8.8 y Registros DNS para Acceso Remoto y Móvil.
Si no hay registros DNS internos, es posible que vea un error en los registros de Expressway que hacen referencia a reverseDNSLookup:
2016-07-30T13:58:11.102-06:00 hostname XCP_JABBERD[20026]: UTCTime="2016-07-30 19:58:11,102" ThreadID="139882696623872" Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:409" Detail="caught exception: exception in reverseDNSLookup: reverse DNS lookup failed for address=x.x.x.x"
Expressway-C sólo debe recibir un FQDN al consultar el registro PTR para la IP de Expressway-E. Si recibe un FQDN incorrecto de DNS, mostrará esta línea en los registros y fallará:
2020-04-03T17:48:43.685-04:00 hostname XCP_JABBERD[10043]: UTCTime="2020-04-03 21:48:43,685" ThreadID="140028119959296" Module="Jabber" Level="WARN " CodeLocation="cvsservice.cpp:601" Detail="Certificate verification failed for host=xx.xx.xx.xx, additional info: Invalid Hostname host.example.com"
Un registro de diagnóstico de Expressway-C muestra un SIP/2.0 405 Method Not Allowed
mensaje en respuesta a la solicitud de registro enviada por el cliente Jabber. Esto probablemente se deba a un enlace troncal existente del protocolo de inicio de sesión (SIP) entre Expressway-C y CUCM mediante el puerto 5060/5061.
SIP/2.0 405 Method Not Allowed
Via: SIP/2.0/TCP 10.10.40.108:5060;egress-zone=CollabZone;branch=z9hG4bK81e7f5f1c1
ab5450c0b406c91fcbdf181249.81ba6621f0f43eb4f9c0dc0db83fb291;proxy-call-id=da9e25aa-
80de-4523-b9bc-be31ee1328ce;rport,SIP/2.0/TLS 10.10.200.68:7001;egress-zone=Traversal
Zone;branch=z9hG4bK55fc42260aa6a2e3741919177aa84141920.a504aa862a5e99ae796914e85d35
27fe;proxy-call-id=6e43b657-d409-489c-9064-3787fc4919b8;received=10.10.200.68;rport=
7001;ingress-zone=TraversalZone,SIP/2.0/TLS
192.168.1.162:50784;branch=z9hG4bK3a04bdf3;received=172.18.105.10;rport=50784;
ingress-zone=CollaborationEdgeZone
From: <sip:5151@collabzone>;tag=cb5c78b12b4401ec236e1642-1077593a
To: <sip:5151@collabzone>;tag=981335114
Date: Mon, 19 Jan 2015 21:47:08 GMT
Call-ID: cb5c78b1-2b4401d7-26010f99-0fa7194d@192.168.1.162
Server: Cisco-CUCM10.5
CSeq: 1105 REGISTER
Warning: 399 collabzone "SIP trunk disallows REGISTER"
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
Para corregir este problema, cambie el puerto SIP en el perfil de seguridad del troncal SIP que se aplica al troncal SIP existente configurado en CUCM y la zona vecina de Expressway-C para CUCM a un puerto diferente como 5065. Esto se explica en este video. A continuación se muestra un resumen de la configuración:
CUCM
Expressway-C
"Unknown domain"
Un registro de diagnóstico de Expressway-C muestra Event="Registration Rejected" Reason="Unknown domain"
Service="SIP" Src-ip="XXX.XXX.XXX.XXX" Src-port="51601" Protocol="TCP" AOR="sip:XXX.XXX.XXX.XXX".
Para corregir este problema, verifique estos puntos:
"Idle countdown expired"
Cuando revise los registros de Expressway-E durante el período de tiempo que el cliente Jabber envía en un mensaje REGISTER, es posible que encuentre un Idle countdown expired
como se indica en el fragmento de código aquí.
2015-02-02T19:46:31+01:00 collabedge tvcs: UTCTime="2015-02-02 18:46:31,144"
Module="network.tcp" Level="DEBUG": Src-ip="JabberPubIP" Src-port="4211"
Dst-ip="VCS-E_IP" Dst-port="5061" Detail="TCP Connecting"
2015-02-02T19:46:31+01:00 collabedge tvcs: UTCTime="2015-02-02 18:46:31,144"
Module="network.tcp" Level="DEBUG": Src-ip="JabberPubIP" Src-port="4211" Dst-ip=
"VCS-E_IP" Dst-port="5061" Detail="TCP Connection Established"2015-02-02T19:46:49+01:00
collabedge tvcs: UTCTime="2015-02-02 18:46:49,606"
Module="network.tcp" Level="DEBUG": Src-ip="92.90.21.82" Src-port="4211" Dst-ip=
"VCS-E_IP" Dst-port="5061" Detail="TCP Connection Closed" Reason="Idle
countdown expired"
Este fragmento de código indica que el firewall tiene el puerto 5061 abierto; sin embargo, no hay tráfico de capa de aplicación que se transmita en una cantidad suficiente de tiempo, por lo que la conexión TCP se cierra.
Si se encuentra con esta situación, existe un alto grado de probabilidad de que el firewall frente a Expressway-E tenga activada la función SIP Inspection/Application Layer Gateway (ALG). Para solucionar este problema, debe desactivar esta funcionalidad. Si no está seguro de cómo hacerlo, debe consultar la documentación del producto de su proveedor de firewalls.
Para obtener más información sobre SIP Inspection/ALG, puede consultar el Apéndice 4 de la Guía de Implementación de Configuración de Cisco Expressway-E y Expressway-C-Basic.
Un registro de diagnóstico de Expressway-E muestra una falla de negociación TLS en el puerto 5061, sin embargo, el intercambio de señales SSL se realizó correctamente en el puerto 8443.
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,533" Module="network.tcp" Level="DEBUG": Src-ip="173.38.117.81" Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connecting"
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,534" Module="network.tcp" Level="DEBUG": Src-ip="173.38.117.81" Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connection Established"
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,535" Module="developer.ssl" Level="ERROR" CodeLocation="ppcmains/ssl/ttssl/ttssl_openssl.cpp(67)" Method="::TTSSLErrorOutput" Thread="0x7fae4ddb1700": TTSSL_continueHandshake: Failed to establish SSL connection
2015-08-04T10:14:23-05:00 expe tvcs: UTCTime="2015-08-04 15:14:23,535" Module="network.tcp" Level="DEBUG": Src-ip="173.38.117.81" Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="TCP Connection Closed" Reason="Got EOF on socket"
2015-08-04T10:14:23-05:00 expe tvcs: Event="Inbound TLS Negotiation Error" Service="SIP" Src-ip="173.38.117.81" Src-port="24646" Dst-ip="10.2.0.2" Dst-port="5061" Detail="No SSL error available, probably remote disconnect" Protocol="TLS" Level="1" UTCTime="2015-08-04 15:14:23,535"
Registros de Jabber:
-- 2015-08-04 10:48:04.775 ERROR [ad95000] - [csf.cert.][checkIdentifiers] Verification of identity: 'expe.korteco.com' failed.
-- 2015-08-04 10:48:04.777 INFO [ad95000] - [csf.cert][handlePlatformVerificationResultSynchronously] Verification result : FAILURE reason : [CN_NO_MATCH UNKNOWN]
-- 2015-08-04 10:48:05.284 WARNING [ad95000] - [csf.ecc.handyiron][ssl_state_callback] SSL alert read:fatal:handshake failure
type=eSIP, isRelevant=true, server=expe.korteco.com:5061, connectionState=eFailed, isEncrypted=true, failureReason=eTLSFailure, SSLErrorCode=336151568
type=eSIP, isRelevant=true, server=192.168.102.253:5060, connectionState=eFailed, isEncrypted=false, failureReason=eFailedToConnect, serverType=ePrimary, role=eNone
-- 2015-08-04 10:48:05.287 ERROR [ad95000] - [csf.ecc.handyiron][secSSLIsConnected] SSL_do_handshake() returned : SSL_ERROR_SSL.
La captura de paquetes de Jabber muestra una negociación SSL con la IP de Expressway E; sin embargo, el certificado enviado no proviene de este servidor:
El firewall tiene configurado Phone Proxy.
Solución:
Confirme que FW ejecute Phone Proxy. Para comprobarlo, introduzca el show run policy-map
y le mostrará algo similar a:
class sec_sip
inspect sip phone-proxy ASA-phone-proxy
Desactive el proxy del teléfono para que los servicios del teléfono se conecten correctamente.
Estas son algunas de las configuraciones faltantes e incorrectas que pueden causar este problema en las implementaciones NIC únicas y duales:
No se recomienda una única NIC con implementaciones NAT estáticas. Estas son algunas consideraciones para evitar problemas de medios:
Puede encontrar más información al respecto en el Apéndice 4 de la Guía de implementación de configuración básica de Cisco Expressway-E y Expressway-C.
Este problema se debe a una limitación en Expressway anterior a la versión X8.5. El Id. de error de Cisco CSCua72781 describe cómo Expressway-C no reenvía medios tempranos en el progreso de la sesión 183 o el timbre 180 a través de la zona transversal. Si ejecuta las versiones X8.1.x o X8.2.x, puede actualizar a la versión X8.5 o realizar la solución alternativa aquí indicada.
Es posible utilizar una solución alternativa en Cisco Unified Border Element (CUBE) si crea un perfil SIP que convierte el 183 en un 180 y lo aplica en el dial-peer entrante. Por ejemplo:
voice class sip-profiles 11
response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session Progress"
"SIP/2.0 180 Ringing"
Después desactivarían 180 Early Media en el perfil SIP de CUCM > CUBE o en el propio CUBE dentro del modo de configuración de sip-ua.
disable-early-media 180
Cuando agrega CUCM a Expressway-C, se produce un error ASCII que impide que se agregue CUCM.
Cuando Expressway-C agrega CUCM a su base de datos, se ejecuta mediante una serie de consultas AXL relacionadas con las funciones get y list. Algunos ejemplos de estos incluyen getCallManager, listCallManager, listProcessNode, listProcessNodeService y getCCMVersion. Después de ejecutar el proceso getCallManager, se ejecuta sucesivamente con un conjunto ExecuteSQLQuery para recuperar todos los valores de confianza de CUCM Call Manager o tomcat.
Una vez que CUCM recibe la consulta y se ejecuta en ella, CUCM devuelve todos sus certificados. Si uno de los certificados contiene un carácter que no es ASCII, Expressway genera un error en la interfaz web similar a ascii codec can't decode byte 0xc3 in position 42487: ordinal not in range(128)
.
Este problema se rastrea con el Id. de bug Cisco CSCuo54489 y se resuelve en la Versión X8.2.
Este problema se produce cuando utiliza certificados autofirmados en CUCM y Tomcat.pem/CallManager.pem tiene el mismo asunto. El problema se aborda con el ID de bug de Cisco CSCun30200. La solución temporal para corregir el problema es eliminar tomcat.pem y deshabilitar la verificación de TLS de la configuración de CUCM en Expressway-C.
Cuando agrega un servidor de IM&P, Expressway-C informa "Este servidor no es un servidor de IM y presencia" o "No se puede comunicar con el error HTTP de consulta .AXL ''HTTPError:500'", lo que hace que el servidor de IM&P no se agregue.
Como parte de la adición de un servidor de IM&P, Expressway-C utiliza una consulta AXL para buscar los certificados de IM&P en un directorio explícito. Debido al Id. de bug Cisco CSCul05131, los certificados no están en ese almacén; por lo tanto, se encuentra con el error false.
Para que el estado del correo de voz del cliente Jabber se conecte correctamente, debe configurar la dirección IP o el nombre de host de Cisco Unity Connection dentro de la lista de permitidos HTTP en Expressway-C.
Para completar esto desde Expressway-C, realice el procedimiento pertinente:
Procedimiento para las versiones X8.1 y X8.2
Procedimiento para la versión X8.5
La solución de acceso remoto y móvil solo utiliza UDS para la resolución de fotos de contacto. Esto requiere que tenga un servidor web disponible para almacenar las fotos. La configuración en sí es doble.
<Directory>
<DirectoryServerType>UDS</DirectoryServerType>
<PhotoUriWithToken>http://%IP/Hostname%/photo%%uid%%.jpg<
/PhotoUriWithToken>
<UdsServer>%IP%</UdsServer>
<MinimumCharacterQuery>3</MinimumCharacterQuery>
</Directory>
Nota: Para obtener más información sobre la resolución de fotos de contacto de UDS, refiérase a la Documentación de fotos de contacto de Jabber.
Este mensaje de error puede estar relacionado con el certificado de borde de Expressway no firmado por una CA pública que sea de confianza para el dispositivo del cliente o que el dominio falte como una SAN en el certificado del servidor.
Para evitar que se pida al cliente Jabber que acepte el certificado de Expressway, debe cumplir los dos criterios enumerados a continuación:
Nota: Esto se consigue fácilmente si utiliza una autoridad de certificación pública porque los dispositivos móviles contienen un gran almacén de confianza de certificados.