Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #9549] Generated certificates cannot be verified w/ openssl 0.9.8j on SLES 11 #3118
This issue has been migrated from Redmine: https://dev.icinga.com/issues/9549
Created by twidhalm on 2015-07-02 20:49:37 +00:00
On SLES 11 SP3 openssl is available in version 0.9.8j-0.70.1 . It seems this version can not deal with the default hashing algorithm of the Icinga 2 CA SHA256 (which was introduced in Issue #7434 ) .
When building a cluster connection, there is one try reported in the logs that says, the connection is unauthenticated and then no more log entries according this connection. (Issue #9489 will fix the missing logevents) When creating a CA to generate all Certificates for all nodes connections are made but the logs of the Agent / Satellite (not on the master) still say the connection is "unauthenticated" although it retries to create a connection regularly. When changing the direction in which the connection is made (by changing the endpoint configuration in zones.conf) you still see the unauthenticated messages it only changes on which Node the reconnection is logged.
When adding the "cluster" and "cluster-zone" check on both nodes, the master says, the satellite zone and endpoint are connected (verified by seeing an alert, when the satellite ist shut down) and the satellite says both zone and endpoint of the master are disconnected at the same time. No configuration (not even global zones) are copied to the satellite.
I've sent some logs and more information directly to Gunnar and I know some people who had the same problem with the same combination Icinga 2.3.5 on SLES 11 SP3, so if you need more information, tell me what you need and I will try to provide it.
2015-07-06 09:43:26 +00:00 by (unknown) 6810737
2015-07-06 11:37:39 +00:00 by (unknown) 3c1aec4
2015-07-06 11:47:48 +00:00 by (unknown) eac73e1
2015-07-07 07:20:12 +00:00 by (unknown) ecd9876
2015-07-07 07:20:32 +00:00 by (unknown) 86b5e20
Updated by mfrosch on 2015-07-03 07:29:02 +00:00
The actual problem seems to have been caused by #8844 - which fixed another Issue with OpenSSL on SuSE.
Whats really bothering me, what OpenSSL are we linking against, when EVP_sha256() seems to be resolved in the ABI.
What version of OpenSSL is the user in #8844 using, and what version here...
Updated by mfriedrich on 2015-07-03 15:29:32 +00:00
CreateCert() with EVP_sha256 fixed in #8844 is called in CreateCertIcingaCA() which gets invoked to request a client certificate in RequestCertificateHandler().
EVP_sha256 was introduced with 0.9.8 and is not available in 0.9.7.
So we build and link against a valid source, but there is a problem with openssl 0.9.8j on SLES11SP3 regarding the verification preventing preverify_ok being set to 1.
Calling those hash functions specifically would somehow explain the segfault encountered with #8844 having that set to NULL previously without initialization of the algorithms.
A slightly different approach is to add the cipher
Although this might require a version check as well.
Update SLES11 packages
SLES provides openssl1 as package inside its security repository. Changing the package requirements and rebuilding the packages linking to openssl 1.0+ will solve the problem.
In terms of the ABI, I don't see an issue here.
I wouldn't go for a simple patch solution only, but rather enforce users to use a more recent openssl library version where we may link against for sles11 sp3 (we're doing that already for boost153 too).
In any attempt, this requires proper tests and feedback on that ancient platform.
Please test the attached patch on your sles11 platform.
Updated by mfrosch on 2015-07-03 16:26:15 +00:00
Since SHA1 should really be deprecated, and is declared to by many vendors, we should keep sha256.
The initialization issue is rather weird, but well, OpenSSL API...
Old platforms like Debian squeeze, RH 5 and SLES 11 SP3(!) seems to support that.
Even on weird platforms the user should make sure to have a secure OpenSSL version...
Updated by mfriedrich on 2015-07-05 17:47:41 +00:00
Applying the patch to a freshly installed sles11sp3 vagrant box environment does not resolve the issue, unfortunately.
The generated client certificate signed with the master's ca is still invalid.
Maybe related for leading zeros and encoding, but our serial is just an integer.
It seems that sha-2 is not available regardless what you specify on the command line.
Test with custom openssl1
Building the icinga2 package against openssl1 from an external repository seems to make it work. Although that proof-of-concept needs to be redone with the sles11 openssl1 package being officially supported.
Only the master setup:
Going further to the client
Master-Client communication exchanging check results also works (after invoking node update-config on the master and restart the service).
The possible safest solution is to enable the sles updates with the security repository and change the spec file to require openssl1-devel. There's a pending request for that already for gcc47 in #9560.
Updated by mfriedrich on 2015-07-06 11:43:39 +00:00
Link against openssl1 packages from Security Module.
Updated by mfriedrich on 2015-07-06 12:29:03 +00:00
The problem is the certificate generation (master, or CSR auto-signing). All certificates generated with 0.9.8j are invalid and cannot be verified - that needs to be re-done with an uptodate icinga2 version linking against openssl1
Updated by mfriedrich on 2015-07-06 14:36:48 +00:00