# Configurar un dominio de inicio de sesión personalizado Un dominio personalizado como `login.acme.com` sirve cada superficie para usuarios finales de su entorno: el inicio de sesión alojado, el portal de la cuenta, el Admin Portal, los endpoints OIDC y OAuth, SSO, SAML y SCIM, y los enlaces de los correos electrónicos. KeenAuth no aloja el dominio de su propia aplicación. El entorno `development` no tiene dominios personalizados. ## Antes de empezar - El nombre debe tener al menos tres etiquetas (un subdominio), porque un CNAME no puede definirse en la raíz de un dominio. - Se convierte a su etiqueta A de IDNA2008 y se pasa a minúsculas. No puede ser `keenauth.app`, `keenauth.com` ni un subdominio de ellos, y tampoco puede ser un sufijo público. - Un nombre es único en toda la plataforma. Un nombre liberado queda en cuarentena durante 30 días antes de que otra cuenta pueda añadirlo. - Plan Free: un dominio, y la cuenta debe tener una tarjeta de pago verificada. Más de un dominio por entorno es una función de Enterprise. - Cada cuenta puede añadir como máximo 10 dominios al día (UTC). Los intentos rechazados también cuentan. ## Paso 1: añada el dominio Llame a [Añadir un dominio personalizado](/docs/api/management/custom-domains/create). El dominio empieza en `pending_dns` y la respuesta enumera los registros DNS que debe publicar. ## Paso 2: publique dos registros DNS | Tipo | Nombre | Valor | |---|---|---| | TXT | `_akp-verify.` | `idp-verify=` | | CNAME | `` | `..edge.keenauth.app` | Mantenga el registro TXT en el DNS de forma permanente, también después de que el dominio esté activo. Es la prueba de propiedad: si el dominio cambia de manos, el propietario anterior ya no puede hacer que se sirva la página. Ambos registros deben ser visibles. La comprobación se ejecuta cada 5 minutos durante 72 horas, y después cada hora durante 30 días. Para reiniciar una comprobación detenida, llame a [Verificar un dominio personalizado](/docs/api/management/custom-domains/verify). ## Paso 3: revise los registros CAA Si el dominio o cualquiera de sus dominios superiores tiene un registro CAA, debe permitir las dos autoridades de certificación ACME que usa KeenAuth. Si no, el dominio vuelve a `pending_dns` con el motivo de error `caa_blocked`, y el panel muestra la línea CAA exacta que debe añadir. Si no existe ningún registro CAA, no se necesita nada. ## Certificado y ciclo de vida KeenAuth obtiene y renueva el certificado TLS por usted. Un certificado se renueva cuando le quedan menos de 30 días de vigencia. Si la renovación falla durante 7 días, recibe el evento `custom_domain.certificate_renewal_failed` y un correo electrónico. La entrega de eventos aún no está disponible; llega con los webhooks en la fase 6A. | Estado | Significado | Siguiente | |---|---|---| | `pending_dns` | Añadido; espera los registros TXT y CNAME | Ambos vistos: `issuing` | | `issuing` | El certificado se está emitiendo | Emitido: `active`. Bloqueo CAA: `pending_dns` con `caa_blocked`. No emitido en 72 horas: `pending_dns` con `certificate_failed` | | `active` | En servicio | Una comprobación diaria fallida: `degraded` | | `degraded` | Falta el registro TXT o CNAME desde hace un día o más; el dominio sigue sirviendo | Corregido: `active`. Sin corregir durante 7 días: `disabled` | | `disabled` | Fuera de servicio; el certificado se elimina y las sesiones de este host se invalidan | Se reinicia con `:verify`: `pending_dns` | | `released` | Se eliminó el dominio o el entorno | Tras 30 días de cuarentena, el nombre se puede volver a añadir | Un dominio activo se comprueba una vez cada 24 horas. Suscríbase a los eventos `custom_domain.verified`, `custom_domain.activated`, `custom_domain.degraded` y `custom_domain.disabled` para que le avisen cuando algo cambie. Estos eventos aún no están disponibles; la entrega llega con los webhooks y la API de eventos en la fase 6A. ## Dominio principal y eliminación Uno de los dominios del entorno es el principal; los enlaces de los correos electrónicos lo usan. Cámbielo con [Hacer principal un dominio personalizado](/docs/api/management/custom-domains/make-primary). Cuando el emisor del entorno sigue al dominio principal, cambiar el dominio principal también cambia el emisor, y es una operación planificada con al menos 7 días de antelación. Un dominio principal, o el dominio que es el emisor, no se puede eliminar (`409 custom_domain_in_use`). Elija primero otro dominio principal. Un dominio usado como rpId de passkey tampoco se puede eliminar ni desactivar (`409 domain_in_use_by_rp_id`). ## Varios dominios en un entorno En Enterprise, un entorno puede tener varios dominios verificados. Cada dominio tiene su propia cookie de sesión, por lo que no hay SSO silencioso entre dominios. Las passkeys entre dominios dependen de la elección del rpId y de la lista de orígenes relacionados, que contiene como máximo 5 etiquetas de dominio registrado y solo los dominios `active` del mismo entorno. Cada aplicación puede tener su propia marca en cada dominio; consulte [Personalizar sus páginas de inicio de sesión](/docs/guides/branding).