Apache, Reverse Proxy and SSL

Of course, the first time I try an SSL certificate I have to have a complicated setup.

I am running several web servers on different machines/ip addresses in my network. I use Apache’s virtualhost to proxy from a proxy server based on passed in URL.

URL’s I’m working with are “riodevaca.com”, “nationalsaanenbreeders.org”, “astro-farmer.com” and “hempenings.com”. The last one is a “dead” project and is my test platform to get this working.

Reverse Proxy works great for http protocol, port 80, but I need to https, port 443 as soon as I figure it out.

Public IP: Proxy is debian 9 running apache2 on Port 80 on my router goes to this machine. This apache server uses reverse proxy to route hempenings.com to as that is the network IP of the dedicated machine to serve a drupal 8/apache site.

Copying the certificate from the /etc/letsencrypt/live path from …126 to …149 and adding port 443 to the virtualhosts in the apache configuration file gives the results below.

What is needed to get this to work?

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: hempenings.com

I ran this command: attempting to transfer generated keys to proxy

It produced this output: the certificate is only valid for the following names: linksyssmartwifi.com, www.linksyssmartwifi.com, myrouter.local, EA6350.home.linksys.com

My web server is (include version):apache 2.4

The operating system my web server runs on is (include version)Debian 10

My hosting provider, if applicable, is:self

I can login to a root shell on my machine (yes or no, or I don’t know):yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): 0.13.0

Is there a simple way to proxy SSL connections?

To me, this look like a port forwarding issue.

The good:

  • Your Apache server is responding to traffic on port 80 of your IP address. :+1:

The bad:

  • Port 443 is not accessible externally (from my perspective). Network timeout.
  • Port 443 is served by your modem-router web admin interface (from your perspective).

What you will probably want to do is to reconfigure your modem-router to serve its admin interface from a port other than 443, and then add a port forwarding mapping for port 443 to map to (your Apache proxy).

What I often do is ask for help then immediately solve the issue.

Yes, I did need to open port 443 and route it also to the proxy server.

What finally got it working though was…

Virtualhost for port 80…redirect to https://site
Virtualhost for port 443 on proxy server…set it up just like the automatically generated config in sites-enabled…but add the reverse proxy stuff
And of course, the archive and live subdirectories with the keys copied to the proxy server.

Still to crack is the automation of renewal. Should be easy on the servers themselves, but replicating the archive and live directories will be an issue. My ssh connections between servers require a pass phrase … as in “interaction”. Setting up noninterractive authentication is going to be the fun part.

You don’t necessarily need to use the exact same public cert on all the systems that respond to that FQDN (internally and externally).

That is, you might be able to resolve your problem in several “other” ways:

  • use only HTTP internally (probably not recommended - but depends entirely on net security)
  • use HTTPS internally but with self-signed certs (for those systems behind the proxy)
  • use DNS authentication for public certs (on those systems behind the proxy)
  • use a public wildcard cert (obtained by only one system) and then copy it around internally

Hi @stuman

checking that domain that looks curious - https://check-your-website.server-daten.de/?q=riodevaca.com

Domainname Http-Status redirect Sec. G
http://riodevaca.com/ 200 1.940 H
http://www.riodevaca.com/ 200 1.846 H
https://riodevaca.com/ 500 4.680 N
Proxy Error
Certificate error: RemoteCertificateNameMismatch
https://www.riodevaca.com/ 500 4.326 N
Proxy Error
Certificate error: RemoteCertificateNameMismatch

There is a wrong certificate - and a Proxy Error:

Proxy Error

The proxy server could not handle the request GET / .
Reason: Error during SSL Handshake with remote server
Apache/2.4.25 (Debian) Server at riodevaca.com Port 443

http answers with a

Server: Apache/2.4.38 (Debian)

the proxy answers with a

Server: Apache/2.4.25 (Debian)

Good: /.well-known/acme-challenge/random-filename answers, there is the expected result http status 404 - Not Found.

So you should use --webroot and the webroot of your 2.4.38, so Certbot can find the correct path.

Your third domain has a wrong redirect ( https://check-your-website.server-daten.de/?q=hempenings.com ):

There is a redirect to https:/hempenings.com, so one / is missing.

Good: Your non-www + https works without error, there is the drupal site.

Your www has the same proxy error and the wrong certificate:

Issuer not before not after Domain names LE-Duplicate next LE
Let's Encrypt Authority X3 2019-09-06 2019-12-05 hempenings.com
1 entries duplicate nr. 2
Let's Encrypt Authority X3 2019-09-06 2019-12-05 hempenings.com
1 entries duplicate nr. 1

Create one certificate with both domain names.

I did that which I often do. Reach out for help when exasperated and promptly resolve the issue myself. I have all three domains working properly through the proxy now. The real fun will come when I test the renewal process, which I should have automated for the single proxy all three sites go through and the individual sites themselves. The proxy is Debian9 and the Drupal hosts are Debian10 so there may be an apache version mismatch but it seems to be working anyway.

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