Installazione iniziale del server di autenticazione WiKID

Installare il server WiKID richiede la creazione di una Certification Authority (CA) intermedia, la generazione di chiavi e di una CSR, l’invio della CSR alla CA di WiKID, l’installazione del certificato firmato e la generazione di un certificato per localhost. Riavviare il servizio wAuth con la passphrase del keystore intermedio per attivare i certificati. Seguire i checklist e le procedure di rollback fornite in fondo.

Introduzione

Questa guida traduce e amplia la procedura di installazione iniziale del server di autenticazione WiKID. Copre la creazione della CA intermedia, la generazione della CSR, la sottomissione per la firma, l’installazione del certificato, la creazione del certificato localhost e il riavvio del servizio. Include raccomandazioni di sicurezza, criteri di accettazione, casi di test, playbook operativo e suggerimenti di compatibilità.

Nota rapida sui termini: CSR — Certificate Signing Request: richiesta che contiene la chiave pubblica e i dati identificativi per ottenere un certificato firmato.

Pagina di amministrazione iniziale

La configurazione del server di autenticazione WiKID è rapida. Si crea una Certification Authority (CA) intermedia, si installa la CA, si genera un certificato per localhost e si attivano i moduli di protocollo. Dopo di che si possono aggiungere domini, client di rete e utenti.

Figura 3 - Pagina di amministrazione iniziale

Configurare la catena di certificati

Il sistema WiKID usa certificati in più funzioni critiche:

• Ogni server di autenticazione è anche una Certification Authority intermedia
• Ogni server usa i certificati per identificare e autorizzare i client di rete

Perché il server funzioni correttamente è necessario generare la chiave e il relativo CSR tramite l’interfaccia di amministrazione del server. Accedere alla scheda “Creating an Intermediate CA” per le funzioni di certificazione.

Fase 1: Generare la CA intermedia

Il primo passo è generare la coppia di chiavi pubblica/privata che identificherà il server e permetterà la cifratura asimmetrica via SSL. Il server include una copia del certificato della CA aziendale WiKID; questo processo genera le vostre chiavi e produce una CSR (Certificate Signing Request). Selezionare Generate e compilare il modulo.

Figura 4 - Schermata di creazione della Certification Authority intermedia

Questo modulo raccoglie i dati necessari per creare la CSR per il server. NOTA: tutti i campi sono obbligatori.

Definizioni dei campi

• Intermediate CA Administrator Email: indirizzo email di contatto per la consegna del certificato firmato. Deve essere valido.
• Server Fully Qualified Domain Name: nome ufficiale del server in DNS. I client SSL verificheranno che il nome corrisponda all’hostname usato per la connessione.
• Organization Unit: solitamente il reparto o divisione. Usato solo per identificazione.
• Organization Name: ragione sociale dell’ente che opera il server. Dovrebbe corrispondere ai record di vendita o valutazione WiKID per velocizzare l’emissione.
• Locality: città.
• State: stato o provincia (non abbreviato per convenzione).
• Country Code: codice nazione a due lettere (es. IT per Italia, US per Stati Uniti).
• Passphrase: passphrase usata per proteggere la chiave privata nel file PKCS#12. Serve ad avviare il server e non viene memorizzata né recuperata; sceglierne una forte e memorabile.

Selezionare Generate per creare le chiavi e la CSR. Dovrebbe apparire una schermata simile alla seguente.

Figura 5 - La CSR

La Certificate Signing Request sarà in codifica base64 DER. Selezionare tutto il testo nella textarea e copiarlo negli appunti.

Fase 2: Inviare la CSR per la firma

Cliccare sul link indicato sopra la textarea che punta a https://www/wikidsystems.com/wikid/newcertreq.jsp. Questo apre la pagina di sottomissione della CSR per la CA di WiKID.

Figura 6 - Schermata di invio CSR

Incollare la CSR (inclusi i delimitatori —-) nell’area prevista e inviare. Riceverete un numero di richiesta per il tracking e l’amministratore della CA sarà notificato.

Figura 7 - Schermata di conferma della CSR

L’amministratore della CA WiKID processerà la richiesta. Riceverete il certificato via email all’indirizzo fornito nel passo 1. Questo processo, in genere, richiede meno di 1 giorno lavorativo. Il certificato inviato via email sarà simile al blocco illustrato nella figura seguente.

Figura 8 - Blocco del certificato

Nota: il certificato è inutilizzabile senza la chiave privata generata e protetta alla fase 1. Copiare e incollare il certificato come testo semplice: Outlook e Gmail possono modificare la codifica.

Fase 3: Installare il certificato

Dopo aver ricevuto il certificato, tornare alla schermata di gestione certificati usando la scheda “Install Intermediate CA” e selezionare Install.

Figura 9 - Schermata di installazione del certificato

Incollare il testo del certificato ricevuto via email nell’area prevista. Inserire la passphrase usata per proteggere la chiave privata nella fase 1 e installare la CA intermedia. Se si riscontra un errore, verificare che la passphrase sia corretta e che il testo sia pastato come testo semplice. Se la passphrase è stata dimenticata, ripetere la procedura da fase 1.

Fase 4: Generare un certificato per localhost

Tutti i sistemi che comunicano direttamente con il server di autenticazione necessitano di un certificato valido emesso da quella CA intermedia. Per consentire ai client locali e ai moduli protocollo di accedere al server, creare un certificato firmato da questa CA.

Alcuni protocolli (es. RADIUS per la versione Enterprise, LDAP, wAuth) non prevedono certificati o cifratura nativa. I moduli di protocollo di WiKID convertono trasparentemente tali protocolli in comunicazioni sicure; pertanto l’interfaccia LDAP del server richiede un certificato anche se RADIUS non gestisce direttamente i certificati.

I moduli che girano localmente sul server possono condividere un singolo certificato per localhost. Creare questo certificato specificando “localhost” come Fully Qualified Domain Name. Deve chiamarsi esattamente “localhost”.

Figura 10 - Schermata di generazione certificato

Significato dei campi nel modulo:

• Client’s Fully Qualified Domain Name: nome che il server risolverà per le connessioni client. Per servizi locali deve essere “localhost”.
• Organization Name: ragione sociale dell’ente che gestisce il client.
• Locality: città.
• State: stato o provincia (non abbreviato).
• Country Code: codice nazione a due lettere.
• Client PKCS12 Passphrase: passphrase che protegerà il certificato generato nel file PKCS#12.
• Passphrase again: ripetere la passphrase per verifica.
• Server Keystore Passphrase: passphrase del keystore della CA intermedia creata in fase 1.

Selezionare Generate e verrà mostrata una schermata di conferma simile alla seguente.

Figura 11 - Schermata di consegna del file PKCS

Il messaggio fornisce la posizione del certificato generato. Se il certificato è per i servizi localhost, è già installato nella posizione corretta.

Fase 5: Riavviare il server wAuth

Accedere al server di autenticazione come root e digitare:

wikidctl restart

Questo arresta e riavvia i servizi WiKID Strong Authentication. Verrà richiesto di inserire la passphrase wAuth: è la passphrase del keystore intermedio creata in fase 1. Inserendo la passphrase corretta il server userà il nuovo certificato per autenticare i client.

Se si desidera evitare l’inserimento della passphrase ad ogni riavvio, è possibile creare il file /etc/WiKID/security con una riga contenente la variabile WAUTH_PASSPHRASE. Esempio:

WAUTH_PASSPHRASE=tuapassphrase

Assicurarsi che questo file sia protetto con permessi restrittivi (es. 600) e che l’accesso sia limitato solo all’utente root per ridurre il rischio di compromissione.

Note di sicurezza importanti

• La passphrase del keystore non viene memorizzata altrove: se persa, non è possibile recuperare il keystore e bisogna rigenerare la CA intermedia e i certificati.
• Proteggere sempre i file PKCS#12 e il file /etc/WiKID/security con permessi di filesystem restrittivi (chmod 600, proprietà root).
• Preferire passphrase lunghe (minimo 16 caratteri) e un gestore di password sicuro.
• Non inviare mai i file di chiave privata via email o canali non cifrati.

Criteri di accettazione

Per considerare l’installazione completata con successo, verificare i seguenti punti:

• La CA intermedia è installata e visibile nell’interfaccia di amministrazione.
• Il certificato intermedio è stato importato senza errori.
• Il certificato localhost è generato e installato nella posizione indicata.
• I servizi di rete (LDAP, wAuth, RADIUS tramite modulo) stabiliscono connessioni TLS con il certificato corretto.
• Il comando wikidctl restart non fallisce dopo aver inserito la passphrase.
• I log non mostrano errori di validazione del certificato per client autorizzati.

Casi di test e criteri di verifica

1. Test della CSR

   • Azione: generare la CSR e verificare che la textarea contenga il blocco BEGIN/END in base64.
   • Criterio: la CSR può essere incollata nella pagina di sottomissione e viene accettata.

2. Test della firma da CA

   • Azione: inviare CSR, ricevere certificato via email e importarlo.
   • Criterio: importazione completata senza errori; la CA intermedia è elencata.

3. Test del certificato localhost

   • Azione: generare certificato con FQDN “localhost” e verificare che i servizi locali usino quel certificato.
   • Criterio: connessioni locali (es. LDAP interno) stabiliscono TLS senza errori.

4. Test di riavvio

   • Azione: wikidctl restart e inserimento della passphrase.
   • Criterio: servizi si avviano; non vengono richieste passphrase non previste; nessun errore nei log.

Playbook operativo per amministratori (SOP)

Passaggi rapidi per un amministratore di sistema:

1. Backup: fare snapshot della VM e backup dei file di configurazione /etc/WiKID.
2. Generare CA intermedia: compilare il modulo con dati validi e una passphrase forte.
3. Copiare la CSR e inviarla tramite la pagina della CA WiKID.
4. Ricevere e salvare il certificato firmato come file .crt in una posizione sicura.
5. Importare il certificato nell’interfaccia web e fornire la passphrase del keystore.
6. Generare e installare il certificato per “localhost” se necessario.
7. Riavviare i servizi: wikidctl restart e inserire la passphrase.
8. Verificare i log e le connessioni TLS.

Rollback rapido se qualcosa va storto:

• Se la passphrase è errata e la rigenerazione non è possibile, ripristinare snapshot e ripetere la procedura generando una nuova CA intermedia.
• Se i servizi non ripartono dopo il riavvio, ripristinare i file di configurazione dal backup e riavviare.

Procedure di risoluzione problemi comuni

• Errore: “passphrase non valida” durante l’installazione o il riavvio

  • Verificare la passphrase inserita; se persa, la CA intermedia deve essere rigenerata.

• Errore: “certificato non valido per hostname”

  • Assicurarsi che il FQDN usato dai client corrisponda al Common Name del certificato.
  • Per servizi locali usare esattamente “localhost” se è quello l’hostname risolto.

• Errore: “impossibile connettersi via TLS”

  • Controllare i log del servizio (es. /var/log/wikid) per dettagli.
  • Verificare che la catena di certificazione (intermedia -> root) sia installata.

Checklist per ruoli (amministratore, responsabile sicurezza, operazioni)

Amministratore di sistema

• Backup snapshot VM prima di iniziare
• Generare CSR e conservare la chiave privata in posizione sicura
• Inviare CSR e monitorare il numero di richiesta
• Importare il certificato firmato e verificare l’installazione
• Generare il certificato localhost se richiesto
• Riavviare i servizi e verificare i log

Responsabile sicurezza

• Confermare politica di gestione passphrase
• Verificare permessi su /etc/WiKID/security
• Richiedere audit dei log dopo prima installazione

Team operazioni

• Aggiornare documentazione di runbook con la nuova CA
• Aggiornare inventario dei certificati e date di scadenza
• Pianificare rotazione certificati e procedure di rinnovo

Migrazione e compatibilità

• Versioni del server: verificare le note di rilascio della versione WiKID in uso per eventuali cambiamenti nella gestione dei keystore e delle passphrase.
• Protocolli: RADIUS non supporta certificati nativi; usare i moduli di protocollo forniti per terminare la sessione TLS sul server.
• Hosting: per server in cloud, proteggere il file di keystore e il file /etc/WiKID/security utilizzando meccanismi del provider (es. KMS o secret manager) se disponibile.

Hardening consigliato

• Abilitare l’accesso SSH con chiavi e limitare login password.
• Limitare accesso alla porta di amministrazione web dell’interfaccia (firewall, VPN o bastion host).
• Impostare SELinux/AppArmor se supportato dalla distribuzione.
• Scansionare il server per vulnerabilità e applicare patch regolarmente.

Privacy e note GDPR (se si processano dati personali)

• Conservare l’indirizzo email dell’amministratore CA in modo conforme alle politiche di trattamento dati personali.
• Se il certificato include dati personali (es. email), assicurarsi che vengano trattati secondo le norme locali e che l’accesso sia minimizzato.

Esempi di output e snippet utili

Riavvio del servizio wAuth:

# Eseguire come root
wikidctl restart

Creare il file di passphrase (solo se si accetta il rischio operativo):

# File: /etc/WiKID/security
# Proteggere con chmod 600
WAUTH_PASSPHRASE=tuapassphrase

Impostare permessi sicuri:

chown root:root /etc/WiKID/security
chmod 600 /etc/WiKID/security

Errori noti e quando la procedura può fallire

• Mancata corrispondenza FQDN: se i client si connettono con un nome diverso da quello del certificato, la validazione fallirà.
• Perdita della passphrase del keystore: obbliga a rigenerare CA e certificati.
• Email certificate bloccata o alterata: incollare come testo semplice per evitare problemi di codifica.

Piccola metodologia operativa

1. Preparazione: backup, policy passphrase, account di contatto.
2. Esecuzione: generazione CSR, sottomissione, importazione, generazione localhost.
3. Verifica: test con client, controllo log, test di riavvio.
4. Documentazione: aggiornare runbook e inventario certificati.

Glossario (1 riga per termine)

• CSR: richiesta per ottenere un certificato firmato.
• CA intermedia: autorità che firma i certificati per il tuo server.
• PKCS#12: formato che contiene chiave privata e certificato in un file armorizzato con passphrase.
• localhost: nome host di loopback usato per servizi locali.

Riepilogo finale

Seguendo questa procedura si crea una CA intermedia, si genera una CSR, si invia la richiesta alla CA di WiKID, si importa il certificato, si crea un certificato per localhost e si riavvia il servizio wAuth per attivare i certificati. Proteggere le passphrase e i file contenenti le chiavi private. Usare le checklist e il playbook per garantire un’installazione ripetibile e sicura.

Importante: la perdita della passphrase del keystore obbliga alla rigenerazione della CA intermedia e dei certificati.