Certificados y HTTPS
Servir la consola por HTTPS: el nombre con el que el certificado debe coincidir, el ajuste URL del sitio que debe concordar con él, y qué se rompe en silencio cuando los dos discrepan.
Qué es esto y cuándo usarlo
Dos cosas distintas tienen que encajar antes de que la consola quede servida correctamente por HTTPS, y confundirlas es la razón de ser de esta página:
El certificado que termina el HTTPS para el acceso web, instalado en el servidor y coincidente con el nombre DNS que teclean sus usuarios.
URL del sitio, un ajuste que le indica a la solución su propia dirección pública.
El certificado hace que el navegador deje de advertir. La URL del sitio es lo que la solución pone en los enlaces de los correos de notificación, en las redirecciones de SSO y en las llamadas de retorno internas. Acertar con el certificado y no tocar la URL del sitio produce una instalación que parece terminada (la página de inicio de sesión carga por HTTPS sin advertencia) y rompe en silencio el inicio de sesión único y todos los enlaces que el sistema envía por correo.
Los certificados de otros puntos del producto son otras cadenas de confianza y no se configuran aquí: LDAPS usa sus propios archivos de certificado cargados en el appliance, el broker autentica gateways y conectores con su propia PKI, y el TLS de SMTP se configura junto con el servidor de correo. Arreglar el certificado de la consola no toca ninguno de ellos.
Qué está establecido
La interfaz web se sirve por HTTPS para el acceso por navegador
Enunciado como característica de la plataforma
Para el acceso web puede usarse su propio certificado o la emisión automática
Cuál de los dos se aplica a su instalación y a su versión debe confirmarse con el soporte; la fuente no afirma más que la existencia de ambos
El certificado lo importa en el servidor el soporte de implantación
Enunciado para el caso del wildcard
La dirección debe ser un nombre DNS que resuelva para sus usuarios
Un certificado coincide con nombres, y la vía temporal de configuración usa una entrada del archivo hosts que solo existe en una máquina
Antes de empezar
Cierre primero el nombre DNS. El certificado coincide con el nombre que teclean los usuarios, la URL del sitio se construye a partir de él, y cambiarlo más tarde significa revisar los dos.
Tenga el certificado. Un certificado wildcard o de subdominio que cubra ese nombre.
Conozca sus dos etapas de DNS. La fuente describe la configuración deliberadamente en dos: una etapa temporal, en la que usted añade una entrada en el archivo hosts de su propia máquina solo para alcanzar el appliance durante la configuración, y la etapa definitiva, en la que los registros existen en su DNS privado, más su DNS público si publica la consola en internet mediante NAT/DNAT. La entrada del hosts es un andamio; dejarla en su sitio es como un administrador acaba viendo un sistema que funciona y que nadie más puede alcanzar.
Recurra al soporte de implantación para la importación.
Pasos
Fije el nombre de host y cree los registros DNS definitivos para el nombre que cubre el certificado: DNS privado, y también DNS público si la consola se publica externamente.
Pida al soporte que importe el certificado en el servidor.
Fije la URL del sitio en Configuración del sistema › General › Básico con la URL completa de ese nombre, con el esquema
https://y sin barra final.Reinicie los componentes dependientes después de cambiar la URL del sitio. La fuente es explícita en que el cambio necesita esto para aplicarse.
Elimine la entrada temporal del archivo hosts de su propia máquina, para que esté probando lo que ven todos los demás.
Para qué se usa la URL del sitio
Por eso el paso 3 no es cosmético. La URL del sitio la consumen internamente:
Los enlaces de los correos de notificación: alertas, aprobaciones de acceso, restablecimientos de contraseña
Los destinatarios reciben un enlace a la dirección antigua, o a una IP por HTTP plano
Las redirecciones tras la autenticación por SSO (SAML2, OIDC, OAuth2)
El inicio de sesión federado falla o entra en bucle, mientras el local sigue funcionando
Las llamadas de retorno y los webhooks generados internamente
Las integraciones no consiguen devolver la llamada
La descarga del cliente de acceso remoto, donde esté configurada
Los clientes descargan de una dirección que puede no resolver para el usuario
Es obligatoria, y debe ser alcanzable desde los clientes que usan la plataforma, no solo resoluble en el servidor.
Cómo verificar que funcionó
Cada comprobación de abajo ejercita un consumidor distinto de la configuración, porque el candado del navegador solo demuestra el primero.
Abra la consola por el nombre DNS exacto, por HTTPS, desde una máquina sin entrada en el archivo hosts. Sin advertencia, y con el nombre del certificado coincidiendo con el nombre de la barra de direcciones.
Consulte el endpoint de salud no autenticado por HTTPS en ese mismo nombre:
/api/health/debe devolver su JSON. Esto confirma que el TLS termina en el nombre y que la aplicación responde detrás de él, cosa que una página estática de error o de mantenimiento no haría.Dispare algo que envíe un enlace, un correo de notificación que pueda recibir, y confirme que el enlace usa el nombre en HTTPS y no una IP o
http://. Esa es la comprobación de la URL del sitio, y nada de lo que se ve en el navegador la sustituye.Haga un inicio de sesión a través de su proveedor de identidad. La redirección posterior a la autenticación tiene que aterrizar en el nombre en HTTPS. Una URL del sitio obsoleta rompe exactamente eso y deja sano el inicio de sesión local, así que probar con la cuenta de administrador local no demuestra nada aquí.
Si un escáner de vulnerabilidades u otra integración consume la API de credenciales, confirme que su conector sigue funcionando: exige la URL base en HTTPS y un certificado que su propio almacén de confianza acepte. Una CA interna en la que los navegadores confían por una directiva de grupo no es necesariamente de confianza para un appliance de escaneo.
Errores frecuentes
La consola carga por HTTPS, pero el inicio de sesión por SSO entra en bucle o aterriza en la dirección equivocada
La URL del sitio no se actualizó al nombre en HTTPS
Fije la URL del sitio en General › Básico y después reinicie los componentes dependientes
Los enlaces de los correos apuntan a una dirección IP o a http://
La URL del sitio conserva todavía su valor de la instalación
La misma solución. Verifíquelo recibiendo un correo, no releyendo el campo
Advertencia de certificado en el navegador tras la instalación
El nombre que se teclea no está cubierto por el certificado, o el DNS todavía resuelve por una entrada de hosts sobrante
Use el nombre que cubre el certificado; elimine las entradas del archivo hosts y confirme que existen los registros DNS definitivos
Funciona para el administrador y es inalcanzable para el resto
La entrada temporal del archivo hosts sigue resolviendo en esa única máquina
Cree los registros definitivos en el DNS privado, y los públicos si la consola está publicada
Un escáner o una integración A2A no consigue conectar
URL base sin HTTPS, o un certificado en el que la integración no confía
Use la URL base en HTTPS y haga que el certificado sea de confianza para ese cliente
LDAPS sigue fallando después de arreglar el certificado de la consola
El TLS de LDAP usa sus propios archivos, ldap_ca.pem, ldap_cert.pem y ldap_cert.key, cargados en el appliance, y necesita un reinicio del servicio
Trate los certificados de LDAP aparte del certificado de la consola
Las conexiones de gateway fallan tras pasar a una release que exige TLS 1.3
La 5.0.1 exige TLS 1.3 entre la VM de Gateway y el servidor, y su nota de versión declara que es necesario un reinicio
Consulte Actualización
Los enrolamientos de broker se rompen tras cambiar la dirección del broker
La dirección del broker queda escrita en sus certificados y en sus tokens de enrolamiento y no puede cambiarse después
Direccione siempre el broker por nombre DNS; cambiarlo de otro modo significa reinstalar el broker
Páginas relacionadas
Atualizado
Isto foi útil?