[RISOLTO] Cambio nome dominio

[capovolgimento]

Ciao a tutti,

Questo fine settimana ho cambiato il mio DNS e il nome di dominio SAMBA (ancora in modalità NT4). Da allora, gli agenti sono visibili come connessi nella console, ma quando provo a forzare un aggiornamento su uno di essi, ricevo il seguente messaggio:

Codice: Seleziona tutto

C:\Program Files (x86)\wapt>wapt-get update
2024-03-27 11:22:21,305 ERROR Certificate check failed for https://svwapt.nouveaudom/wapt/Packages and verify_cert C:\Program Files (x86)\wapt\ssl\server\svwapt.anciendom.crt
2024-03-27 11:22:21,305 CRITICAL Error merging Packages from wapt into db: None: None
2024-03-27 11:22:21,336 CRITICAL Error merging Packages from wapt-host into db:None : None
Using config file: C:\Program Files (x86)\wapt\wapt-get.ini
Update package list from https://svwapt.nouveaudom/wapt, https://svwapt.nouveaudom/wapt-host
Total packages : 120
Added packages :

Removed packages :

Discarded packages count : 0
Pending operations :
  install:
  upgrade:
  additional:
  remove:
  immediate_installs:
Repositories URL :
  wapt
  wapt-host

C:\Program Files (x86)\wapt>

Il messaggio è chiaro: c'è un problema con l'autenticazione e con il certificato che fa riferimento al vecchio dominio.
Ho trovato una pagina sul wiki che spiega come rigenerare i certificati in caso di furto o smarrimento, ma ho l'impressione che questo riguardi il certificato utente e non quello utilizzato dal server per comunicare con gli agenti.

Esiste una procedura specifica?

Grazie in anticipo.
Filippo.

[dcardon]

Ciao Philippe,

stai usando un certificato autofirmato o un certificato pubblico (Let's Encrypt, ecc.)?

Sembra che tu abbia `verify_cert=1` nel tuo file `wapt-get.ini` e che il nome del server nel certificato non corrisponda a quello nella configurazione. Puoi risolvere temporaneamente questo problema impostando `verify_cert=0` mentre aggiorni le impostazioni del certificato.

Stai usando il pinning del certificato? Ovvero, hai `verify_cert=c:\program files (x86)\wapt\ssl\moncertif.crt`?

Su un server Linux, i certificati HTTPS sono memorizzati in `/opt/wapt/waptserver/ssl` se vuoi aggiornarli per riflettere il tuo nuovo nome del server. Tuttavia, se stai usando il pinning, questo non risolverà il problema.

Se si trattava solo di un test e non hai ancora effettuato il deployment in produzione, puoi aspettare la prossima versione. Nel file postconf, abbiamo integrato la possibilità di creare un sottocertificato con il nuovo nome del server nel campo subjectAltName, il che dovrebbe risolvere il problema in questo caso.

Cordiali saluti,

Denis

[capovolgimento]

Buongiorno,

Grazie per la risposta.

Stai utilizzando un certificato autofirmato o un certificato pubblico (Let's Encrypt, ecc.)?

È autofirmato

Sembra che nel file `wapt-get.ini` sia presente `verify_cert=1` e che il nome del server nel certificato non corrisponda a quello nella configurazione. Puoi risolvere temporaneamente il problema impostando `verify_cert=0` durante l'aggiornamento delle impostazioni del certificato.

Stranamente, in `verify_cert` ho il percorso locale dell'agente al certificato. Per testarlo, l'ho impostato su 0 e ho ripreso il controllo dell'agente di test nella console.

Stai utilizzando il pinning del certificato? Cioè, hai un file verify_cert=c:\program files (x86)\wapt\ssl\moncertif.crt?

Lo supponevo, in base alla risposta alla tua domanda precedente

Sul server Linux, i certificati HTTPS sono archiviati in /opt/wapt/waptserver/ssl, se si desidera aggiornarli in modo che riflettano il nuovo nome del server. Tuttavia, se è presente il pinning, il problema non verrà risolto.

Non ho una rete di grandi dimensioni, quindi posso distribuire manualmente il nuovo certificato agli agenti. Il certificato richiede una configurazione specifica per WAPT o è sufficiente un certificato standard?

Se si trattava solo di un test e non hai ancora eseguito la distribuzione in produzione, puoi attendere la prossima release. Nel postconf, abbiamo integrato la possibilità di creare un sottocertificato con il nuovo nome del server nel subjectAltName, il che dovrebbe risolvere il problema in questo caso.

Come si dice: "Troppo tardi!"

[dcardon]

Ciao Philippe,

se hai Active Directory, puoi ripristinare l'agente aggiornato con le impostazioni modificate.

Per quanto riguarda il certificato HTTPS autofirmato, se elimini/sposti i certificati in /opt/wapt/waptserver/ssl, verranno generati nuovi certificati utilizzando il nuovo nome del server. Devi controllare attentamente l'output di `hostname -f` per ottenere il FQDN, che deve essere incluso nel file `wapt-get.ini` sugli agenti. Quindi, blocca il certificato corretto (`wapt-get enable-check-certificate`) oppure imposta `verify_cert=0`.

Cordiali saluti,

Denis