vault Vault do not return a new line at the end of an rfc7468 encoded certificate

Describe the bug Vault do not return a final newline at the end of the certificate. This is specified by rfc7468 and it state that an eol is expected at the end of each PEM block

To Reproduce Steps to reproduce the behavior:

follow the steps in vault learn site
notice when requesting a certificate that it don't end with \n at the end

Expected behavior Each certificate returned by vault need to have new line at the end of the PEM

Environment:

Vault Server Version (retrieve with vault status): v1.7.3
Vault CLI Version (retrieve with vault version): v1.7.3
Server Operating System/Architecture: any

Additional context This issue was reported for consul when using vault provider 8178 we created a fix that mitigate the problem in consul side 10411 but we would like to have it fixed in Vault.

Jun 29 '21 02:06 dhiaayachi

hi everyone, can I pick this up.

Sep 07 '21 05:09 arjunagl

hi everyone, can I pick this up.

That'd be great, thanks @arjunagl .

Sep 07 '21 12:09 ncabatoff

@ncabatoff how do I assign the issue to my name.

Sep 08 '21 06:09 arjunagl

@arjunagl We don't generally assign issues. Just create a PR and reference the issue in your description.

Sep 08 '21 12:09 ncabatoff

Hello, I have a problem with openshift router.

We are using certmanager to provide certificates to the default ingress controller in OpenShift. Openshift converted the secret to a pem file with no newline between certificate and key.

As a result, we got the following error: [ALERT] 138/102043 (22) : parsing [/var/lib/haproxy/conf/haproxy.config:117] : 'bind 127.0.0.1:10444' : unable to load SSL private key from PEM file '/var/lib/haproxy/router/certs/default.pem'. [ALERT] 138/102043 (22) : parsing [/var/lib/haproxy/conf/haproxy.config:154] : 'bind 127.0.0.1:10443' : unable to load SSL private key from PEM file '/var/lib/haproxy/router/certs/default.pem'.

Is there any information on the timing of the elimination of this problem?

Sep 13 '21 13:09 spanarek

I'm currently working on this, but I am sorry I cannot give you an exact time since I work on this during my spare time and I'm new to the project and code.

Sep 16 '21 05:09 arjunagl

is this issue still open ?

Jul 25 '22 22:07 clock21am

is this issue still open ?

Yes!

Aug 01 '22 13:08 spanarek

Likely adding a new line will break existing deployments, where the absence of a newline is currently expected. A new format=rfc7468 option will need to be added to support this, hence moving to enhancement.

Jun 21 '23 22:06 cipherboy

Likely adding a new line will break existing deployments, where the absence of a newline is currently expected.

Since the PEM format is inherently line-based, it is difficult for me to imagine how someone would write a PEM parser that would break if Vault began to provide the currently-omitted line terminator after the -----END----- line.

I do understand that no change in a public interface like this is absolutely 100% free of risk, but I would rate this change as very much towards the safe end of the spectrum. What makes you rate breakage as "likely" in this case?

Adding a new option that users must know about and use to get conforming more compatible output has a cost of its own, that is paid on an ongoing basis by new users finding the software that little bit harder to use - personally, just adding the newline unconditionally seems best, based on my perception of the balance of probability of issues.

Jun 22 '23 07:06 maxb

@maxb I vaguely recall a particular parser that fails when given multiple new lines between certificates, e.g.:

Here, existing processes would generate a single newline (explicitly) between certificates, and such an update to Vault would introduce a second, which (I thought) could break things.

I was thinking it was Go, but my memory is incorrect it seems: https://go.dev/play/p/nx6te5nad50

OpenSSL seems fine with openssl storeutl -noout -text -certs chain.txt...

Maybe this is a misremembered problem? Looking at RFC 7468, this would need to be a PEM parser that uses multiple stricttextualmsg without allowing additional whitespace between them, which (by my read -- the bundle part is less clear but the parsing of a single cert aspect is clear that it) is explicitly allowed by the RFC...

(E.g., combining:

Files MAY contain multiple textual encoding instances. This is used, for example, when a file contains several certificates. Whether the instances are ordered or unordered depends on the context.

with the definition of stricttextualmsg is what gets me to a chain with only a single newline between certs).

Jun 22 '23 13:06 cipherboy

Ah, I see. I can't deny the possibility of such a parser existing somewhere. It would be a pretty sloppy implementation, but humans write bad code all the time.

On the other hand, the default certificate bundle in Alpine images contains blank lines between successive certificates, so if such a parser does exist anywhere, it doesn't appear to be used in that context, which should rule out such an issue in many more common implementations.

Jun 23 '23 13:06 maxb

vault vault copied to clipboard

Vault do not return a new line at the end of an rfc7468 encoded certificate

vault
vault copied to clipboard