Could not reverse map the HTTPS VirtualHost to the original when whitespace in End of File
Certbot throws "Could not reverse map the HTTPS VirtualHost to the original" when trying to parse a vhost file where the last lines after the closing tag are empty (newline) and/or contain a single space in one of those lines.
This error is really unspecific and i spent lots of time trying to fix it. Also the parser should be able to handle it better. There should be a more specific warning on what file and why its failing.
The Issue and resolving it can be found here https://community.letsencrypt.org/t/could-not-reverse-map-the-https-virtualhost-to-the-original/168559/5 but someone else ran into a similar issue earlier here https://community.letsencrypt.org/t/why-cant-i-certbot-d-toastmastervoice-com-and-create-a-new-virtualhost-and-certificate/131544
This seems to work
<VirtualHost *:80>
ServerName md.thorgerjansen.de
DocumentRoot /var/www/html/test
</VirtualHost>
Something like this seems to fail (not sure anymore where the space was, just removed the tailing lines and it suddenly worked)
<VirtualHost *:80>
ServerName md.thorgerjansen.de
DocumentRoot /var/www/html/test
</VirtualHost>
This error is really hard to find and debug and can be really frustrating. Thanks to the people over at community.letsencrypt i solved within 2h what i couldnt solve the day before.
I had a little trouble consistently reproducing this, but I was able to do so. It'd be nice to fix this at some point.
Wow...getting rid of the extra lines at the end worked for me too. Very annoying. Thanks for posting this.
I think this problem might be more extensive. My conf file looked like this:
<VirtualHost *:80>
...
</VirtualHost>
<Directory "/var/www1">
...
</Directory>
the final '>' was followed by a blank line (just 0x0a), and a comment with no preceding WS. The last char in the file was the 0x0a terminating the comment. If I removed the final two lines and ran:
certbot --apache -d example.com -d www.example.com
there was no change; certbot failed with the 'Could not reverse map' message. I then changed the file so that the Directory section came before the VirtualHost section, re-ran certbot, and it succeeded.
But, interestingly, the original VirtualHost spec was followed by a blank line with a single space in it before the Directory spec, so maybe it is exactly the same thing...
Thanks for posting this!!
I honestly think this bug should have a higher priority or at least a more informative message when appearing to it. I now know of multiple people who wasted a lot of time with this issue.
Is anyone aware of a reason this bug is being hit more often? I don't think we've changed anything recently in our Apache plugin that would have caused this.
Regardless, we would accept a well written PR for this. I'm not certain, but I highly suspect the fix here would need to be made to Augeas and/or our Augeas lens.
Commented out OSCP Stapling stuff (which doesn't belong in a port 80 host, but was preparing it from a working TLS config from another of my sites) and OSCP Stapling can't go inside the VirtualHost section.
So this stuff (commented-out settings) appeared below the VirtualHost section, and triggered this bug, before I found this issue and temporarily put these comments inside the VirtualHost section, (marking them with a reminder to move back outside on the TLS config, post-install).
We've made a lot of changes to Certbot since this issue was opened. If you still have this issue with an up-to-date version of Certbot, can you please add a comment letting us know? This helps us to better see what issues are still affecting our users. If there is no activity in the next 30 days, this issue will be automatically closed.
It's not straightforward to test if this is still borken b/c people would have to be setting up a new Certbot-enabled site. Once I have everything working, I'm loathe to touch it, for fear of having it fail when the cert expires.
I see it's prioritized "unplanned". Seems mighty easy to trip over, but not easy to solve without help. Maybe put info in instructions? Maybe have Certbot ignore-but-preserve everything after the VirtualHost section?
On 19/03/2023 23:21, David Cain wrote:
It's not straightforward to test if this is still borken b/c people would have to be setting up a new Certbot-enabled site. Once I have everything working, I'm loathe to touch it, for fear of having it fail when the cert expires.
True. And I'm afraid that I had to drop Certbot from my server images anyway, when cleaning out anything that required Snap installation. I've been using apache-md instead without problems.Message ID: @.***>
We've made a lot of changes to Certbot since this issue was opened. If you still have this issue with an up-to-date version of Certbot, can you please add a comment letting us know? This helps us to better see what issues are still affecting our users. If there is no activity in the next 30 days, this issue will be automatically closed.
I came across the same error "Could not reverse map the HTTPS VirtualHost to the original" while setting a new domain in a LAMP server.
After some time, I realized that for some reason I didn't figure out, the Certbot wasn't creating the file 'mydomainname.com-le-ssl.conf' in the Apache folder /etc/apache2/sites-available (which the Certbot usually does). I was able to fix the issue manually creating the file 'mydomainname.com-le-ssl.conf' and copying/pasting the content from other of other domain I already had configured and working (replacing the domain of course).
Then I run a2ensite domainname-le-ssl.conf (which usually is not necessary), and reloaded Apache with systemctl reload apache2
It worked!
Still not resolved?
The solution of @EML-github worked for me (changed the file so that the Directory section came before the VirtualHost section): from:
<VirtualHost *:80>
...
</VirtualHost>
<Directory "/var/www1">
...
</Directory>
to:
<Directory "/var/www1">
...
</Directory>
<VirtualHost *:80>
...
</VirtualHost>
Additionally I checked:
- no spaces between te beginning of the line and the opening brackes '<'
- no spaces at the end of any line
Than because I already had the certificates, but certbot couldn't install them because of the error. After fixing the above, I only had to rerun:
certbot install --cert-name the.domain.name