Bug: Could not reverse map the HTTPS VirtualHost to the original

I have a working 80 vHost, check http://kekschen.eu

Your installation is corrupt - https://check-your-website.server-daten.de/?q=kekschen.eu

Port 443 answers, but with http content. Perhaps that's part of the problem.

Additional: Check

https://www.digitalocean.com/community/questions/why-do-i-get-this-could-not-reverse-map-the-https-virtualhost-to-the-original-message-when-i-try-to-install-an-ssl

So first remove that wrong configured port 443.

The basic vhost configuration you should end up with (lets start minimal with keckschen.eu) is:

<VirtualHost *:80>
  ServerName keckschen.eu
  ServerAlias www.keckschen.eu
  ...
</VirtualHost>

<VirtualHost *:443>
  ServerName keckschen.eu
  ServerAlias www.keckschen.eu
  SSLEngine on
  SSLCertificateKeyFile /etc/letsencrypt/live/<path to key>
  SSLCertificateFile /etc/letsencrypt/<path to fullchain>
  ...
</VirtualHost>

If you still have key/cert files lying around, you can manually configure this with the paths and check that you can access your server. Then you can start certbot and check if it correctly detects all the vhosts and domains.

If you do no longer have certs, remove the *:443 vhosts and keep the *.80 ones. Then, certbot should be able to figure out what to do.

The problem with certbot - for me at least - is always the initial magic of boot-strapping itself. Once you have the vHosts in place and running, it becomes easier.

If you need a break from certbot, you can try the Apache native module mod_md which is available on ubuntu 18.10.

sudo apt install libapache2-mod-md
sudo a2enmod md
sudo systemctl restart apache2.service

The config above with mod_md would look like this:

# You have read the Terms of Service from LE
MDCertificateAgreement https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf

# You want this domain (and all connected) to be managed
MDomain keckschen.eu

# You want http: to redirect to https: (for now)
MDRequireHttps temporary

<VirtualHost *:80>
  ServerName keckschen.eu
  ServerAlias www.keckschen.eu
  ...
</VirtualHost>

<VirtualHost *:443>
  ServerName keckschen.eu
  ServerAlias www.keckschen.eu
  SSLEngine on
  ...
</VirtualHost>

(Disclaimner: I wrote the module.)

My vHost looks like that but certbot doesnt create any ssl vhost:

<VirtualHost *:80>
ServerAdmin Philipp@PNG.Services
ServerName kekschen.eu
ServerAlias www.kekschen.eu

DocumentRoot /var/www/kekschen/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
 
<Directory /var/www/kekschen/html>
AllowOverride All
</Directory>

As written: You have a wrong port 443 vHost - http://kekschen.eu:443/

I have no idea what's this is. But that may block Certbot because port 443 is used with http content.

Not Implemented

The URL or IP you are trying to access is out of service

There is a link to https://png.services/ - there is the same problem. That's http over port 443, because

http://png.services:443/

answers.

I think this because of default.conf

<VirtualHost *:80>
	# The ServerName directive sets the request scheme, hostname and port that
	# the server uses to identify itself. This is used when creating
	# redirection URLs. In the context of virtual hosts, the ServerName
	# specifies what hostname must appear in the request's Host: header to
	# match this virtual host. For the default virtual host (this file) this
	# value is not decisive as it is used as a last resort host regardless.
	# However, you must set it for any further virtual host explicitly.
	#ServerName www.example.com

	ServerAdmin Philipp@PNG.Services
	DocumentRoot /var/www/html

	# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
	# error, crit, alert, emerg.
	# It is also possible to configure the loglevel for particular
	# modules, e.g.
	#LogLevel info ssl:warn

	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	# For most configuration files from conf-available/, which are
	# enabled or disabled at a global level, it is possible to
	# include a line for only one particular virtual host. For example the
	# following line enables the CGI configuration for this host only
	# after it has been globally disabled with "a2disconf".
	#Include conf-available/serve-cgi-bin.conf
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
<VirtualHost *:443>
	# The ServerName directive sets the request scheme, hostname and port that
	# the server uses to identify itself. This is used when creating
	# redirection URLs. In the context of virtual hosts, the ServerName
	# specifies what hostname must appear in the request's Host: header to
	# match this virtual host. For the default virtual host (this file) this
	# value is not decisive as it is used as a last resort host regardless.
	# However, you must set it for any further virtual host explicitly.
	#ServerName www.example.com

	ServerAdmin Philipp@PNG.Services
	DocumentRoot /var/www/html

	# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
	# error, crit, alert, emerg.
	# It is also possible to configure the loglevel for particular
	# modules, e.g.
	#LogLevel info ssl:warn

	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined

	# For most configuration files from conf-available/, which are
	# enabled or disabled at a global level, it is possible to
	# include a line for only one particular virtual host. For example the
	# following line enables the CGI configuration for this host only
	# after it has been globally disabled with "a2disconf".
	#Include conf-available/serve-cgi-bin.conf
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

That's terrible. A 443 vHost without a minimal working SSL configuration.

Remove that vHost (first, make a backup).

That doesn’t solve the issue. However, I reinstalled Ubuntu now and it should be working now. I will run certbot soon.
Nevertheless the bug in certbot should be fixed. Reinstalling the os shouldn’t be the solution.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.