Am 11.07.2016 um 10:58 schrieb Stephan Tesch:
Am 2016-07-07 14:52, schrieb Stephan Tesch:Hi everyone, we've solved the problem: the certificates were issued as purely ssl SERVER certificates: X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication, Time Stamping Netscape Cert Type: SSL Server We've changed the certificate to look like this: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication, Time Stamping Netscape Cert Type: SSL Client, SSL Server The error message generated by Icinga is highly confusing. If I issue the openssl command directly, the error message from openssl is pointing into the right direction: # openssl verify -CAfile ca.crt -purpose sslclient server.crt master.example.com: DN = blablabla, CN = master.example.com error 26 at 0 depth lookup:unsupported certificate purpose OK Any chance to get the openssl error included in the Icinga error messsage?
If you can provide a way to reliably test that scenario (certs, configs) and we only need to fiddle with the error message passed inside the code, feel free to open a feature request. Kind regards, Michael
Best regards, StephanDear Icinga Masters, we're about to deploy a simple satellite for our Icinga 2 (2.4.10) setup. The config should be okay, the master is connecting to the satellite, but we're getting the following error message (on the satellite): [2016-07-07 12:25:23 +0000] information/ApiListener: New client connection for identity 'master.example.com' (client certificate not signed by CA) The API configuration on the master looks like this: /** * The API listener is used for distributed monitoring setups. */ object ApiListener "api" { cert_path = SysconfDir + "/icinga2/pki/" + NodeName + ".crt" key_path = SysconfDir + "/icinga2/pki/" + NodeName + ".key" ca_path = SysconfDir + "/icinga2/pki/ca.crt" ticket_salt = TicketSalt } We're using an external CA for the communication. The CA is splitted into Root CA, Intermediate CA, Issuing CA. All three PEM files are contained within /etc/icinga2/pki/ca.crt (on the master and the satellite). Any idea why this happens? The certificates are good, the only thing that comes to my mind is that the certs are also used for the web frontend, so these are SSL server certs with corresponding usage remarks within the certificate. My code reading ability sucks today, so I can't tell if this is really checked within the code or if TlsStream just checks for a valid cert. Any ideas how to debug this? Many thanks, Stephan _______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users_______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
-- Michael Friedrich, DI (FH) Senior Developer NETWAYS GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg Tel: +49 911 92885-0 | Fax: +49 911 92885-77 CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB18461 http://www.netways.de | michael.friedr...@netways.de ** OSBConf 2016 - September - osbconf.org ** ** OSMC 2016 - November - netways.de/osmc ** _______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
