@henningw @miconda indeed, the full raw PEM-encoded certificate is not currently available via an existing PV.

Thinking through this a little bit more, would you prefer a full certificate access mechanism via something like $tls_peer_raw_cert{s.urlencode.param} instead?

Just to explain where I was coming from, nginx has deprecated access to the raw PEM-encoded certificate, encouraging users to use a new urlescaped cert mechanism instead:

http://nginx.org/en/docs/http/ngx_http_ssl_module.html

It is that avenue of thinking that I created this PR for accessing and urlencoding the URL cert with one PV. In retrospect, nginx's urlencoding of the certificate is probably rooted in use cases that involve wrapping the cert in a header and passing it off to a different system for processing. I did not consider use of the raw PEM-encoded certificate in a kemi-enabled scenario, where $tls_peer_escaped_cert would need to be urldecoded before being asn1parsed (or even re-encoded with some other encoding scheme in pv_trans.c...).

I'll create $tls_peer_raw_cert as a separate PR, since that seems simpler. Does this plan sound good to you?


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.