Einige haben erst am 12. Dezember 2012 gemerkt, dass die Zeit einzigartig ist. CAs hingegen wissen das schon seit Längerem und wissen dies auch effektiv zu nutzen. Bei meinem letzten Setup bin ich wieder über diese Falle gestolpert: Die Einrichtung der externen CA und des Puppetmasters ging wie immer ohne Probleme, nur jegliche Zertifikate wollten nicht akzeptiert werden. Wer Puppet einsetzt wird diese Fehlermeldung sofort erkennen:
err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=puppet ]
Wir können in diesem Fall zum einen prüfen, ob unsere CA die selbe ist.
Mit OpenSSL können Zertifikate lesbar dargestellt werden.
openssl x509 -text -noout -in /path/to/ssl/certs/ca.pem | grep Issuer
In dem Output sollte dann eine Zeile mit dem Issuer zu sehen sein und wenn dieser mit der Puppet CA nicht übereinstimmt, müssen deren Einstellungen überprüft werden. Dabei können diese Befehle hilfreich sein.
sudo puppet master --configprint certname
sudo puppet master --configprint ca
Sobald aber hier alles richtig konfiguriert wurde, ist es zum anderen gut ein Auge auf die Zeit zu werfen.
Wenn die Zeit nicht stimmt kann es dazu kommen, dass Zertifikate in der Zukunft ausgestellt werden und diese für die CA keine Gültigkeit besitzen.
Ein einheitlicher Zeitserver kommt diesem Problem entgegen, denn mit ihm vermeiden wir Zertifikate in der Zukunft auszustellen. Wenn dieser nicht vorhanden ist, reicht ein einfaches:
sudo apt-get install ntp
und eventuell ein kurzer Neustart. Danach muss der Puppet Agent neu signiert werden. Dazu müssen alle Zertifikate gelöscht werden.
Auf dem Puppetmaster:
sudo puppet cert clean yourserver.localdomain
Auf dem Client:
sudo rm -rf /path/to/puppet/ssl/* #Default ist /var/lib/puppet/ssl/
Anschließend kann ein neuer Testlauf auf dem Agent ausgeführt werden, der dann ein neues Zertifikat generiert
sudo puppet agent --test
und durch den Puppetmaster validieren lässt.
sudo puppet cert sign yourserver.localdomain
P.S.: Achtet bei eurer Icinga2 HA Installation auch auf die Zeit, hier werden ebenfalls SSL Zertifikate benutzt und unterschiedliche Zeitserver können zu Zeitverschiebungen (im Projekt) führen. 😉
Kritisch: Fehler in Elasticsearch mit JDK22 kann einen sofortigen Stop des Dienstes bewirken
Update Seit gestern Abend steht das Release 8.13.2 mit dem BugFix zur Verfügung. Kritischer Fehler Der Elasticsearch Dienst kann ohne Vorankündigung stoppen. Diese liegt an einem Fehler mit JDK 22. In der Regel setzt man Elasticsearch mit der "Bundled" Version ein....
0 Kommentare
Trackbacks/Pingbacks