Fix for issue 857: RFC-7230 compliant forwarding of client certificates

Flemming Frandsen at
Fri Nov 25 14:06:06 UTC 2016

On Fri, Nov 25, 2016 at 12:58 PM, Maxim Dounin <mdounin at> wrote:

> > 2: No existing parser will handle url decoding of the header without
> > changes, but some might work without the newlines.
> You may want to name a few.

Well, ok, mine worked out of the box, because the server changed newlines
to spaces before I got the value in my application.

I'm using Jetty, which is quite popular in Java circles, so I suspect a lot
of people would be unsurprised to find the newlines replaced by spaces,
like you suggested.

And we already use URL encoding in out mail module, so the are
> good reasons to keep things consistent.

Yes, that's true.

> 3: You don't need to recover the original PEM format as newlines are
> > optional for any reasonable base64 parser.
> They aren't optional at least for OpenSSL itself.

Yes, I think I did find a comment somewhere that said that openssl wanted a
max line length.

> If you're really unhappy with my proposed solution, then I can try to fix
> > up the url encoding patch that was posted earlier, though I still think
> > it's silly to go to such lengths to preserve newlines that nobody wants.
> There is no problem with preparing any patch.  And there
> were already quite a few.

>From where I sit it looks like this problem was reported about a year ago
without any solution being merged, so I just want try to help things along.

> The main problem here is naming things:
> that is, how things are expected to be named in the future, and how
> transition is expected to look like.  The situation when
> $ssl_client_cert variable is not usable in most if not all cases
> looks at least strange.

I agree wholeheartedly.

So at least urlencoded variant is needed ($ssl_client_escaped_cert?).

Yes, and at least it's consistent with the other solution as you noted.

And the next
> question is what to do with current $ssl_client_cert, as we need
> to preserve compatibility at least somehow for people who
> currently use certificate with tabs added as a multiline header.

I'm afraid I don't know what this means, care to elaborate?
Do you mean people who simply set a header to $ssl_client_cert?

Another possible approach might be to change $ssl_client_cert to
> use spaces (tabs?) instead of newline + tab.  This should be
> compatible with what most servers provide as a result of parsing
> multi-line header, and implies less changes.  This needs an
> additional investigation though.

I'd be very happy with this as the only change as my server already gives
me exactly this value when I ask for the header, so my application would
not even notice the change.

Flemming Frandsen - YAPH - -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx-devel mailing list