Nazwa hosta marionetki nie pasuje do certyfikatu serwera

Próbuję skonfigurować maszynę Wirtualną Ubuntu z zainstalowaną marionetką, aby móc lokalnie przetestować naszą konfigurację produkcyjną. Mam problem z nakłonieniem nauczyciela i kukiełki do rozmowy. Pozwól, że przeprowadzę cię przez moje kroki. (Serwer hostnameto nazwa FQDN formatu „web1.xxx.xxx.net”).

Po pierwsze, usuwam z /etc/puppet/sslkatalogu wszystkie pliki pem (z wyjątkiem oczywiście pemów CA), aby móc zacząć od nowa. puppetca --listnie zwraca wyników.

Następnie biegnę, puppetd --testaby wygenerować CSR dla marionetkowego nauczyciela. puppetca --listteraz zawiera moją nazwę hosta („web1.xxx.xxx.net”).

Potem biegnę puppetca --sign web1.xxx.xxx.net. Teraz puppetca --listznów jest pusty - wszystko działa dobrze.

W końcu puppetd --testznów biegnę . Otrzymuję następujące dane wyjściowe:

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

Lista zawartości /etc/puppet/sslkatalogu pokazuje pliki PEM z poprawną nazwą serwera, która pasuje do mojego hostname. Czy ktoś ma jakieś pomysły, jak zaatakować ten problem?

Błąd jest taki, że klient domyślnie łączy się z nazwą hosta serwera „marionetka”, ale przedstawiony certyfikat nie ma „marionetki” ani jako podmiotu, ani jako atrybutu podmiotu.

Aby to naprawić, możesz (wybrać jeden):

1. zamiast inicjować certyfikat twojego puppetmaster przez uruchomienie puppetd, zainicjuj go przez uruchomienie puppetmasterd- spowoduje to, że nazwa podmiotu certyfikatu będzie zawierać „puppet”.

2. zamiast pozostawiać rzeczy przypadkowi, których możesz użyć puppetca --generate --certdnsnames puppet:puppet.mydomain.com web1.xx.xx.xx.net- opcja certdnsnames określa listę SubjectAltNames, które będą zawarte w certyfikacie; powinna mieć oddzieloną dwukropkami listę dowolnej nazwy , której klient użyłby do skontaktowania się z serwerem.

3. zamiast po prostu uruchamiać puppetd --testsię na kliencie, uruchom, puppetd --test --server=web1.xx.xx.xx.netaby nazwa serwera, z którą łączy się klient, była taka, która faktycznie istnieje w certyfikacie przedstawionym przez serwer.

Zapoznaj się z doskonałym wpisem na blogu masterzen w celu uzyskania dalszych informacji na temat rozwiązywania problemów: objaśniono obsługę protokołu Puppet SSL

Czy sprawdziłeś plik dziennika puppetmaster? Znalazłem ten sam problem i stwierdziłem, że serwer rejestruje informacje o certyfikacie:

[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

Pole Temat pokazuje, że CN to „ubuntu.localdomain”, więc wykonałem lalkę, wykonując:

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

Mam nadzieję że to pomoże :-)

Oprócz tego, co odpowiedział Pau, chciałbym tylko podkreślić, że możesz sprawdzić certyfikat lalek za pomocą:

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

Następnie upewnij się, że używasz dokładnie tej samej nazwy hosta, gdy pochodzi od klienta:

puppetd --server <hostname_of_puppet_master> <etc>

Czy oba serwery potrafią się rozwiązać? Domyślam się, że skoro używasz maszyny wirtualnej, możesz nie rozpoznawać nazw. Jeśli nie korzystasz z DNS, aby umożliwić serwerom wzajemne rozwiązywanie się, musisz dodać wpisy do /etc/hostspliku na obu serwerach.

Puppet wymaga, aby nazwy hostów rozpoznały prawidłowe adresy IP, bez tego otrzymasz błąd, o którym wspomniałeś. Po wykonaniu tej czynności może być konieczne ponowne utworzenie certyfikatów. Oba komputery powinny mieć możliwość pingowania każdego według nazwy hosta.

Inną rzeczą, na którą należy uważać w przypadku maszyn wirtualnych, jest synchronizacja czasów na serwerach. Jeśli tego nie zrobisz, prawdopodobnie certyfikaty będą nieważne.