Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
certbot http -> https rewrite rules messes up GET params #3243
An issue I encountered today: the rewrite rules added to apache config by certbot-auto to coerce http requests to https doesn't seem to be bulletproof.
In particular, GET params that are url-encoded, eg ?email=testest%2Byhbugfixer%40gmail.com, seem to end up getting encoded twice so that my application receives 'testest%2Byhbugfixer%40gmail.com' for the param value instead of the intended 'email@example.com', if I make the initial request in http://
Notably, this does not happen if in place of the rewrite rules added by certbot-auto, I simply create a new virtual host like so:
hey @sagi ,
Unfortunately I no longer have the "before" configuration files, but I'm pretty sure this is the snippet inserted by certbot to coerce https:
This is the contents of the virtual host file for my domain, if relevant:
Back then, during my research on this I bumped on this thread.
It seems that
I've been meaning to test it out; but didn't get to it.
Also, I believe that a change in escaping / encoding of the query string may harm current
Double-encoding a query is a well known issue with a resolution to use NE. There are cases where NE isn't the answer. However, for a blind wildcard redirect to move a client from http -> https it is important to not alter any part of the URL beyond the protocol (i.e. path, port, query, etc.).
There is no reliable manner for the receiving code to know if the received query string is single url encoded or erroneously double url encoded. Therefore, there is no legit legacy workaround coded by current certbot users. Anything written by someone out there...isn't reliable.
Therefore, the resolution is to fix the core issue which is the use of QSA. It should instead be NE. This will result in...