Error en sistemas para documentación medica del issemym

Errores críticos en sistema de validación de vigencia del Instituto de Seguridad Social del Estado de México y Municipios (issemym), demuestran incapacidad para la resolución de problemas tecnológicos dentro de sus infraestructuras digitales para mantener la operación de las diversas actividades que dependen de este documento digital.

  El fin de semana pasado, el 24 de enero, sábado, por una situación medica de un familiar, me pidieron que le obtuviera una serie de documentos de forma electrónica, el CURP, Acta de Nacimiento, IMSS, etc, entre otros uno me llamo la atención, porque nunca lo había sacado o generado, y es el llamado “Constancia de Vigencia o no Vigencia del ISSEMYM”, este trámite o documento indica o sirve para indicar si tienes derecho a los servicios médicos por parte del ISSEMYM o no, y para obtenerlo tienes que entrar al siguiente link: 

https://prestaciones.issemym.gob.mx/issemymdigital/

Y estuve investigando de como tramitar este documento oficial y me encontré con este video que indica los pasos a seguir, fueron los mismos pasos que tuve que seguir, pero en mi caso no funciono de forma adecuada.

Segui los pasos que indica el video, llene el formulario, con la CURP, llene el formulario, con el nombre y apellidos, y la palabra de seguridad presione el botón “Consultar Información” y espere a que se procesara la solicitud y me generara el archivo pdf con el resultado de la consulta, pero en vez de obtener el dichoso documento me mostro una pantalla con la siguiente información:
 

Error de servidor en la aplicación '/issemymdigital'.

---

No es posible conectar con el servidor remoto(-10001)

Descripción: Excepción no controlada al ejecutar la solicitud Web actual. Revise el seguimiento de la pila para obtener más información acerca del error y dónde se originó en el código.

Detalles de la excepción: System.Exception: No es posible conectar con el servidor remoto(-10001)

Error de código fuente:

Se ha generado una excepción no controlada durante la ejecución de la solicitud Web actual. La información sobre el origen y la ubicación de la excepción pueden identificarse utilizando la excepción del seguimiento de la pila siguiente.

Seguimiento de la pila:

[Exception: No es posible conectar con el servidor remoto(-10001)] GeneXus.Programs.SdtWebServiceFirmaCVD.firmaconstanciavigenciaderechos(String gxTp_DATOS) +3114 GeneXus.Programs.acairconstaciandv.executePrivate() +792 GeneXus.Programs.acairconstaciandv.webExecute() +567 GeneXus.Http.GXHttpHandler.ProcessRequest(HttpContext httpContext) +899 [Exception: GXApplication exception] GeneXus.Http.GXHttpHandler.ProcessRequest(HttpContext httpContext) +1168 System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +790 System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) +195 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +88

---

Información de versión: Versión de Microsoft .NET Framework:4.0.30319; Versión ASP.NET:4.7.4087.0

Y le pregunte a la IA, que me puede dar de más información al respecto y este fue el resultado:

Gracias por traer el detalle completo del fallo. Voy a desglosarlo en claro, proponerte causas probables, pruebas de diagnóstico y acciones correctivas, específicas para un stack IIS + ASP.NET 4.x + GeneXus llamando un Web Service de firma del Estado de México.

1) ¿Qué significa exactamente el error?

Mensaje clave: No es posible conectar con el servidor remoto (-10001)

Contexto: La llamada ocurre en GeneXus.Programs.SdtWebServiceFirmaCVD.firmaconstanciavigenciaderechos(String gxTp_DATOS), invocada desde acairconstaciandv.

Capa: Falla previa a ejecutar lógica de negocio del servicio remoto; es un error de conectividad/seguridad en la salida desde tu aplicación hacia el Web Service de firma (probablemente SOAP/REST).

Tecnología: ASP.NET 4.7.4087.0 (app compilada con .NET 4.0.30319), ejecutando en IIS.

Traducción práctica: tu app en IIS intenta consumir el servicio de “firma de constancia de vigencia de derechos”, pero no logra establecer la conexión (DNS/puerto/red/proxy/TLS/certificados), y GeneXus lo encapsula en una excepción genérica (código interno -10001).

2) Causas más probables (ordenadas por frecuencia)

A. Red / Resolución / Conectividad

DNS: el host del WS cambió o no resuelve desde el servidor IIS.

Firewall/salida: puerto 443 o 80 bloqueado hacia el dominio del WS.

Proxy corporativo: la app no usa el proxy correcto (o WinHTTP vs IE/usuario).

Routing: caída de ruta, bloqueo en UTM, o lista blanca no actualizada.

IPV6/SNI: endpoint requiere SNI/IPv4 y el cliente negocia mal.

B. Seguridad / TLS / Cifrado

Versión de TLS: el servidor remoto exige TLS 1.2+ y tu app cliente negocia 1.0/1.1 (común cuando la app fue compilada con .NET 4.0).

Cifrados (cipher suites): desalineación (el remoto exige suites modernas).

Fecha/Hora del servidor desincronizada → rompe TLS y validación de cert.

C. Certificados y firma (muy probable por tratarse de “firma”)

Cadena de confianza del certificado del servidor no instalada en el servidor IIS consumidor (faltan intermedios/raíz).

CRL/OCSP inaccesibles (el servidor necesita salir a validar revocación).

Certificado cliente (si el WS exige autenticación mutua): no instalado, sin clave privada o permisos al App Pool Identity.

Cert expirado o con CN/SAN que no coincide con el host.

D. Endpoint / Servicio remoto

URL cambió o ambiente (prod/pre) ya no está disponible.

Intermitencia/caída del WS o rate limiting / bloqueo por IP.

Cambios de contrato (menos probable porque el error es de transporte).

E. Configuración de la app GeneXus/.NET

Timeout de conexión demasiado corto.

Proxy configurado en web.config distinto al proxy de máquina.

ServicePointManager.SecurityProtocol no forzado a TLS 1.2.

Codificación/characters en gxTp_DATOS no afectan a conexión, pero si el WS valida algo al handshake de app gateway, podría cortar (raro). 

 

Apuntes finales

La complejidad que existe detrás de los sistemas web siempre me ha fascinado. El simple hecho de que un trámite pueda completarse en segundos implica la coordinación de servidores, bases de datos, servicios web, certificados digitales, redes y múltiples capas de tecnología que deben funcionar en perfecta armonía. Todo ese ecosistema existe para facilitar la vida de los usuarios y entregar resultados correctos, confiables y oportunos.

Por eso mismo resulta tan frustrante ver cómo, cuando realmente se necesitan, los sistemas críticos del gobierno pueden fallar. Y en mi opinión, este es un problema serio. Los sistemas que afectan directamente la salud, los derechos o la atención de las personas no deberían presentar fallas de este tamaño, y mucho menos permanecer inoperantes durante días.

Este error reportado desde el viernes 23 de enero de 2026 continúa sin resolverse al momento de escribir este post, lunes 26 de enero de 2026. Es decir, han pasado cuatro días y el servicio sigue caído. En términos de gestión de sistemas, esto es realmente inaudito. ¿Cuántas personas, como mi familiar, dependen de este documento para recibir atención médica? ¿Cuántos trámites quedan detenidos? ¿Cuánta gente queda en incertidumbre por la falta de una constancia que debería generarse en segundos?

Es lamentable que el Gobierno del Estado de México no pueda resolver un problema tan prioritario en un tiempo razonable, o mejor aún, anticiparse a él implementando redundancia, monitoreo adecuado y mecanismos de prevención. Al final, quienes terminan pagando las consecuencias son los ciudadanos que dependen diariamente de estos servicios digitales.

La tecnología puede facilitar la vida, sí, pero solo cuando se administra con responsabilidad, visión y verdaderas prioridades en beneficio de la población.