Hi there,
During a recent upgrade of a client that sends requests to the icinga2 API using python’s urllib3, we noticed some weird TLS validation errors.
Upon further investigation, we figured out, that urllib3 introduced stricter TLS validation (see create_urllib3_context() should set ssl.VERIFY_X509_PARTIAL_CHAIN and ssl.VERIFY_X509_STRICT · Issue #3571 · urllib3/urllib3 · GitHub).
And after digging a bit deeper, we noticed that the default icinga2 CA isn’t compliant to RFC5280.
The CA, which was generated with icinga2 api setup, has no subject key identifier and no authority key identifier in the CA and the certificate that was signed by that CA is missing the AKI as well.
RFC5280 (4.2.1.2 - Subject Key Identifier) states:
To facilitate certification path construction, this extension MUST appear in all conforming CA certificates, that is, all certificates including the basic constraints extension (Section 4.2.1.9) where the value of cA is TRUE.
If you check the icinga2 certificate using openssl x509 -text -noout -in /var/lib/icinga2/ca/ca.crt, you can see that CA:TRUE is present but the CA has no SKI.
Given that “Own CA for Icinga Cluster/API communication?” strongly suggests that people don’t bring their own CA, the CA generated by Icinga2 should be compliant to RFC5280.
Please let me know what you think about this.