Firmar un documento parece una operación local: el archivo está en el disco, el certificado en el token y el programa en el escritorio. En la práctica, una firma bien hecha necesita salir a internet. Necesita comprobar que el certificado sigue vigente, necesita pedir un sello de tiempo confiable y, si la firma es en la nube, necesita hablar con el servicio que custodia la clave. Cuando un proxy corporativo se interpone, todo eso falla de maneras que rara vez dicen "problema de red".
Este artículo ordena qué hay que permitir, por qué, y cómo demostrar que el bloqueo está en la red y no en el firmador. Está escrito para el área de infraestructura, que es quien tiene que aprobar la excepción.
Qué tráfico genera realmente una firma
Conviene tener claro el mapa antes de pedir permisos:
- Consulta de estado del certificado. La comprobación de que el certificado no fue revocado se hace contra los servicios de la entidad emisora. Históricamente estas consultas viajan por HTTP en el puerto 80, no por HTTPS, y eso sorprende a más de un equipo de seguridad que bloquea todo el puerto 80 saliente.
- Sellado de tiempo. Si la firma incorpora un sello de tiempo, hay una llamada adicional al servicio correspondiente, normalmente por HTTP o HTTPS.
- Firma en la nube. El documento o su resumen viaja por HTTPS al servicio del proveedor, en el puerto 443.
- Actualizaciones y descarga del firmador. Tráfico HTTPS ocasional, que puede convivir con una política más restrictiva.
- Sincronización de hora. No es tráfico de firma, pero un reloj desfasado invalida validaciones y sellos. El servicio de hora usa su propio puerto y suele estar permitido solo hacia el controlador de dominio.
Puertos: la lista corta
| Puerto | Para qué | Comentario |
|---|---|---|
| 443 (HTTPS) | Servicios de firma en la nube, portales, actualizaciones | Imprescindible; el que casi siempre está abierto |
| 80 (HTTP) | Consulta de estado y descarga de listas de revocación | El olvido más frecuente; muchas organizaciones lo cierran por completo |
| Servicio de hora | Reloj del sistema sincronizado | Basta con que el equipo sincronice contra el controlador de dominio y este contra una fuente confiable |
No hay puertos exóticos en juego. El problema casi nunca es el número de puerto, sino el destino y la inspección.
Dominios: pídelos, no los adivines
Aquí conviene ser categórico: la lista de dominios a permitir la entrega tu proveedor de certificados y la entidad emisora, y cambia con el tiempo. Copiar una lista de un foro o deducirla de una captura de tráfico vieja es la mejor manera de dejar el firmador funcionando a medias durante meses. Lo que sí se puede fijar como criterio:
- Autorizar por nombre de dominio, no por dirección IP. Los servicios de validación suelen estar detrás de redes de distribución de contenido y su dirección cambia sin aviso.
- Incluir los dominios de la entidad emisora que publican el estado de los certificados, no solo el sitio web del proveedor.
- Documentar la excepción con su justificación, para que sobreviva a la siguiente revisión de la política de seguridad.
- Revisar la lista cuando se renueve el certificado o cuando el proveedor anuncie cambios de infraestructura.
Si tu empresa emite comprobantes electrónicos desde el mismo equipo, la lista debe incluir además los servicios en línea del SRI que consume tu sistema de facturación. Ese tráfico es distinto del de la firma, aunque el certificado sea el mismo; el contexto está en firma electrónica y facturación electrónica ante el SRI.
La inspección de tráfico: el enemigo silencioso
Muchos proxies corporativos hacen inspección TLS: rompen la conexión cifrada, la examinan y la vuelven a firmar con un certificado emitido por una autoridad interna de la empresa. Para el navegador eso es transparente, porque esa autoridad interna está desplegada en el almacén de Windows. Para una aplicación de escritorio basada en Java, no lo es.
La razón es concreta y vale la pena que quede clara: Java mantiene su propio almacén de certificados de confianza, independiente del de Windows. Si el proxy inspecciona el tráfico y la autoridad interna no está también en ese almacén, la aplicación rechaza la conexión y muestra un error de certificado que no tiene nada que ver con el certificado de firma del usuario. La solución es una de dos: importar la autoridad interna en el almacén de confianza de Java, o excluir de la inspección los destinos de firma. Los detalles del lado de Java están en Java en la empresa: versiones compatibles y cómo fijarlas.
Para servicios de validación de estado de certificados, la práctica recomendada es excluirlos de la inspección: el objetivo de esa consulta es precisamente verificar una cadena de confianza, y un intermediario que la reescribe no ayuda.
Proxy con autenticación
Es el segundo gran bloqueo. Cuando el proxy exige autenticación integrada del dominio, el navegador la resuelve solo. Una aplicación de escritorio puede no hacerlo, o hacerlo únicamente si se le indica la configuración del proxy de forma explícita. Los síntomas son inconfundibles una vez que se conocen: el usuario navega sin problemas, pero el firmador se queda esperando y termina con un error de conexión.
Las salidas habituales, en orden de preferencia:
- Definir una excepción sin autenticación para los destinos de firma, acotada por dominio.
- Configurar el proxy explícitamente en la aplicación o en el entorno de ejecución, si el firmador lo permite.
- Como último recurso y solo con aprobación del área de seguridad, una ruta directa a internet para los equipos que firman.
Los archivos de configuración automática también merecen revisión: si la lógica de ese archivo envía todo por el proxy sin excepciones, ninguna configuración local ayudará.
Cómo demostrar que el bloqueo es de red
Antes de abrir un ticket con el proveedor de certificados, tres pruebas que cierran el diagnóstico:
- Intentar la misma operación desde un equipo conectado a una red sin proxy, por ejemplo un enlace móvil. Si ahí funciona, el problema es de red corporativa y no del certificado.
- Revisar los registros del proxy en el momento exacto del intento fallido: la denegación aparece con el destino que se está bloqueando, que es la información que hace falta para la excepción.
- Comprobar la hora del equipo. Un desfase significativo produce errores de validación que parecen de red y no lo son.
Si tras abrir la red el problema persiste, el siguiente sospechoso es la protección del endpoint: revisa antivirus corporativo que bloquea FirmaEC y, si el equipo está en dominio, las directivas de grupo que bloquean la firma. Para una red corporativa completa, el marco general está en cómo configurar FirmaEC en una red corporativa.
Firma en la nube: menos excepciones que administrar
Desde el punto de vista de red, la firma en la nube es la opción más sencilla de gobernar: una salida HTTPS hacia un conjunto acotado de dominios, sin controladores ni dispositivos en el puesto. Firmas.com.ec emite certificados con trámite 100% en línea y entrega en aproximadamente 30 minutos, en formato archivo .p12, token USB o firma en la nube, con validez legal y ante el SRI, y el equipo corporativo puede entregar a tu área de infraestructura la lista de destinos a permitir. Consulta el precio actualizado en la página de precios.
Si además necesitas emitir comprobantes electrónicos, el grupo ofrece Azur, facturación electrónica autorizada por el SRI, con registro en azur.com.ec/registro.
Coordinar el soporte sin perder el hilo
El grupo desarrolla también Omnifox, plataforma omnicanal que reúne WhatsApp, correo, redes sociales y llamadas en una sola bandeja. Para una coordinación entre infraestructura, usuarios y proveedor, tener la conversación completa en un solo lugar acorta bastante el tiempo de resolución. Más información en omnifox.io.
Preguntas frecuentes
¿Basta con abrir el puerto 443?
No siempre. Las consultas de estado de certificados suelen viajar por el puerto 80, y muchas organizaciones lo bloquean por completo en la salida. Ese es uno de los olvidos más frecuentes.
¿Puedo autorizar por dirección IP en lugar de por dominio?
No es recomendable. Los servicios de validación cambian de dirección con frecuencia y la excepción quedará obsoleta sin aviso, con fallos intermitentes difíciles de rastrear.
¿Por qué el navegador funciona y el firmador no?
Por dos motivos habituales: el firmador puede no heredar la configuración de proxy del sistema, y las aplicaciones basadas en Java usan un almacén de certificados de confianza propio, distinto del de Windows.
¿Hay que excluir la firma de la inspección TLS?
Para los servicios de validación de certificados es lo más sensato. Si la política de la empresa no lo permite, la alternativa es importar la autoridad interna en el almacén de confianza de la aplicación.
¿La hora del equipo influye?
Sí. Un reloj desfasado hace que las validaciones y los sellos de tiempo fallen o queden marcados como no confiables, con mensajes que no mencionan la hora por ningún lado.
Si tu área de infraestructura necesita la lista de destinos a permitir y un esquema de firma que no complique la política de red, habla con un asesor corporativo de Firmas.com.ec. Solicita tu cotización corporativa.