An equivalent of Apache's +ExportCertData in Caddy

[Marian-Kechlibar]

Apache Webserver's mod_ssl has an optional configuration flag +ExportCertData, which is turned off by default (for performance reasons), but when turned on, it populates the superglobals with variables containing the current server and client certificate. To cite from the docs:

When this option is enabled, additional CGI/SSI environment variables are created: SSL_SERVER_CERT, SSL_CLIENT_CERT and SSL_CLIENT_CERT_CHAIN_n (with n = 0,1,2,..). These contain the PEM-encoded X.509 Certificates of server and client for the current HTTPS connection and can be used by CGI scripts for deeper Certificate checking. Additionally all other certificates of the client certificate chain are provided, too. This bloats up the environment a little bit which is why you have to use this option to enable it on demand.

This would be useful in Caddy too, as it would make migration of Apache-optimized apps to Caddy more straightforward. We had a debate with @francislavoie about the functionality here and I made case that it makes sense to have access to the server-side cert as well.

https://caddy.community/t/populating-server-server-cert-and-server-client-cert/26521

He recommended me to start an Issue on GitHub, so here I am. I know next to nothing about Caddy code, so I dare not submit a Pull request for that functionality.

[mholt]

Thanks -- to clarify, it looks like, based on the forum topic, the request is actually for placeholders containing server cert info.

[Marian-Kechlibar]

Yes. it is.

Meanwhile, I was able to use the placeholder for the client certificate, but with some unexpected behavior, which may warrant its own issue...

Namely, when I enter the following into my Caddyfile:

request_header +X-Tls-Client-Cert-Der-Base64 {http.request.tls.client.certificate_der_base64}

the request header gets added even if there is no client cert provided, and populated with the literal "{http.request.tls.client.certificate_der_base64}"

That is unexpected for me. I would expect the header either to be absent, or empty in that case. (If HTTP allows empty headers; IDK). Should I start another topic over that purpose?

[mholt]

Ah, that's because in the header directive(s) only known placeholders are replaced. If there is no client certificate, the placeholder is not set.

We can change this in one of two ways:

• Always replace placeholder-looking substrings, but this is problematic (syntactically) for values that aren't intended to be placeholders (e.g. JSON)
• Replacers return two values: the value, and whether the key (placeholder name) is known. We are evidently returning false to known, when there is no client cert. It is kind of debatable whether that is correct. We could return true as in, we know this placeholder, but do we really if there is no client auth?

I'm leaning towards the second though, if we do make a change.

[Marian-Kechlibar]

Ah, that's because in the header directive(s) only known placeholders are replaced. If there is no client certificate, the placeholder is not set.

We can change this in one of two ways:

• Always replace placeholder-looking substrings, but this is problematic (syntactically) for values that aren't intended to be placeholders (e.g. JSON)
• Replacers return two values: the value, and whether the key (placeholder name) is known. We are evidently returning false to known, when there is no client cert. It is kind of debatable whether that is correct. We could return true as in, we know this placeholder, but do we really if there is no client auth?

I'm leaning towards the second though, if we do make a change.

The second variant feels more natural to me, too.

[steffenbusch]

Can you try this:

@hasClientCert {
       not vars {http.request.tls.client.certificate_der_base64} ""
}
request_header @hasClientCert +X-Tls-Client-Cert-Der-Base64 {http.request.tls.client.certificate_der_base64}

[mholt]

Thanks for the workaround @steffenbusch !

I suppose we could still change the placeholders behavior in the case of client auth missing.