-
Notifications
You must be signed in to change notification settings - Fork 573
-
Notifications
You must be signed in to change notification settings - Fork 573
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[dev.icinga.com #9549] Generated certificates cannot be verified w/ openssl 0.9.8j on SLES 11 #3118
Comments
Updated by mfriedrich on 2015-07-02 21:25:30 +00:00 Pleas add logs, configuration and cli output directly to this issue so that others may also look into this issue, not only Gunnar. Thanks. |
Updated by twidhalm on 2015-07-02 22:21:35 +00:00
I added excerpts of debug.log and icinga2.log of both hosts here (anonymised). Most of the events just repeat themselves, so I uploaded just a part of them. |
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 mfrosch on 2015-07-03 07:29:11 +00:00
|
Updated by mfriedrich on 2015-07-03 07:31:34 +00:00
|
Updated by mfriedrich on 2015-07-03 07:32:15 +00:00
|
Updated by mfriedrich on 2015-07-03 08:10:43 +00:00
|
Updated by mfriedrich on 2015-07-03 15:29:32 +00:00
AnalysisCreateCert() 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. SHA-2 supporthttps://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility
Calling those hash functions specifically would somehow explain the segfault encountered with #8844 having that set to NULL previously without initialization of the algorithms. http://linux.die.net/man/3/openssl\_add\_ssl\_algorithms
A slightly different approach is to add the cipher http://lists.freebsd.org/pipermail/freebsd-bugs/2009-August/036249.html
Although this might require a version check as well.
Update SLES11 packagesSLES 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. More materialMore on that topic on the internet: https://projects.puppetlabs.com/issues/21029#note-3 ConclusionI 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.
Available CiphersIt seems that sha-2 is not available regardless what you specify on the command line.
Test with custom openssl1Building 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). ConclusionThe 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
SolutionLink against openssl1 packages from Security Module. |
Updated by mfriedrich on 2015-07-06 11:45:00 +00:00
|
Updated by Anonymous on 2015-07-06 11:45:03 +00:00
Applied in changeset 3c1aec4. |
Updated by mfriedrich on 2015-07-06 11:51:32 +00:00
Requires Changelog entry for 2.3.6 |
Updated by mfriedrich on 2015-07-06 12:29:03 +00:00 UpgradingThe 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 Old:
new
|
Updated by mfriedrich on 2015-07-06 14:36:48 +00:00 Tests
|
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
Assignee: mfriedrich
Status: Resolved (closed on 2015-07-06 11:45:03 +00:00)
Target Version: 2.3.6
Last Update: 2015-07-06 14:36:48 +00:00 (in Redmine)
Hi,
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.
Cheers,
Thomas
Attachments
Changesets
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
Relations:
The text was updated successfully, but these errors were encountered: