At the moment, when using spring.ssl.bundle.pem property with PEM encoded content, it works fine with what is defined in the PemPrivateKeyParser.java class.
Headers and footers defined as PKCS1_RSA_HEADER and PKCS1_RSA_FOOTER, PKCS8_HEADER and PKCS8_FOOTER, PKCS8_ENCRYPTED_HEADER and PKCS8_ENCRYPTED_FOOTER, SEC1_EC_HEADER and SEC1_EC_FOOTER.
However, most of the time we will have encrypted private keys that does not fit in those predefined keys.
Here is an example of the beginning of the key which can be defined as PKCS1 ENCRYPTED I guess.
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,XXXXXXXXXXXXXXXXXXXXXXXX
When using those types of keys, I get the following error:
"Missing private key or unrecognized format"
Which is thrown from the PemPrivateKeyParser class.
I think the parser cannot parse the two lines after the header.
It would be nice if you could had support for this type of private keys in a near future.
Thank you very much.
Comment From: philwebb
It's quite hard to find useful information on the PEM format, but I think this style is quite old format that was generated by OpenSSL. It looks like Netty had a request to support it at one point as well. See https://github.com/netty/netty/issues/4637. They declined and instead added some docs https://netty.io/wiki/sslcontextbuilder-and-private-key.html.
https://www.rfc-editor.org/rfc/rfc7468 also has the following:
Unlike legacy PEM encoding RFC1421, OpenPGP ASCII armor, and the OpenSSH key file format, textual encoding does not define or permit headers to be encoded alongside the data.
Given those two data points, and the limited resources we have to implement and support the format, I think we need to decline this one. hopefully converting the content as described in https://netty.io/wiki/sslcontextbuilder-and-private-key.html is enough for most users.
Comment From: AlexMeyerPMU
Thank you for your response.