Note: This is a reference to a longer thread on https://monitoring-portal.org/t/client-certificate-validation-failed/5732/36
CSR auto-signing doesn’t seem to be working for me and for a bunch of other people in the thread above. We’re unsure whether that’s a real problem or a PEBKAC issue.
Steps to reproduce:
1 (client):
icinga2 pki new-cert --cn centos3
--key /var/lib/icinga2/certs/centos3.key
--cert /var/lib/icinga2/certs/centos3.crt
2 (client):
icinga2 pki save-cert
--key /var/lib/icinga2/certs/centos3.key
--cert /var/lib/icinga2/certs/centos3.crt
--trustedcert /var/lib/icinga2/certs/trusted_parent.crt
--host centos1
3 (master):
icinga2 pki ticket --cn centos3
abcb8df38495227d47aa81e6ba17196bd98c102a
4 (client):
icinga2 node setup
--cn centos3
--ticket abcb8df38495227d47aa81e6ba17196bd98c102a
--endpoint centos1
--trustedcert /var/lib/icinga2/certs/trusted_parent.crt
--zone centos3
--parent_zone master
--parent_host centos1
--accept-commands
--accept-config
--disable-confd
From what I understand (https://icinga.com/docs/icinga2/latest/doc/06-distributed-monitoring/#node-setup-with-satellitesclients) this should result in centos3
receiving a certificate signed by our CA, the master (centos1
in this case), but in fact, the certificate that is received and written (see here below) is still self-signed:
[root@centos3 certs]# openssl x509 -in centos3.crt -text -noout | grep Issuer
Issuer: CN=centos3
[root@centos3 certs]# openssl x509 -in centos3.crt.orig -text -noout | grep Issuer
Issuer: CN=centos3
Result:
Client:
information/cli: Requesting certificate with ticket 'abcb8df38495227d47aa81e6ba17196bd98c102a'.
information/cli: Verifying parent host connection information: host 'centos1', port '5665'.
information/cli: Using the following CN (defaults to FQDN): 'centos3'.
information/base: Writing private key to '/var/lib/icinga2/certs//centos3.key'.
information/base: Writing X509 certificate to '/var/lib/icinga2/certs//centos3.crt'.
information/cli: Verifying trusted certificate file '/var/lib/icinga2/certs/trusted_parent.crt'.
information/cli: Requesting a signed certificate from the parent Icinga node.
information/cli: Writing CA certificate to file '/var/lib/icinga2/certs//ca.crt'.
information/cli: !!!!!!
information/cli: !!! Certificate request for CN 'centos3' is pending. Waiting for approval from the parent Icinga instance.
information/cli: !!!!!!
Master (debuglog):
[2019-07-25 20:35:22 +0200] information/ApiListener: New client connection for identity 'centos3' from [10.24.1.190]:33236 (certificate validation failed: code 18: self signed certificate)
[2019-07-25 20:35:22 +0200] notice/JsonRpcConnection: Received 'pki::RequestCertificate' message from 'centos3'
[2019-07-25 20:35:22 +0200] information/JsonRpcConnection: Received certificate request for CN 'centos3' not signed by our CA.
[2019-07-25 20:35:22 +0200] information/JsonRpcConnection: Certificate request for CN 'centos3' is pending. Waiting for approval.
[2019-07-25 20:35:22 +0200] warning/JsonRpcConnection: API client disconnected for identity 'centos3'
[2019-07-25 20:35:24 +0200] information/ApiListener: Reconnecting to endpoint 'centos3' via host '10.24.1.190' and port '5665'
[2019-07-25 20:35:24 +0200] information/ApiListener: Finished reconnecting to endpoint 'centos3' via host '10.24.1.190' and port '5665'
I don’t see why the master wouldn’t accept the ticket and return a signed certificate. Can I maybe increase verbosity somewhere to see the actual negotiation on the master where it refuses the ticket?
Is it supposed to complain about the CSR not being signed by our CA?
[…]
[2019-07-25 20:35:22 +0200] information/JsonRpcConnection: Received certificate request for CN 'centos3' not signed by our CA.
[…]
I have, btw, the very same result when I use icinga2 node wizard
on the client.
Versions:
- OS: centos 7.6.1810 (Core)
- icinga2: 2.10.5 release 1.el7.icinga
- openssl: 1.0.2k release 16.el7
P.S. Out of curiosity, I tried this with 2.11-rc1 this morning and the behavior is exactly the same. As someone pointed out above, it might not be related to the icinga2 packages, but without increased verbosity during the failing CSR auto-signing process, we’re kind of stuck here.