Instalación inicial del servidor WiKID

Página de instalación inicial

La configuración inicial del servidor de autenticación WiKID es rápida y directa. En el proceso básico se crea una Autoridad Certificadora (CA) intermedia, se instala esa CA, se genera un certificado para localhost y se activan los módulos de protocolo necesarios. Tras completar estos pasos podrá añadir dominios, clientes de red y usuarios.

Figura 3 - La página de administración inicial

Configuración de la cadena de certificados

WiKID utiliza la autenticación basada en certificados en varias funciones internas importantes:

• Cada servidor de autenticación actúa también como una autoridad certificadora intermedia.
• Cada servidor identifica y autoriza a los clientes de red mediante autenticación por certificados.

Por tanto, es necesario generar un certificado antes de que el servidor sea completamente funcional. Este proceso se realiza desde la interfaz de administración del servidor. Acceda a la pestaña Crear una CA intermedia para usar las funciones de certificación.

Paso 1: Generar la CA intermedia

El primer paso es generar las claves pública/privada que identificarán este servidor y permitirán el cifrado asimétrico vía SSL. El servidor incluye una copia del certificado de la CA corporativa de WiKID. Este proceso generará sus claves y producirá una Solicitud de Firma de Certificado (CSR). Seleccione Generar y rellene el formulario como se describe a continuación.

Figura 4 - Pantalla para crear la autoridad certificadora intermedia

Este formulario recopila la información necesaria para generar la CSR. NOTA: Todos los campos son obligatorios.

Definición de campos y recomendaciones prácticas:

• Intermediate CA Administrator Email: Correo de contacto para la entrega del certificado firmado. Use una dirección válida y revisada.
• Server’s Fully Qualified Domain Name: Nombre FQDN registrado en DNS. Los clientes SSL esperan que este nombre coincida con el hostname que usan para conectarse.
• Organization Unit: Nombre de departamento o división. Solo para identificación.
• Organization Name: Razón social de la empresa que opera el servidor. Hágalo coincidir con los registros comerciales para agilizar la emisión del certificado.
• Locality: Ciudad donde está ubicado el servidor.
• State: Estado o provincia; por convención no se abrevia.
• Country Code: Código de dos letras del país, por ejemplo ES para España o US para Estados Unidos.
• Passphrase: Frase de acceso que protegerá la clave privada dentro de un archivo PKCS#12. Se solicitará cada vez que arranque el servidor para desbloquear la clave privada. No se almacena y no se puede recuperar; elija una frase robusta y recordable.

Consejos de seguridad y buenas prácticas:

• Use una dirección de correo que esté monitorizada por al menos dos administradores.
• El FQDN debe coincidir con el certificado que usarán los clientes; si va a usar varios alias, consulte opciones avanzadas (SANs) fuera de este flujo básico.
• Anote la passphrase en un gestor de contraseñas corporativo; perderla obliga a repetir el proceso desde el paso 1.

Seleccione Generar para crear las claves y la CSR. Tras generar los archivos verá una pantalla con la CSR en codificación base64 DER similar a la siguiente.

Figura 5 - La CSR

Copie todo el texto del cuadro (incluyendo las líneas —–BEGIN CERTIFICATE REQUEST—– y —–END CERTIFICATE REQUEST—–) al portapapeles.

Paso 2: Enviar la CSR para firma

Haga clic en el enlace a https://www/wikidsystems.com/wikid/newcertreq.jsp que aparece inmediatamente encima del cuadro de texto. Esto abrirá la página de envío de solicitudes de certificados para la CA de WiKID.

Figura 6 - Pantalla de envío de CSR

Pegue la CSR copiada (incluyendo las líneas —–) en el área indicada y envíe la solicitud. Recibirá un número de solicitud para seguimiento y el administrador de la CA de WiKID será notificado.

La administración de la CA procesará su solicitud y le enviará el certificado firmado por correo electrónico a la dirección que indicó en el Paso 1. Este proceso normalmente tarda menos de 1 día laborable. El certificado enviado por correo tendrá un formato de bloque de texto similar al que se muestra a continuación.

Figura 8 – Bloque del certificado

Importante: el certificado no sirve sin la clave privada generada y protegida en el Paso 1. Asegúrese de pegar el certificado como texto plano: clientes de correo como Outlook o Gmail pueden convertir formatos y alterar el contenido.

Paso 3: Instalar el certificado

Una vez recibido el certificado vuelva a la pantalla de gestión de certificados usando la pestaña Instalar CA intermedia y seleccione la opción Instalar.

Figura 9 – Pantalla de instalación del certificado

Pegue el texto del certificado desde el correo en el área indicada. Introduzca la passphrase que usó en el Paso 1 para proteger la clave privada y proceda a instalar la CA intermedia.

Notas de solución de problemas:

• Si aparece un error, verifique que la passphrase es la correcta.
• Asegúrese de pegar como texto plano, sin formato HTML ni conversiones de codificación.
• Si ha perdido la passphrase, deberá repetir el Paso 1 y generar nuevas claves y CSR; no existe recuperación.

Paso 4: Generar un certificado para localhost

Todos los sistemas que se comuniquen directamente con el servidor de autenticación requieren un certificado válido emitido por esa CA intermedia. Antes de que los clientes puedan acceder al servidor debe crear un certificado firmado por la CA intermedia. Esto evita que sistemas no autorizados hablen con el servidor de autenticación.

Tenga en cuenta que protocolos como RADIUS (en la versión Enterprise), LDAP, wAuth, etc., no siempre incorporan autenticación por certificados o cifrado en el transporte. Los módulos de protocolo de WiKID convierten de forma transparente estas interfaces al canal seguro requerido. En consecuencia, la interfaz LDAP del servidor WiKID exige un certificado para validar credenciales, aunque RADIUS no tenga concepto de certificados.

Los módulos de protocolo que se ejecutan localmente en el servidor pueden compartir un único certificado para localhost. Cree este certificado indicando “localhost” como Fully Qualified Domain Name en la pantalla de generación del certificado. Debe usarse exactamente el nombre localhost para servicios locales.

Figura 10 – Pantalla de generación de certificado

Explicación de los campos del formulario de cliente:

• Client’s Fully Qualified Domain Name: Nombre que se resolverá cuando un cliente se conecte usando este certificado. Para servicios locales debe ser “localhost”.
• Organization Name: Nombre de la empresa.
• Locality: Ciudad.
• State: Estado o provincia, sin abreviaturas.
• Country Code: Código de dos letras del país.
• Client PKCS12 Passphrase: Passphrase que protegerá el certificado generado en formato PKCS#12.
• Passphrase again: Repetición para verificación.
• Server Keystore Passphrase: Passphrase de la CA intermedia creada en el Paso 1.

Seleccione Generar y verá una pantalla con la ubicación del certificado generado.

Figura 11 – Pantalla de entrega del PKCS

Si el certificado es para servicios localhost, normalmente ya estará instalado en la ubicación apropiada del servidor.

Paso 5: Reiniciar el servidor wAuth

Inicie sesión en el servidor de autenticación como root y ejecute:

wikidctl restart

Esto detendrá e iniciará los servicios de WiKID Strong Authentication. Se le pedirá la passphrase de wAuth: es la passphrase que creó en el Paso 1 para la CA intermedia. Al introducirla correctamente, el servidor comenzará a usar el nuevo certificado para la autenticación de clientes.

Si desea evitar introducir la passphrase manualmente cada vez, puede crear un archivo llamado /etc/WiKID/security con una línea:

WAUTH_PASSPHRASE=yourpassphrase

Asegúrese de proteger los permisos de ese archivo para que solo root pueda leerlo. El uso de ese archivo reduce la seguridad si el servidor es comprometido, por lo que su uso debe evaluarse en función del contexto operacional.

Buenas prácticas y consideraciones

• Mantenga una copia de seguridad segura de la clave privada y no comparta la passphrase. Use gestión de secretos corporativos.
• Planifique la rotación de certificados antes de su expiración y coordine ventanas de mantenimiento para reinicios del servicio.
• Valide que los clientes confíen en la CA intermedia o en la cadena de confianza completa; en entornos con firewalls y proxys revierte problemas de conexión.
• Use nombres FQDN consistentes y monitorice errores de coincidencia de nombre común (CN) o SAN.

Procedimiento operativo estándar (SOP)

1. Revisar requisitos previos: acceso root y conexión a la interfaz de administración del servidor.
2. Generar CA intermedia: completar formulario y guardar la passphrase en un gestor seguro.
3. Copiar la CSR y enviar a la CA de WiKID mediante la URL indicada.
4. Registrar el número de solicitud y esperar notificación por email.
5. Al recibir el certificado, pegarlo en la pestaña Instalar CA intermedia y validar la instalación.
6. Generar certificado para localhost si procede.
7. Reiniciar wAuth con wikidctl restart e introducir la passphrase.
8. Verificar conectividad y autenticación desde clientes de prueba.

Lista de verificación por roles

Administrador de seguridad:

• Confirmar la identidad FQDN y el correo de administrador.
• Guardar passphrases en gestor de secretos.
• Revisar permisos del archivo /etc/WiKID/security si se usa.
• Programar rotación de certificados.

Operador del sistema:

• Generar CSR y enviar a la CA de WiKID.
• Pegar certificado recibido y ejecutar la instalación.
• Reiniciar el servicio y comprobar logs de arranque.

Auditor/Técnico de cumplimiento:

• Verificar que la CA intermedia esté instalada en la cadena de confianza.
• Comprobar registros de emisión y número de solicitud de la CA.
• Revisar uso de passphrases y accesos de root.

Runbook de incidentes frecuente

Incidente: Se perdió la passphrase de la CA intermedia

• Impacto: No se puede arrancar wAuth con la clave privada y el servidor no podrá autenticar clientes mediante certificados hasta regenerarla.
• Acciones inmediatas:
  1. Declarar incidente y notificar a administradores.
  2. Generar nuevas claves y CSR siguiendo el SOP y enviar a la CA.
  3. Instalar el nuevo certificado y reiniciar servicios.
  4. Invalidar la CA y certificados antiguos si está en su política.

Incidente: CSR rechazada por la CA

• Acciones:
  1. Revisar el email de rechazo por errores de formato o campos incompletos.
  2. Regenerar CSR corrigiendo los campos indicados (por ejemplo, FQDN o correo).
  3. Volver a enviar y monitorizar el número de solicitud.

Incidente: Certificado expirado

• Acciones:
  1. Preparar certificado de sustitución con antelación (ventana de preparación).
  2. Generar CSR y solicitar firma con la CA interna.
  3. Instalar nuevo certificado y reiniciar wAuth.

Casos de prueba y criterios de aceptación

Prueba 1: Validación de instalación de la CA intermedia

• Acción: Instalar certificado firmado.
• Criterio de aceptación: Interfaz confirma instalación sin errores y el servidor carga la cadena de certificados.

Prueba 2: Autenticación de cliente localhost

• Acción: Generar y usar certificado localhost para un servicio local.
• Criterio de aceptación: Servicio local acepta conexiones usando el certificado y no se muestran errores de coincidencia CN/SAN.

Prueba 3: Reinicio de wAuth con passphrase

• Acción: Ejecutar wikidctl restart e introducir passphrase.
• Criterio de aceptación: Servicios arrancan y logs no muestran errores de clave privada.

Seguridad y endurecimiento

• Restrinja el acceso SSH al servidor a rangos IPs de administración.
• Use permisos 600 para /etc/WiKID/security y UID root.
• Aplique actualizaciones de seguridad del sistema y parches del paquete WiKID.
• Mantenga registros de auditoría externos (SIEM) para eventos de arranque y fallos de certificado.
• Considere el uso de HSM o módulos PKCS#11 para almacenar claves privadas en entornos de alta seguridad.

Matriz de riesgos y mitigaciones

Mini-metodología: heurística para gestión de certificados

• Prevenga: planifique la rotación antes de la expiración.
• Proteja: centralice passphrases en gestor de secretos y limite accesos.
• Pruebe: valide certificados en un entorno de staging antes de producción.
• Recupere: documente procedimientos de regeneración y responsables.

Diagrama de decisión para acciones rápidas

flowchart TD
  A[¿La CA intermedia está instalada?] -->|Sí| B{¿El certificado localhost existe?}
  A -->|No| C[Generar CA intermedia y CSR]
  C --> D[Enviar CSR a CA y esperar certificado]
  D --> E[Instalar CA intermedia]
  B -->|Sí| F[Reiniciar wAuth y verificar]
  B -->|No| G[Generar certificado localhost]
  G --> F
  E --> B

Glosario de una línea

• CSR: Solicitud de Firma de Certificado que contiene la clave pública y metadatos.
• CA: Autoridad Certificadora que firma certificados y crea la cadena de confianza.
• PKCS#12: Formato de archivo que almacena clave privada y certificado, protegido por passphrase.
• localhost: Nombre reservado que se resuelve al host local (127.0.0.1).

Consideraciones de privacidad y cumplimiento

• No incluya información sensible en los campos del CSR que no deba ser pública.
• Trate el archivo PKCS#12 y las passphrases como datos sensibles; aplique políticas de acceso y retención conforme a GDPR si aplica.

Resumen final

• Genere la CA intermedia y mantenga la passphrase segura.
• Envíe la CSR a la CA de WiKID y pegue el certificado recibido como texto plano.
• Genere el certificado localhost para los servicios locales y reinicie wAuth.
• Documente y pruebe los procedimientos; proteja claves y passphrases.

Notas importantes:

• Nunca comparta la passphrase ni almacene el archivo PKCS#12 en ubicaciones sin protección.
• Si olvida la passphrase debe repetir la generación de claves desde el Paso 1.