Interesting. I think the problem is the PEM is not URL encoded, so I think it's complaining about certain characters contained there. I think likely + and /.

@gdhameeja I think we might need another placeholder, certificate_pem_urlencoded or something like that.

Right. Will take this up and add the placeholder.

Why does it need to be URL encoded in an HTTP header?

Taking another quick look at why this happens, I think it's because of the newlines rather than +/. Seems like headers can't have newlines.

That might be more accurate. It is true that header values can't have raw new lines; I bet Apache is escaping them. Our header manipulation should probably do the same thing.

Edit: Wait, shouldn't Go (std lib) already be escaping it for us?

Looks like it hits this check: https://godoc.org/golang.org/x/net/http/httpguts#ValidHeaderFieldValue

in https://golang.org/src/net/http/transport.go

I'm not certain how to decipher that 🤔

Edit: Yeah isCTL() rejects \n as it's ASCII value is 10 (it rejects 0-31 and 127)

Edit2: Looks like HTTP headers use \r\n (CRLF) for newlines.

Looks like nginx solves this by providing two variables (one of which is deprecated):

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

The deprecated one used \t to replace the newlines, and the new one URL encodes. I think we should provide a URL encoded option for use in headers, similarly to nginx.

Following their lead on the naming, I think certificate_pem_escaped would do.

It's weird to URL-encode a header value though.

Is there any other option that's more elegant? What if we just strip the header/footer lines and remove all the newlines? To clarify, this means that the header value is basically just the base64-encoded DER content of the certificate. That should suffice. If the upstream really wants PEM they can tack headers on the front and back and then add newlines if they want it to look pretty.

(I'll also add that communicating a certificate via a header is just plain weird.)

I don't see the harm in URL encoding it personally. It'll be more compatible with existing applications written to support the approach Apache and Nginx take with passing through certificates via headers.

If we do the DER approach then it should be called certificate_der, but I don't see the harm in adding certificate_pem_escaped for those that want it that way.

If we do the DER approach then it should be called certificate_der

Let's do that then. It will solve the problem and won't introduce any unnecessary weirdness into the code base. URL-encoding base64 just seems odd to me. We don't need to urlencode it: just use the base64.

I'll get around to implementing this sooner or later, unless someone would like to get to it first!