Il nome host del pupazzo non corrisponde al certificato del server

Sto cercando di configurare una VM Ubuntu con il pupazzo installato in modo da poter testare localmente la nostra configurazione di produzione. Ho dei problemi a far parlare il burattinaio e il burattinaio. Lascia che ti accompagni attraverso i miei passi. (Il server hostnameè un nome FQDN del formato "web1.xxx.xxx.net").

Quindi, in primo luogo, elimino tutti i file pem (tranne ovviamente i pem CA) dalla /etc/puppet/ssldirectory in modo da poter ricominciare da capo . puppetca --listnon restituisce risultati.

Quindi, corro puppetd --testper generare un CSR per il burattinaio. puppetca --listora include il mio nome host ("web1.xxx.xxx.net").

Quindi corro puppetca --sign web1.xxx.xxx.net. Ora puppetca --listè di nuovo vuoto - tutto funziona bene finora.

Infine corro di puppetd --testnuovo. Ottengo il seguente output:

err: Could not retrieve catalog from remote server: hostname was not match with the server certificate
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

L'elenco dei contenuti della /etc/puppet/ssldirectory mostra i file PEM con il nome server corretto, che corrisponde a my hostname. Qualcuno ha qualche idea su come attaccare questo problema?

L'errore è dovuto al fatto che il client si connette per impostazione predefinita al nome host del server "fantoccio" ma il certificato presentato non ha "fantoccio" né come oggetto né come attributo SubjectAltName.

Per risolverlo, puoi (scegline uno):

1. invece di inizializzare il certificato del tuo burattinaio eseguendolo puppetd, inizializzalo eseguendo puppetmasterd- questo farà sì che il nome del soggetto cert includa "burattino".

2. invece di lasciare le cose al caso che puoi usare puppetca --generate --certdnsnames puppet:puppet.mydomain.com web1.xx.xx.xx.net- l'opzione certdnsnames specifica un elenco di SubjectAltNames che saranno inclusi nel certificato; dovrebbe avere un elenco separato da due punti di qualsiasi nome che un client userebbe per contattare il server.

3. invece di eseguire solo puppetd --testsul client, eseguire in puppetd --test --server=web1.xx.xx.xx.netmodo che il nome del server a cui si connette il client sia quello esistente nel certificato presentato dal server.

Dai un'occhiata all'eccellente post di blog di masterzen per ulteriori informazioni sulla risoluzione dei problemi: Spiegazione di Puppet SSL

Hai controllato il file di registro del burattinaio? Ho riscontrato lo stesso problema e ho riscontrato che il server registra le informazioni sul certificato:

[2012-02-28 16:21:09] INFO  
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=ca
        Validity
            Not Before: Feb 26 16:32:46 2012 GMT
            Not After : Feb 24 16:32:46 2017 GMT
        Subject: CN=ubuntu.localdomain

Il campo Oggetto mostra che la CN è "ubuntu.localdomain", quindi ho eseguito il pupazzo facendo:

puppetd -t --server=ubuntu.localdomain --fqdn=myfqdn

Spero che sia di aiuto :-)

Oltre a ciò che Pau ha risposto, vorrei solo evidenziare che è possibile ispezionare il certificato di burattinai usando:

openssl x509 -text -in /var/lib/puppet/ssl/certs/<hostname_of_puppet_master>

Quindi assicurati di utilizzare lo stesso nome host esatto quando dal client:

puppetd --server <hostname_of_puppet_master> <etc>

Entrambi i server sono in grado di risolversi a vicenda? La mia ipotesi è che, poiché stai eseguendo il VMing, potresti non avere la risoluzione dei nomi. Se non si utilizza DNS per consentire la risoluzione reciproca dei server, è necessario aggiungere voci al /etc/hostsfile su entrambi i server.

Puppet richiede che i nomi host si risolvano con gli IP corretti, senza questo otterrai l'errore che hai citato. Potrebbe essere necessario ricreare i certificati dopo aver fatto questo. Entrambe le macchine dovrebbero essere in grado di eseguire il ping ciascuna per nome host.

Un'altra cosa a cui bisogna fare attenzione con le macchine virtuali è che si sincronizzano i tempi sui server. In caso contrario, è probabile che i certificati non siano validi.