letsencrypt exception on apache reverse proxy along with ip restrictions

vincix · 04-16-2019, 07:32 AM

I have the following apache configuration for a reverse proxy:

Code:

<VirtualHost *:80>
  ServerName example.com
  DocumentRoot /var/www/html
  Redirect / https://example.com/
</VirtualHost>

<VirtualHost *:443>
  ServerName example.com
  
  SSLEngine on
  SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
  SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
  DocumentRoot /var/www/html


  ProxyRequests Off
  ProxyPreserveHost On
<Location />
    ProxyPass "http://localhost:8050/"
    ProxyPassReverse "http://localhost:8050/"
    Require ip 10.0.0.0/24
    Require ip 192.168.0.0/24
</Location>
</VirtualHost>

Now if I want to create an exception for let's encrypt so that it doesn't proxy requests coming from their servers I would normally do it like that:

Code:

ProxyPass /.well-known !
ProxyPass / "http://localhost:8050/"
ProxyPassReverse / "http://localhost:8050/"

That is to say, outside the "Location" section (which means that I explicitly write the path of the ProxyPass and ProxyPassReverse, as it is no longer implicit). The problem is that I wouldn't be able to integrate the IP restrictions, which I would like to have only for the proxied backend and I would leave the /.well-known location accessible.

Any ideas how I can achieve this?

tyler2016 · 04-16-2019, 10:40 AM

You could use mod_rewrite to send requests from your internal networks to the proxied backends unmodified, and everything else to the file Let's Encrypt uses to verify domain ownership. Unless you are running a super high traffic site where you need to squeeze every bit of performance out of it, it should do the job.

vincix · 04-16-2019, 03:03 PM

I find the solution a little bit ambiguous. So what you're saying is that I should add rewrite rules for each of network address? There must be a clearer and cleaner way of doing this, but maybe I'm wrong. But if you're willing to be more explicit, then I'll give it a try.

tyler2016 · 04-17-2019, 06:30 AM

Maybe something like this?

Code:

RewriteEngine On
RewriteCond %{CONN_REMOTE_ADDR} (!10\.0\.0\..*)|(!192\.168\.0\..*)
RewriteRule #LETSENCRYPT_URI

vincix · 04-17-2019, 08:18 AM

On the one hand, I have a long list of IPs that I need to give access to. On the other hand, I don't see how the rule would work anyway, as the letsencrypt_uri is going to be example.com/.well-known, which doesn't really help me in this context, as it's going to go to the backend anyway, so that the letsencrypt requests are going to end up accessing http://localhost:8050/.well-known instead.

I don't understand why it wouldn't work with an Alias and/or with another Location for /.well-known. I tried it, but it doesn't seem to have any effect. I added the following before <Location />

Code:

Alias "/.well-known" "/var/web/letsencrypt"
  <Directory "/var/web/letsencrypt">
  Require all granted
  </Directory>

I was able to do it in nginx so easily while also including ip restriction in another location:

Code:

location /.well-known {
                alias /var/www/html/.well-known;
    }
location / {
        include allowed.ips; # restrict access to certain IPs
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Port $server_port;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://mybackend;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        # This allows the ability for the execute shell window to remain open for up to 15 minutes. Without this parameter, the default is 1 minute and will automatically close.
        proxy_read_timeout 900s;
    }

tyler2016 · 04-17-2019, 09:09 AM

Quote:

Originally Posted by vincix

I don't understand why it wouldn't work with an Alias and/or with another Location for /.well-known. I tried it, but it doesn't seem to have any effect. I added the following before <Location />

I'm glad you got it to work with Nginx. It has been a while since I have used Let's Encrypt for a machine on my network. Right now, I am only using Let's Encrypt for shared hosting. I would think adding another location block like you said would work. I've never used Apache for reverse proxying, I've always used HAProxy.

I just thought of something you might be able to do if you really want to use Apache. I wonder if it would work if you were to configure a virtual host for Let's Encrypt, then setup another location block that uses it as a back end?

vincix · 04-17-2019, 04:27 PM

Maybe I was a little bit misleading. I had the solution for nginx from the very beginning, but it's important to find it on apache, because this is what we're currently using in some setups and there are still many configurations that I find a little bit dificult to transfer to nginx - I still need to understand how I would go about doing that.
So basically two <VirtualHost> sections, one for let's encrypt and the other for the backend? I don't see how anything good could come out of this, but I could give it a try, I guess. I expect that the first one takes precedence over the second one, and so the second wouldn't be accessible anymore.

vincix · 07-09-2019, 05:15 AM

I ended up writing a Redirect exception on the 80 VirtualHost, so that letsencrypt simply doesn't connect to the 443 at all:

Code:

RedirectMatch 301 ^(?!/\.well-known/acme-challenge).* https://example.com$0

Hostech_Support · 07-10-2019, 07:38 AM

I’d suggest changing the rewrite rule at the end of the apache conf (http section ) to;

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

vincix · 07-11-2019, 03:16 PM

If you also gave some arguments and explained to me how that could possibly accomodate the letsencrypt exception, that would be really amazing.