20.6.2018
Sometime I need to publish some information from out intranet. I use our server hosting https://www.hobrasoft.cz for reverse proxying usually. The server is located in Prague, while our intranet is located in Rožnov pod Radhoštěm, distance is about 300 km. Visitor communicates with our Prague server only, he knows nothing about our intranet site. Only the reverse proxy in Prague communicates directly with the server in our intranet.
I used this scheme in our customer's sites in many cases, too. Most asked task is secured access to an internal information system.
In Hobrasoft, we have most of our data located on internet, so we have another reason to use reverse proxy usually. For example, we created a small remote controlled town for a short lecture about BeagleBone. Security is important for us so we use HTTPS with Let's Encrypt certificates. Since the BeagleBone is slow, using HTTPS could decrease the speed of communication significantly. For this reason the HTTPS is made in our Prague server and the BeagleBone communicates without encrypting. Of course, the communication between the Prague server and our intranet router is secured using IPSEC. We prefer IPv6, so the communication between reverse proxy and BeagleBone is made on IPv6 protocol only. There is no IPv4 address set in BeagleBone. The reverse proxy provides the power for HTTPS and smooth interfacing between IPv4 and IPv6 networks.
Reverse proxy mediates the data from atmospheric pressure sensor ( Pa) mentioned in article Pressure sensor connected to BeagleBone. In this case, the reverse proxy provides the URL https://www.hobrasoft.cz/meteo only. All details are hidden from our web's visitor.
We want to create the https://weblight-demo.hobrasoft.cz site listening on port 433, protocols both IPv6 and IPv4. The site provides access to a device in our office. The site uses HTTPS only, all HTTP requests should be redirected to HTTPS. The device communicates using IPv6 only, no HTTPS is possible.
The request are handled on address 178.238.42.9 or 2a01:430:59:1:3::1.
The device has address 2001:DB8::11. The firewall restricts access to the device from the 2a01:430:59:1:3::1 address only. No other addresses are allowed to access the device.
Certificates are created automatically using Let's Encrypt acme.sh utility.
In distributions like Debian or Gentoo the configuration files differ. Also the format of configuration differs depending on Apache version. In this example the Apache 2.4 syntax is used. Previous Apache versions (2.2 or older) differ in Directory directive items mostly.
Only one virtual host's setting is described in the example. Complete configuration of the server and all it's virtual hosts can be much more complicated.
#
# Access via HTTP (without encryption) is important. Two reasons exist:
# redirection to HTTPS for ordinary requests
# issuing the certificate from Let's Encrypt
#
<VirtualHost *:80>
ServerName weblight-demo.hobrasoft.cz
#
# Redirect allows only requests to /.well-know directory using HTTP
# All other request are redirected to HTTPS version of URL
#
RedirectMatch permanent ^/(?!(\.well-known)) https://weblight-demo.hobrasoft.cz/
#
# The well-know directory is needed for certificates issuing only.
#
DocumentRoot /var/www/localhost/well-known
<Directory /var/www/localhost/well-known>
Order allow,deny
Allow from all
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
#
# All requests are handled using HTTPS, except requests from Let's Encrypt certification authority.
# To use name based virtual hosts the SNI extension must be implemented in Apache server.
# Most Apache installations has the SNI extension available already.
#
<VirtualHost *:443>
ServerName weblight-demo.hobrasoft.cz
#
# The device is available on it's own URL. Apache need to know the URL.
# In fact, the weblight-demo device runs on two different physical devices
# (the BeagleBone and a web camera). The request is redirected to
# the right URL depending on request's URL using RewriteRule.
#
# For the simplicity, we use only one device in the example.
#
# The option ProxyPass* has two parameters
# / Which URL is being redirected
# http://[... Which URL is redirected to
#
# Using reverse proxy you can choose which device and URL handles the request.
#
ProxyRequests off
ProxyPass / http://[2001:db8::11]:8099/
ProxyPassReverse / http://[2001:db8::11]:8099/
#
# In IPv6 networks the computer has more IPv6 addresses usually.
# It allows you to use different IP addresses for different services running on your server.
# When using reverse proxy it is useful to use one specific address only for outgoing requests.
# It is important specifically in sites where the access to intranet is
# restricted by firewall to some specific IP addresses.
#
ProxySourceAddress 2a01:430:59:1:3::1
#
# The path to certificates, SSL settings...
# Certificates are stored using "certificates" user account for security reason.
# Apache must have access granted to the directory.
#
# Only strong ciphers are allowed.
#
SSLEngine on
SSLCipherSuite \
HIGH:!aNULL:!MD5
SSLCertificateFile /home/certificates/.acme.sh/weblight-demo.hobrasoft.cz/weblight-demo.hobrasoft.cz.cer
SSLCertificateKeyFile /home/certificates/.acme.sh/weblight-demo.hobrasoft.cz/weblight-demo.hobrasoft.cz.key
SSLCertificateChainFile /home/certificates/.acme.sh/weblight-demo.hobrasoft.cz/fullchain.cer
</VirtualHost>
We administer our certificates from Let's Encrypt using acme.sh utility. The utility can be downloaded from here: https://github.com/Neilpang/acme.sh. The utility is well described in documentation and the installation is very simple. But some errors can occur obtaining the certificates.
If you use the root account, no special access rights are needed for the directories usually. But if you have reserved user account for your certificates, you have to set access rights to the /var/www/localhost/well-known directory for the user account. The user account must be allowed to write to the directory.
Before you run the acme.sh utility, make sure that you can access the .well-known directory from internet. Create a file in /var/www/localhost/well-known directory and try to access the file using curl utility:
echo "hello" > /var/www/localhost/well-known/abcd.txt curl -X GET http://weblight-demo.hobrasoft.cz/.well-known/abcd.txt
Curl has to write string "hello" to the console. If not, try to run curl with parameter -v and analyze the network communication.
If everything is ok, you can try to issue the certificate:
acme.sh --issue -d weblight-demo.hobrasoft.cz -w /var/www/localhost/well-known
Once the certificate is issued, restart the Apache server and test the reverse proxy:
Add the acme.sh to your crontab. When the certificates changed, the Apache server should be restarted. You can use the --post-hook option to restart server. The option has one parameter – a script started when some certificate changed. If you use ordinary user account, the sudo utility is your friend.
In the example the reverse proxy is located in Prague and the device is located in Rožnov pod Radhoštěm. All the communication uses non-secure HTTP protocol. In this case no sensitive information are being transported over the internet. But in other cases, when sensitive information are being transported, the additional security is needed. We use IPSEC for all communication between our Prague server and the intranet router. I strongly recommend to use IPv6. The IPSEC setting for the IPv6 is simple and easy to understand. The IPv6 firewall setting is simple, too.