Cannot decode Apache-formatted X-Client-Cert header

Docs impact: This issue is referenced in the documentation/external_ssl_termination.markdown file. Once resolved, it'll need an update.

Puppet Server is intended to support the ability for the client certificate to be passed into a request to the master via an X- header – X-Client-Cert – when allow-header-cert-info is set to true. Puppet Server expects the content in the X-Client-Cert to be a URI-encoded form of the original Base-64 PEM certificate, i.e., with the newline characters from the original certificate replaced with %0A characters.

A VirtualHost configuration in an Apache server, where mod_proxy is used to proxy client requests on to a Puppet master, might inject this header with the following:

RequestHeader set X-Client-Cert %{SSL_CLIENT_S_DN}s

This results in the full content of the client certificate being included in the X-Client-Cert header in the request. Apache, however, does not URI-encode the original content of the certificate. Instead, the spaces inside of the...

-----BEGIN CERTIFICATE-----

and

-----END CERTIFICATE-----

... PEM tags are preserved and newline characters are replaced with spaces as well.

Puppet Server uses functionality from the puppetlabs/certificate-authority library to load the certificate into an X509Certificate object in memory. This library uses BouncyCastle classes to do the loading work. The BouncyCastle classes apparently do not understand spaces in the body of the PEM as being equivalent to newline characters. Any requests routed through Apache which have the X-Client-Cert header appended in the above way will result in the request failing, with the following error being written to the log and returned from the agent request:

Error 400 on SERVER: Unable to parse x-client-cert into certificate: -----END CERTIFICATE not found

In order to overcome this problem and not require further changes to be made in the upstream Apache configuration, Puppet Server could be enhanced to handle decoding the Apache spaces format back to a proper PEM format. This would need to be done in such a way that the URI-encoding method would still be supported, e.g., for non-Apache proxies. This would arguably be a "new feature" for Puppet Server, though, in that if the X-Client-Cert were sent from Apache mod_proxy to a Ruby Puppet master running under Apache/Passenger where no special decoding of the header were provided at the Apache/Passenger layer, the Ruby Puppet master would similarly be unable to handle decoding the certificate and would, therefore, fail the request.