|
I'd bet yes, otherwise you probably wouldn't have this issue.
But to verify, according to that StackOverflow post, if the key starts with
-----BEGIN PRIVATE KEY-----
it's from the "new" format, while if starts with
-----BEGIN RSA PRIVATE KEY-----
it's from the old format (though the post has the wrong capitalization). I verified that my key used indeed the new format, and is indeed from a "new" openssl:
# openssl version
OpenSSL 1.0.1f 6 Jan 2014
(Warning: For the old format, I'd guess you could also find DSA there instead of RSA, depending on the key algorithm).
I found a more complete description of the situation in this post: http://stackoverflow.com/q/20065304/53974. The "new" format is PKCS #8, the "old" format is PKCS #1. In the old format, the key algorithm (RSA or DSA) is described in the header; in the new format, this info is not in the header but in an extra field in the base64 content. While parsing the content, Jenkins produced the exception we see because of this extra field. That post links to further details.
Issue Summary/Possible Diagnosis
To sum up the issue (as we understand), Jenkins only accepts the PKCS #1 format, and OpenSSL used to produce that by default, but now produces PKCS#8, and Jenkins cannot handle the latter format. There is a workaround which fits this hypothesis, that worked (up to now) for the only user who tested it. More experiments are needed to confirm the explanation.
Acks
Kudos to andrew finkenstadt for finding the essential bit of info, and the workaround (I haven't tried to verify it). I've just put together a summary. Caveat: I'm no PKCS format expert.
|
