Geuni/ May 1, 2020/ Englisch/ 0 comments

In the first part “ReverseProxy – Part 1? What is that? How does that help me?” I showed how to build a ReverseProxy in a Docker container and deploy your first applications over it, as well as perform authentication on it. Now we want to focus on how we can finally integrate and renew an SSL certificate free of charge, as well as what you have to pay attention to at TLS/SSL in order to be secure.

1) What do we want to achieve here?

We want to secure our services with TLS via our reverseproxy and automate as many “operational activities” as possible, so that we have little to do with them.

2) What are our requirements to a reverseproxy?

We want to include an SSL certificate in our reverseproxy (based on apache), have the renewal of the certificate automated and have a common, secure configuration for our services. SSL/TLS.

3) How do we want to achieve this?

We have already built the basics with our ReverseProxy, now we only need another container with a CertBot that gets and renews the certificate. Of course, we need to integrate CertBot with the Apache container.

4) CertBot – Directory-level preparation

In the area of Docker containers, you can do virtually all of them on command lines, which in turn means that it is very much automatable. That’s why we’re going to assemble a command that puts the container on, runs briefly, and removes it. For this to work, we need to prepare a pair of folders, assign the correct permissions, and change something in our vHosts in the Apache configuration. Let’s start with the folders.

We create a folder in the shared folder/share “container” with the name “letsencrypt” (if we don’t have that before). In this folder comes a folder with the name “data”. Now we need a folder in “data” named “.well-known” (don’t forget the point, it’s important). Then create a folder with the name “acme-challenge”. If the attachment of the folders does not work via Windows Explorer, you have to try this using the “mkdir” command via an SSH connection on your NAS or by CMD in Windows.

mkdir /share/Container/letsencrypt/
mkdir /share/Container/letsencrypt/data/
mkdir /share/Container/letsencrypt/data/.well-known
mkdir /share/Container/letsencrypt/data/.well-known/acme-challenge

Now, at the beginning in our reverseproxy configuration, where our vHosts are described as<ip>”container” are<NameDerDatei>these lines:</NameDerDatei> </ip>

########################
#CertBot Configs for all!
########################
#Setze an Alis
Alias /.well-known/acme-challenge/ "/letsencrypt/data/.well-known/acme-challenge/"
#bestimme the record
<Directory "/letsencrypt/data/.well-known/acme-challenge/"=""></Directory>
    #erlaube address the directory to each IP
    Require all granted
    #Der server has an index for the directory and is able to track symbolic links in the file path
    Options Indexes -FollowSymLinks
    .htaccess files in which other settings for directories may exist are ignored by the "none"
    AllowOverride None

This is the general function that CertBot on every vHost you will continue to create! This is practically the integration of CertBot with your Apache reverseproxy.

Small note: If someone doesn’t want this CertBot configuration for all vHosts, they only need <Virtualhost …=””> </Virtualhost>to write this block to the block of a vHost (i.e. between ) and not at the top of the file!

These lines mean that we can create an alias to browse behind our domain or all sub-domains into the path “/.well-known/acme-challenge/”. This path, which we enter into the browser, is converted in the Apache container (caution: this just does not happen mentally in the CertBot container!) to the local path at runtime “/letsencrypt/data/.well-known/acme-challenge/”.

For this to work, the apache container must of course have the folders available on the root (keyword: YML file and volumes). We will test this later, as we also have to play with permissions here.

5) CertBot – Directory Permissions

Anyone who has understood this little prank in your head now knows that we should probably check our “Apache.yml” again if we have a volume in it that has a folder on the root of the Apache container with the name “letsencrypt”. There are two ways to do this;

  • 2) We run an “ls” command using SSH in the Apache Docker container to see which folders are available at run time:
docker exec apache ls /

Now we have to change the rights to these strangely named folders (“well-known”, “acme-challenge”) because every administrator has to be able to write from the server. Otherwise CertBot will not work. We do this simply by a CHMOD and a CHOWN with the parameter recursively.

• Change the owner and the group
chown -R admin:administrators /share/Container/letsencrypt/
• grant the owner and the group full rights, but not to
chmod 770 /share/Container/letsencrypt/
• grant the owner and the group full rights, but not to
chmod 770 -R /share/Container/letsencrypt/data/

In this folder, only a temporary file from the CertBot is to be stored in this folder, which Checks LetsEncrypt against it, so that an SSL certificate is issued. So if someone puts data there(well, only an inner offender can do that! Nobody can do that from the Internet!) he simply has nothing of it. So for us, this configuration is not a problem for the first time. If everything worked, a “ls -al” provides the following result.

[~]ls -al /share/Container/letsencrypt/
total 76
drwxrwxrwx 13 admin administrators 4096 2019-06-22 10:36 ./
drwxrwx--- 14 admin administrators 4096 2019-06-22 09:34 .. /
drwxrw-rw- 4 admin administrators 4096 2019-04-22 20:15
drwxrwx--- 3 admin administrators 4096 2019-04-28 12:57 archive/
drwxrw-rw- 2 admin administrators 4096 2019-04-28 12:57 csr/
drwxrwx--- 3 admin administrators 4096 2019-04-28 12:38 data/
drwxrw-rw- 3 admin administrators 4096 2019-04-21 11:21 etc/
drwxrw-rw- 2 admin administrators 4096 2019-04-28 12:57 keys/
drwxrwx--- 3 admin administrators 4096 2019-04-28 12:57 live/
drwxrw-rw- 2 admin administrators 4096 2019-06-20 21:49 log/
drwxrw-rw- 2 admin administrators 4096 2019-04-28 12:57
drwxrw-rw- 5 admin administrators 4096 2019-04-22 19:55 renewal-hooks/
-rwxrw-rw- 1 admin administrators 64 2019-01-01 21:29 .updated-options-ssl-apache-conf-digest.txt*
drwxrw-rw- 2 admin administrators 4096 2019-04-21 11:21 var/

The most important thing here is the specified for the directory “data/”.

Here I would recommend a test now! With all this volume in Docker containers, it can be quite complicated. Restart Apache reverseproxy Docker once (only by SSH:

docker restart apache

We should now add a TXT file with any content in the folder “.. Create “Container”letsencrypt.well-known-acme-challenge”. Now try to access one of our configured domains in the browser and append it at the end “/.well-known/acme-challenge/<nameeurerdatei>.txt”.</nameeurerdatei> Should this not work we still have a problem (consider browser caching, a change can sometimes help at such a point not to interpret page effects as errors). The goal of this test is that we can use a domain to call a file in the /.well-known/acme-challenge/folder. If that’s possible, then our drive mappings are correct and CertBot should then also be able to access the files or create the necessary files at run time.

If you see the contents of your file now, it has worked and CertBot could do the challenge and validate your domains. All we have to do is set it up.

6) CertBot – Dry-Run Certificates!

With Lets-Encrypt, as long as you don’t have your “CertBot command line” perfect, you should always make a “dry run”, because there is so-called domain. Rate limits. Meaning that if you do something wrong too often, Lock Lets-Encrypt for a week and you can wait until you can try again! Therefore, always pay attention to the parameter “Dry-Run” when testing. In SSH you type the following command (of course you replace the necessary positions with your configuration):

docker run -it --rm -v /share/Container/letsencrypt:/etc/letsencrypt -v /share/Container/letsencrypt/data:/data/letsencrypt certbot/certbot certonly --non-interactive --webroot --webroot-path=/data/letsencrypt -d <domain>.<tld> <subdomain><domain> <tld>--email <name><domain>.<tld> --agree-tos --dry-run</tld> </domain> </name> </tld> </domain> </subdomain> </tld> </domain>

So that we can understand what we are doing here. “docker run” says that you want to run a container, “-it” means “i”=”interactive” and “t”=”terminate”, so the container runs interactively and ends after its run. “–rm” then stands for it being deleted after the run. With “-v” the volume mappings come as in the YML file. After a space of the last volume, the name of the image (these are specified in the Docker hub) is written. Now follows the actual CertBot command, which is executed in the container at run time.

Here you would expect certBot again as a command (if you install CertBot in an OS), but since the container can’t do anything else, it’s practically already done and we parameterize the already running CertBot with the first parameter “certonly”, tell him then that we are not interactive (so we don’t answer a question!) with “–non-interactive” and then say that we are in the so-called “non-interactive” WebRoot mode and where our “web root” is in the example (for this are the weirdly named folders before). With “-d” we specify our domain. Each further “-d” parameter gives a so-called “-d” parameter. “alternative name” in the SSL certificate. Here you can simply take other domains (I wouldn’t recommend), but also all the sub-domains we have.

Finally, we send an e-mail and say that we agree with the user regulations and do not forget the important “–dry-run”, because we do not yet know if this works!

When we fire the command, something like that should come out if it works!

If mistakes come, then you may need to. adjust the rights, that is usually the problem! However, CertBot should always give you the HTTP error code, so you get good clues about what’s not possible.

[~]# ....  --agree-tos --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert not due for renewal, but simulating renewal for dry run
Renewing an existing certificate
Performing the following challenges:
...
Using the webroot path /data/letsencrypt for all unmatched domains.
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
 - The dry run was successful.

If it works, then run the same command only without the parameter “–dry-run” and you get your certificate!

If you have your certificate, you can check it in the folder<ip>”Container” “letsEncrypt” where you should now have a folder with the first “-d” parameter value, so probably your root domain.</ip> There should now be a few files like a chain.pem a key.pem etc.

7) Reverseproxy vHost – HTTPs Redirects

Upstairs, we’ve only ever played with HTTP. We haven’t tried anything with HTTPs yet. CertBot only needs HTTP to validate a website, so HTTP must always remain open, at least for CertBot. However, we do not want anyone else to continue to access via HTTP, so everyone else should be compulsively forwarded to HTTPs.

So that we can now safely access our pages via HTTPs, but at the same time do not get lost on the CertBot, we have to tell our reverseproxy that almost all requests that are HTTP should be converted to HTTPs, but exactly those of the CertBot should not! For this purpose, we enter the following three lines in our vHosts file under the alias block!

########################
#HTTP rewrites
########################
engine #Einschalten
RewriteEngine on
#Bedingung: Do not apply rewrites until the requested file is a valid one!
RewriteCond %-REQUEST_FILENAME-f
If a valid file now appears in the path "well-known", do nothing and stop all further rewrites!
RewriteRule .well-known/.+ -[END]
• If there is no "well-known" beforekahm, write everything on HTTPs
RewriteRule . . . . . . . . . . . . HTTP_HOST . . . . . . . . . . . . . . . . . . . . . . . . . . . .[NC,R=301,L]

To understand: first we turn on the rewrite engine. Then we define the condition (RewriteCond) that whenever a file is requested that exists, the first rule is applied (only allows files with the URL portion “well-known”) that allows the file to be accessed via HTTP. If the file is not found via HTTP, recode everything to HTTPs and ignore that someone wanted a file from “.well-known”. The rough, how these lines work, in detail, these are much more complicated! But I don’t explain what that means at first and refer to the Apache documentation for the RewriteEngine.

8) Reverseproxy vHost – Global HTTPs config

Now we come to the actual SSL parameters that we configure once for all vhosts and then within each vHost (code below with comments).

SSL stapling, that’s what the first 4 lines after the comment in the code are all about. It is stupid that it is called SSL stapling, because it refers to the function of checking certificates against multiple CAs for validity, which is called The Online Certificate Status Protocol (OCSP). The fourth line, which specifies the caching directory, describes that the “shmcb” protocol is used here as so-called “shmcb”. “Shared Object Cache” is accessed on a path.

SSLPassPhraseDialog refers to the method by which Apache decrypts the encrypted private key of the SSL certificate locally at startup. Here you could, for example, include another program if you want to work with service accounts and the like. The next two parameters are again caching functions for running SSL sessions.

IMPORTANT: All paths you are tapped here are executed from the Apache container’s point of view. This always confuses when you forget how the mappings were in the container! Here’s the code and comments about it, you just shouldn’t get that together.

SSL CONFIGS
• turn on the SSL-Enginge
SSLUseStapling on
Set the OCSP responder timeout to 5 seconds
SSLStaplingResponderTimeout 5
• Do not send the CA any responder errors
SSLStaplingReturnResponderErrors off
Cache the OCSP responses using shmbc in the path ...
SSLStaplingCache shmcb:/var/run/ocsp(128000)
Use the Apache standard method to decrypt private keys at server startup
SSLPassPhraseDialog builtin
Define the location where SSL caches are stored
SSLSessionCache "shmcb:/opt/bitnami/apache/logs/ssl_scache(512000)"
• Remove SSL caches after 300 seconds if they are unused
SSLSessionCacheTimeout 300

9) Reverseproxy vHost – vHost HTTPs config

So, now we have briefly described the general parameters for SSL above. These are not complete! However, they are sufficient for our application here.

Now we go on to our vHost. We now have to finish this for SSL/HTTPS. In our example, we first set the port to 8443. This is simply due to our configuration, the port 443 would be common here.

You might think that the first line specifies the name of the vHost, no, that happens in the “ServerName” line. There is your domain to use, or subdomain. In the first line “<VirtualHost *:8443=””>” you could replace the “*” with an IP to change if necessary.</VirtualHost> other interfaces for editing the vHost. After that, we start the SSLEngine and set a header to activate HTTP Strict Transport Security (HSTS), of course also for all subdomains. HSTS is a protection for HTTPs which states that the user’s browser only allows HTTPs connections over a certain time (max-age) from the site. So are so- “Downgrade attacks” or “session hijacking” attacks.

Then we define the allowed SSL protocols. We say “all” and exclude with a minus all that we do not want. In this example, we are all of you who are old and have known weaknesses. I don’t go into this in detail now, I recommend googling, because you will quickly find which weaknesses are contained in the old protocols (e.g. TLS1.0).

One of the minutes is that the so-called “so-called” CipherSuits. These are the encryption algorithms used in the TLS protocol. I’m even less concerned about that, because you can fill books with it! If you want to understand this more precisely, you should start with the topic on Wikipedia.

Below in the configuration comes an important part by saying that the CipherSuits may only be processed in the order as they are specified. This prevents downgrade attacks. Then let’s say we’re exhibiting compression, as well as session tickets.

Now we indicate where our certificates are located. It should be borne in mind that we always handle this relatively out of the container. For this purpose, if necessary. Take a look at the YML file of our Apache container and see where we have included the directory for LetsEncrypt and of course check the authorization structure again so that Apache revereseproxy can really see and use the files.

All as a comment in the code.

<VirtualHost *:8443=""></VirtualHost>
	This is the name of the vHost which should be equal to the domain or subdomain
	Server name <domain>.<tld> </tld> </domain>
	
	here the SSL-Enginge is activated for the vHost
	SSLEngine on
	
	This is the activation of the so-called " HSTS
	Header always set Strict transport security "max-age=31536000; includeSubDomains; preload"
	
	• defines which protocols we allow for HTTPs
	SSLProtocol all -TLSv1 -TLSv1.1 -SSLv2 -SSLv3
	
	• defines the encryption algorithms used
	SSLCipherSuite 'kEECDH+ECDSA kEECDH kEDH HIGH +SHA !aNULL !eNULL ! Low! Medium! MD5 ! Exp! Dss! Psk! SRP !kECDH ! Camellia! RC4'
	
	• defines that the encryption algorithm is applied in the above order, from left to right
	SSLHonorCipherOrder on
	
	• Disables the compression of SSL Traffic
	SSLCompression off
	
	• ensures that every session gets a ticket
	SSLSessionTickets off
	
	Path specification to the certificate
	SSLCertificateFile /letsencrypt/live/<domain>.<tld> /cert.pem</tld> </domain>
	
	Path specification to Privateky
	SSLCertificateKeyFile /letsencrypt/live/<domain>.<tld> /privkey.pem</tld> </domain>
	
	Path announcement to the certificate chain
	SSLCertificateChainFile /letsencrypt/live/<domain>.<tld> /chain.pem</tld> </domain>
	• quasi standarad for the determination of the original protocol
	RequestHeader append "X-Forwarded-Proto" "https"
	
	• additional information that was originally SSL in the connection
	RequestHeader set "X-Forwarded-Ssl" "on"
	<Location "/"=""></Location>
		ProxyPass http://xxx.xxx.xxx.xxx:8080/
		ProxyPassReverse http://xxx.xxx.xxx.xxx:8080/
	

Finally, we add two X-headers that can be used by browsers or by applications. These are virtually standards on the Internet (the two used) and are used by many applications. These only mean that we are allowed to forward SSL traffic with a reverse proxy and that the original traffic is HTTPs encrypted. At the very end comes our location part, which represents the actual forwarding to the service in our “backend”.

We now need to check whether our Apache can really access our SSL certificate files. In order for us to apply the rights to the correct folders, one should understand a little how the folders are created by CertBot. CertBot creates all the data in the order<IP>”Container”letsencrypt”</IP> after our configuration. There we see the following folders and their permissions by means of SSH:

[~]ls -al /share/Container/letsencrypt/
total 76
drwxrwxrwx 13 admin everyone 4096 2019-06-22 10:36 ./
drwxrwxrwx 14 admin administrators 4096 2019-06-22 09:34 .. /
drwxrw-rw- 4 admin administrators 4096 2019-04-22 20:15
drwxrwxrwx 3 admin everyone 4096 2019-04-28 12:57 archive/
drwxrw-rw- 2 admin administrators 4096 2019-04-28 12:57 csr/
drwxrw-rw- 3 admin everyone 4096 2019-04-28 12:38 data/
drwxrw-rw- 3 admin administrators 4096 2019-04-21 11:21 etc/
drwxrw-rw- 2 admin administrators 4096 2019-04-28 12:57 keys/
drwxrwxrwx 3 admin everyone 4096 2019-04-28 12:57 live/
drwxrw-rw- 2 admin everyone 4096 2019-06-20 21:49 log/
drwxrw-rw- 2 admin administrators 4096 2019-04-28 12:57
drwxrw-rw- 5 admin administrators 4096 2019-04-22 19:55 renewal-hooks/
-rwxrw-rw- 1 admin administrators 64 2019-01-01 21:29 .updated-options-ssl-apache-conf-digest.txt*
drwxrw-rw- 2 admin administrators 4096 2019-04-21 11:21 var/

CertBot creates the currently valid certificates under the “live” folder, and all the certificates it requests and signs in the archive folder. The joke is that under “live” there are only symbolic links to the files under “archive”. Therefore, we need to provide both folders with the same permissions.

chmod 777 -R /share/Container/letsencrypt/live
chmod 777 -R /share/Container/letsencrypt/archive
chown admin:everyone -R /share/Container/letsencrypt/archive
chown admin:everyone -R /share/Container/letsencrypt/live

With 777, this is unfortunately quite a lot of rights that you apply to the folders live and “archive”, but apparently no other way possible. All my attempts to get this with fewer rights have failed for me.

Now, of course, you should not forget to open the port 443 on your router and (as in our example above) to redirect to the internal port 8443, to the IP of the revreseproxy container. This allows you to access your new website from the Internet. If you just don’t know how to do it, check part 1, it’s described for port 80 and you’re just replacing 80 with 443, or 8443.

10) Reverseproxy vHost – HTTP vHost despite HTTPs

In order for everything to really work with CertBot (I’m honest, I had to add that) at least one HTTP vHost must be available in Apache, which we simply enter somewhere in the Config and leave next to the Rewrites and SSL-vHosts and then also a renew of the certificates go without which we have a problem. The vHost doesn’t really have to work, but it needs to be accessible to CertBot.

########################
#HTTPs vHosts
########################
<VirtualHost *:8181=""></VirtualHost>
	Server name <domain>.<tld> </tld> </domain>

11) Reverseproxy vHost – Full File

For those who at times felt confused about what the full file would look like, here’s complete.

########################
CertBot Configs for all!
########################
Set an Alis
Alias /.well-known/acme-challenge/ "/letsencrypt/data/.well-known/acme-challenge/"
• determine the record
<Directory "/letsencrypt/data/.well-known/acme-challenge/"=""></Directory>
    • allow each IP to address the directory
    Require all granted
    The server has an index for the directory and is able to track symbolic links in the file path
    Options Indexes -FollowSymLinks
    . .htaccess files in which other settings for directories may exist are ignored by the "none"
    AllowOverride None
########################
#HTTP rewrites
########################
engine #Einschalten
RewriteEngine on
#Bedingung: Do not apply rewrites until the requested file is a valid one!
RewriteCond %-REQUEST_FILENAME-f
If a valid file now appears in the path "well-known", do nothing and stop all further rewrites!
RewriteRule .well-known/.+ -[END]
• If there is no "well-known" beforekahm, write everything on HTTPs
RewriteRule . . . . . . . . . . . . HTTP_HOST . . . . . . . . . . . . . . . . . . . . . . . . . . . .[NC,R=301,L]
SSL CONFIGS
• turn on the SSL-Enginge
SSLUseStapling on
Set the OCSP responder timeout to 5 seconds
SSLStaplingResponderTimeout 5
• Do not send the CA any responder errors
SSLStaplingReturnResponderErrors off
Cache the OCSP responses using shmbc in the path ...
SSLStaplingCache shmcb:/var/run/ocsp(128000)
Use the Apache standard method to decrypt private keys at server startup
SSLPassPhraseDialog builtin
Define the location where SSL caches are stored
SSLSessionCache "shmcb:/opt/bitnami/apache/logs/ssl_scache(512000)"
• Remove SSL caches after 300 seconds if they are unused
SSLSessionCacheTimeout 300
########################
#HTTPs vHosts
########################
<VirtualHost *:8181=""></VirtualHost>
	Server name lendel.cloud
<VirtualHost *:8443=""></VirtualHost>
	This is the name of the vHost which should be equal to the domain or subdomain
	Server name lendel.cloud
	
	here the SSL-Enginge is activated for the vHost
	SSLEngine on
	
	This is the activation of the so-called " HSTS
	Header always set Strict transport security "max-age=31536000; includeSubDomains; preload"
	
	• defines which protocols we allow for HTTPs
	SSLProtocol all -TLSv1 -TLSv1.1 -SSLv2 -SSLv3
	
	• defines the encryption algorithms used
	SSLCipherSuite 'kEECDH+ECDSA kEECDH kEDH HIGH +SHA !aNULL !eNULL ! Low! Medium! MD5 ! Exp! Dss! Psk! SRP !kECDH ! Camellia! RC4'
	
	• defines that the encryption algorithm is applied in the above order, from left to right
	SSLHonorCipherOrder on
	
	• Disables the compression of SSL Traffic
	SSLCompression off
	
	• ensures that every session gets a ticket
	SSLSessionTickets off
	
	Path specification to the certificate
	SSLCertificateFile /letsencrypt/live/lendel.cloud/cert.pem
	
	Path specification to Privateky
	SSLCertificateKeyFile /letsencrypt/live/lendel.cloud/privkey.pem
	
	Path announcement to the certificate chain
	SSLCertificateChainFile /letsencrypt/live/lendel.cloud/chain.pem
	• quasi standarad for the determination of the original protocol
	RequestHeader append "X-Forwarded-Proto" "https"
	
	• additional information that was originally SSL in the connection
	RequestHeader set "X-Forwarded-Ssl" "on"
	<Location "/"=""></Location>
		ProxyPass http://xxx.xxx.xxx.xxx:8080/
		ProxyPassReverse http://xxx.xxx.xxx.xxx:8080/
	

11) Automation of certificate renewal

We can now automate the renewal of the certificate, which is due every 90 days, so we don’t have to do that. Unfortunately, I’ve only determined the option so far to do it via Crontab, which is actually part of the NAS in the case and not part of the container, which means we’re losing a little “portability,” but that’s the way it is here.

The important thing here is that we call the command as an absolute path. For this we find out where our docker is installed with :

which docker

Now that gives you a path that may look like this:

/share/CACHEDEV1_DATA/.qpkg/container-station/bin/docker

If your path differs from mine, then you have to adjust your path in the code section.

Because Qnap seems to have its own way of managing crontabs, we have to proceed as follows so that our crontab is not deleted after a restart.

vi /etc/config/crontab

Now with VI you should be in view mode of your crontab file. Now press “Ins” on your keyboard and navigate down to the last line and add one if necessary. There you insert:

0 23 * * * /share/CACHEDEV1_DATA/.qpkg/container-station/bin/docker run -t --rm -v /share/Container/letsencrypt/log:/var/log/letsencrypt -v /share/Container/letsencrypt:/etc/letsencrypt -v /share/Container/letsencrypt/data:/data/letsencrypt certbot/certbot renew --webroot --quiet"

Now the explanation: The first 5 characters determine the exact time when the following command is to be executed. The first character is the minute, then the hour, the day, the month and then the weekday when the command is to be executed. In the example above this means that we execute it at minute 0 in hour 23 on every day of the month and week. So simply every day at 23:00. The command we execute is of course very similar to the command before, except that we do a “renew” at the end in Webroot and Quiet Mode. WARNING: I have already removed the parameter “–dry-run”!

In order for the modified crontab file to be loaded, you need to deliberately load it and then restart the service.

crontab /etc/config/crontab && /etc/init.d/crond.sh restart

If you want to check if it worked, a log file should appear in the /share/Container/LetsEncrypt/Log folder at 11pm every evening.

12) Conclusion

We have built a vHost, which can now be reached via CertBot via port 80 from the Internet. When a browser accesses, it is always redirected to HTTPS (port 443) and cannot communicate with our website unsecured. In addition, we have built in common SSL parameters that make the protocol sufficiently secure and we have automated the renewal process of the certificate. So we don’t have a job for the time being! Except we’re adding more vHosts now for more services we want.

13) Outlook

Other services are exactly what we want. So far, we have centralized our contacts and calendars on our NAS, thus also safeguarding all of this with HTTPs as an example. Now let’s take a look at how we can securely deploy KeePass as a password safe via our NAS on the Internet to have our passwords everywhere!

Share this Post

Leave a Comment

Your email address will not be published. Required fields are marked *

*
*