> For the complete documentation index, see [llms.txt](https://wiki.datadike.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.datadike.com/es/pam/deploy-operate/certificates.md). # 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. {% hint style="warning" %} **La instalación del certificado en sí no es un procedimiento de autoservicio en el material de origen de esta wiki.** Lo que la fuente afirma es que implementar el certificado HTTPS requiere el soporte de implantación de DataDike, que accede al servidor por línea de comandos para importar su wildcard. Recurra al soporte en lugar de improvisar. Tenga en cuenta además que existe una pantalla de Configuración para subir un certificado wildcard o de subdominio, cuyos campos no pudieron verificarse contra la fuente y, por tanto, no se documentan aquí. Confirme con el soporte qué vía se aplica a su instalación y a su versión. {% endhint %} ## Qué está establecido | Hecho | Nota | | ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | 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 1. **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. 2. **Pida al soporte que importe el certificado** en el servidor. 3. **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**. 4. **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. 5. **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: | Consumidor | Efecto de un valor incorrecto | | ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------- | | 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. 1. **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. 2. **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. 3. **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. 4. **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í. 5. **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. {% hint style="warning" %} **Nada en la fuente documenta una alerta de vencimiento para el certificado de la consola.** Siga la fecha de vencimiento fuera del producto, en su inventario de certificados o en su sistema de monitorización. Un certificado que caduca tumba el acceso por navegador de todo el mundo a la vez, y lo hace en una fecha que se conocía con meses de antelación. {% endhint %} ## Errores frecuentes | Síntoma | Causa | Solución | | ----------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | 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](/es/pam/deploy-operate/upgrade.md) | | 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 * [Actualización](/es/pam/deploy-operate/upgrade.md) * [Monitorización y salud](/es/pam/deploy-operate/monitoring.md) * [Puertos](/es/pam/reference/ports.md) * [Conceptos esenciales](/es/pam/get-started/core-concepts.md)