Cannot decode OpenSSL-formatted X-Client-DN 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 DN to be passed into a request to the master via an X- header, e.g., X-Client-DN, when allow-header-cert-info is set to true.

Via the puppetlabs/certificate-authority library, Puppet Server is using a BouncyCastle-based routine to pull the CN value from the DN string. This BouncyCastle routine works fine so long as the string to decode is compatible with DN formats from RFC 2253, e.g., the value "myhost" would be pulled from an original DN of CN=myhost, OU=blah. If the DN format follows the custom "OpenSSL" style, e.g., /CN=myhost/OU=blah, however, the BouncyCastle routine will fail to decode the CN. Puppet Server will then treat the corresponding request as "unauthenticated", leading any functionality that the request tries to perform which requires authentication to fail.

When a request is routed through an Apache web server mod_proxy, the web server's VirtualHost may inject an X-Client-DN header like this....

RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e

With this approach, the X-Client-DN header value sent to Puppet Server master will use the OpenSSL DN style, which leads to the failure above. The same failure would not occur with a Ruby master being hosted by Apache/Passenger as the Ruby master implementation supports decoding DNs either from RFC 2253 or OpenSSL style formats.

For backward compatibility with Apache Passenger mod_proxy being able to forward "authenticated" requests to a Ruby master, Puppet Server should be enhanced to support decoding the OpenSSL-style DN.