OK - updated the cert on asustor nas

https://clickety-clack.click/ssl-use-certbot-openssl-steps/#nascertbot

attempted to go this route- but as you can see - still need to work out what ADM does for PATH problems.

SO - went the default / scroched earth route -

• Uninsatlled all certificated

• Uninstalled (from app central) - Let's Encrypt Acme Client

• Restarted

• Reinstalled Let's Encrypt Acme Client (app central)

• Went through certrificate manger to set up cert -

WORKED!!

WORD OF WARNING -

you can end up with errors

https://forum.asustor.com/viewtopic.php?f=240&t=13190

Re: Couple of issues...

by wingstyle » Wed Sep 28, 2022 6:15 am

Well, I decided to try it. No guts no glory, right.

I first exported my myasustor.com cert and then uninstalled and reinstalled the Let's Encrypt ACME Client. It Worked!!! I was able to get a cert for both my asustor and my afraid ddns. Thanks a million ilike2burnthings.

• wingstyle

Re: Couple of issues...

by ilike2burnthing » Wed Sep 28, 2022 6:16 am

Glad to hear it!

• ilike2burnthing

   

Re: Couple of issues...

by wingstyle » Wed Sep 28, 2022 11:52 pm

Well, all is not good. I got an email from Let's Encrypt saying one or more of my certificates has been marked as compromised an they are required to revoke any certificates which contain that public key. They showed me three hex numbers saying they are revoked. I didn't know which were revoked from the numbers. I figured out which cert was revoked because it wasn't working (one works and one doesn't). They say: 'If your ACME client generates a new key on every renewal, all you need to do is renew your certificate. If you are using the same key for each renewal, you will need to regenerate that key'. I renewed the one that wasn't working and it still didn't work. I then removed it and generated it again, but it still doesn't work. The ACME client for Asustor must not generate a new key on every renewal.

So my problem is, I don't know how to generate a new key for the one that isn't working. Any thoughts?

That did happen to me once - not sure why it was ok this time.

"
spiffy@spiffynasty:/volume1/home/spiffy 
 python --version
Python 2.7.17
spiffy@spiffynasty:/volume1/home/spiffy  pip --version
pip 1.4.1 from /volume1/.@plugins/AppCentral/python/lib/python2.7/site-packages/pip-1.4.1-py2.7.egg (python 2.7)
spiffy@spiffynasty:/volume1/home/spiffy
pip install cryptography && pip install certbot
Downloading/unpacking cryptography
  Cannot fetch index base URL https://pypi.python.org/simple/
  Could not find any downloads that satisfy the requirement cryptography
Cleaning up...
No distributions at all found for cryptography
Storing complete log in /home/spiffy/.pip/pip.log
spiffy@spiffynasty:/volume1/home/spiffy  cd /usr/local/AppCentral/python/bin/certbot
-sh: cd: can't cd to /usr/local/AppCentral/python/bin/certbot: No such file or directory
spiffy@spiffynasty:/volume1/home/spiffy 
spiffy@spiffynasty:/volume1/home/spiffy $ python --version
Python 2.7.17
spiffy@spiffynasty:/volume1/home/spiffy $ pip --version
pip 1.4.1 from /volume1/.@plugins/AppCentral/python/lib/python2.7/site-packages/pip-1.4.1-py2.7.egg (python 2.7)
spiffy@spiffynasty:/volume1/home/spiffy $ pip install cryptography && pip install certbot
Downloading/unpacking cryptography
Cannot fetch index base URL https://pypi.python.org/simple/
Could not find any downloads that satisfy the requirement cryptography
Cleaning up...
No distributions at all found for cryptography
Storing complete log in /home/spiffy/.pip/pip.log
spiffy@spiffynasty:/volume1/home/spiffy $ cd /usr/local/AppCentral/python/bin/certbot
-sh: cd: can't cd to /usr/local/AppCentral/python/bin/certbot: No such file or directory
spiffy@spiffynasty:/volume1/home/spiffy $ which python
/usr/local/bin/python
spiffy@spiffynasty:/volume1/home/spiffy $ python --version
Python 2.7.17
spiffy@spiffynasty:/volume1/home/spiffy $ python3 --verions
unknown option --verions
usage: python3 [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try `python -h' for more information.
spiffy@spiffynasty:/volume1/home/spiffy $ python3 --version
Python 3.10.11
spiffy@spiffynasty:/volume1/home/spiffy $ pip3 --version
pip 23.2.1 from /usr/local/AppCentral/python3/lib/python3.10/site-packages/pip (python 3.10)
spiffy@spiffynasty:/volume1/home/spiffy $ pip3 install cryptography && pip install certbot
Collecting cryptography
Obtaining dependency information for cryptography from
https://files.pythonhosted.org/packages/14/fd/dd5bd6ab0d12476ebca579cbfd48d31bd90fa28fa257b209df585dcf62a0/cryptography-41.0.7-cp37-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata
Downloading cryptography-41.0.7-cp37-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (5.2 kB)
Collecting cffi>=1.12 (from cryptography)
Obtaining dependency information for cffi>=1.12 from
https://files.pythonhosted.org/packages/c9/7c/43d81bdd5a915923c3bad5bb4bff401ea00ccc8e28433fb6083d2e3bf58e/cffi-1.16.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata
Downloading cffi-1.16.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (1.5 kB)
Collecting pycparser (from cffi>=1.12->cryptography)
Downloading pycparser-2.21-py2.py3-none-any.whl (118 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 118.7/118.7 kB 1.1 MB/s eta 0:00:00
Downloading cryptography-41.0.7-cp37-abi3-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (4.4 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.4/4.4 MB 22.0 MB/s eta 0:00:00
Downloading cffi-1.16.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (443 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 443.9/443.9 kB 9.8 MB/s eta 0:00:00
Installing collected packages: pycparser, cffi, cryptography
Successfully installed cffi-1.16.0 cryptography-41.0.7 pycparser-2.21

[notice] A new release of pip is available: 23.2.1 -> 23.3.1
[notice] To update, run: python3 -m pip install --upgrade pip
Downloading/unpacking certbot
Cannot fetch index base URL https://pypi.python.org/simple/
Could not find any downloads that satisfy the requirement certbot
Cleaning up...
No distributions at all found for certbot
Storing complete log in /home/spiffy/.pip/pip.log
spiffy@spiffynasty:/volume1/home/spiffy $ python3 -m pip install --upgrade pip
Requirement already satisfied: pip in /volume1/.@plugins/AppCentral/python3/lib/python3.10/site-packages (23.2.1)
Collecting pip
Obtaining dependency information for pip from
https://files.pythonhosted.org/packages/47/6a/453160888fab7c6a432a6e25f8afe6256d0d9f2cbd25971021da6491d899/pip-23.3.1-py3-none-any.whl.metadata
Downloading pip-23.3.1-py3-none-any.whl.metadata (3.5 kB)
Downloading pip-23.3.1-py3-none-any.whl (2.1 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 2.1/2.1 MB 12.0 MB/s eta 0:00:00
Installing collected packages: pip
Attempting uninstall: pip
Found existing installation: pip 23.2.1
Uninstalling pip-23.2.1:
Successfully uninstalled pip-23.2.1
WARNING: The scripts pip, pip3 and pip3.10 are installed in '/usr/local/AppCentral/python3/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed pip-23.3.1
spiffy@spiffynasty:/volume1/home/spiffy $ which pip3
/usr/local/bin/pip3
spiffy@spiffynasty:/volume1/home/spiffy $ pip3 install cryptography && pip install certbot
Requirement already satisfied: cryptography in /volume1/.@plugins/AppCentral/python3/lib/python3.10/site-packages
(41.0.7)
Requirement already satisfied: cffi>=1.12 in /volume1/.@plugins/AppCentral/python3/lib/python3.10/site-packages (from
cryptography) (1.16.0)
Requirement already satisfied: pycparser in /volume1/.@plugins/AppCentral/python3/lib/python3.10/site-packages (from cff
i>=1.12->cryptography) (2.21)
Downloading/unpacking certbot
Cannot fetch index base URL https://pypi.python.org/simple/
Could not find any downloads that satisfy the requirement certbot
Cleaning up...
No distributions at all found for certbot
Storing complete log in /home/spiffy/.pip/pip.log
spiffy@spiffynasty:/volume1/home/spiffy $ pip install cryptography && pip install certbot
Downloading/unpacking cryptography
Cannot fetch index base URL https://pypi.python.org/simple/
Could not find any downloads that satisfy the requirement cryptography
Cleaning up...
No distributions at all found for cryptography
Storing complete log in /home/spiffy/.pip/pip.log
spiffy@spiffynasty:/volume1/home/spiffy $ pip install certbot
Downloading/unpacking certbot
Cannot fetch index base URL https://pypi.python.org/simple/
Could not find any downloads that satisfy the requirement certbot
Cleaning up...
No distributions at all found for certbot
Storing complete log in /home/spiffy/.pip/pip.log

Upgrade certbot - monthly

sudo /opt/certbot/bin/pip install --upgrade certbot

SIMPLIFED CERTBOT INSTALL

https://support.hostinger.com/en/articles/6865487-how-to-install-ssl-on-vps-using-certbot

How to Install SSL on VPS Using Certbot

Installing an SSL certificate on your VPS with Certbot using Python

If your VPS operating system does not have a control panel or it does not integrate a free SSL option, you can generate and install a free Let’s Encrypt SSL with Certbot. Just follow these steps:

Step 1 - Prepare the VPS

Before installing the SSL, make sure that your VPS:

• Has a web server running (eg. Apache, NGINX, etc.)
• The website hosted on your VPS is set up to be opened by entering the domain name on the address bar – not the IP
• The domain is fully propagated and pointing to your VPS child nameservers. Installing an SSL with Certbot while the domain is still propagating will create a self-signed certificate, which may cause errors when accessing your website

Step 2 - Install Dependencies

Certbot recommends using snapd for installation. Since snapd is not supported on Hostinger Linux-based VPS, you can use Python by installing it first on your server.

To start the process, connect to your VPS using SSH. Next, install the required dependencies (Python 3.6+, venv and Augeas) according to your OS:

For APT-based distributions (such as Debian or Ubuntu), run the following:

>sudo apt update
sudo apt install python3 python3-venv libaugeas0

For RPM-based distributions (Fedora, CentOS), use this command:

>sudo dnf install python3 augeas-libs

NOTES:

• For older distributions that do not support dnf, use yum instead
• Some RHEL-based distributions use python3x instead of python3 (eg. python38). Please refer to the documentation of your Linux distribution 🙂
• If you have issues installing cryptography, you may need to install additional dependencies. Check this article for more information: Building Cryptography on Linux

Step 3 - Install Certbot

To prevent any conflicts with previous versions, remove any Certbot packages already installed before installing the newest version. You can use your package manager (apt, dnf, yum, etc.) for this.

Once it's ready, run the following to set up a Python virtual environment:

>sudo python3 -m venv /opt/certbot/
sudo /opt/certbot/bin/pip install --upgrade pip

To install Certbot, run this on Apache:

>sudo /opt/certbot/bin/pip install certbot certbot-apache

Or this for NGINX:

>sudo /opt/certbot/bin/pip install certbot certbot-nginx

Next, create a symbolic link so that Certbot can be executed from any path:

>sudo ln -s /opt/certbot/bin/certbot /usr/bin/certbot

Install and activate SSL for your websites and have Certbot do all the configurations by executing the following command for Apache:

>sudo certbot --apache

For NGINX:

>sudo certbot --nginx

NOTE:

• To obtain only the certificates and configure the SSL manually, append certonly after certbot and before --apache or --nginx.

Since the SSL is active for 90 days, it is recommended to set up automatic renewal. You can do so by running the following:

>echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

That’s it, you can now visit your website on an incognito window to verify that SSL is properly installed and working 😊

Additional resources:

• If your OS has a control panel (such as Cyberpanel or cPanel), check this article: How to install SSL on VPS
• You can find more alternative methods to install Certbot here: Install Certbot using Docker, pip

Auto-Renewal

echo "0 0,12 * * * root /opt/certbot/bin/python -c 'import random; import time; time.sleep(random.random() * 3600)' && sudo certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

 
https://eff-certbot.readthedocs.io/en/stable/using.html#setting-up-automated-renewal
Setting up
    automated renewal¶
If you think you may need to set up automated renewal, follow these instructions to set up a scheduled task to
  automatically renew your certificates in the background. If you are unsure whether your system has a pre-installed
  scheduled task for Certbot, it is safe to follow these instructions to create one.
Note
If you’re using Windows, these instructions are not neccessary as Certbot on Windows comes with a scheduled task for
  automated renewal pre-installed.
If you are using macOS and installed Certbot using Homebrew, follow the instructions at https://certbot.eff.org/instructions to
  set up automated renewal. The instructions below are not applicable on macOS.
Run the following line, which will add a cron job to /etc/crontab:
>SLEEPTIME=$(awk 'BEGIN{srand(); print int(rand()*(3600+1))}'); echo "0 0,12 * * * root sleep $SLEEPTIME && certbot renew -q" | sudo tee -a /etc/crontab > /dev/null

If you needed to stop your webserver to run Certbot, you’ll want to add pre and post hooks
  to stop and start your webserver automatically. For example, if your webserver is HAProxy, run the following commands
  to create the hook files in the appropriate directory:
>sudo sh -c 'printf "#!/bin/sh\nservice haproxy stop\n" > /etc/letsencrypt/renewal-hooks/pre/haproxy.sh'
sudo sh -c 'printf "#!/bin/sh\nservice haproxy start\n" > /etc/letsencrypt/renewal-hooks/post/haproxy.sh'
sudo chmod 755 /etc/letsencrypt/renewal-hooks/pre/haproxy.sh
sudo chmod 755 /etc/letsencrypt/renewal-hooks/post/haproxy.sh

Congratulations, Certbot will now automatically renew your certificates in the background.
If you are interested in learning more about how Certbot renews your certificates, see the Renewing certificates
  section above.
 

Step
    5 — Verifying Certbot Auto-Renewal
Let’s Encrypt’s certificates are only valid for ninety days. This is to encourage users to automate their certificate
  renewal process, as well as to ensure that misused certificates or stolen keys will expire sooner rather than later.

The certbot package we installed takes care of renewals by including a renew script to
  /etc/cron.d, which is managed by a systemctl service called certbot.timer. This
  script runs twice a day and will automatically renew any certificate that’s within thirty days of expiration.
To check the status of this service and make sure it’s active and running, you can use:
sudo systemctl status certbot.timer

Copy
You’ll get output similar to this:
>Output● certbot.timer - Run certbot twice daily
     Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-04-28 17:57:48 UTC; 17h ago
    Trigger: Wed 2020-04-29 23:50:31 UTC; 12h left
   Triggers: ● certbot.service

Apr 28 17:57:48 fine-turtle systemd[1]: Started Run certbot twice daily.

To test the renewal process, you can do a dry run with certbot:
sudo certbot renew --dry-run

Copy
If you see no errors, you’re all set. When necessary, Certbot will renew your certificates and reload Apache to pick
  up the changes. If the automated renewal process ever fails, Let’s Encrypt will send a message to the email you
  specified, warning you when your certificate is about to expire.




Where are my
    certificates?¶

All generated keys and issued certificates can be found in /etc/letsencrypt/live/$domain, where
  $domain is the certificate name (see the note below). Rather than copying, please point your (web) server
  configuration directly to those files (or create symlinks). During the renewal,
  /etc/letsencrypt/live is updated with the latest necessary files.
Note
The certificate name $domain used in the path /etc/letsencrypt/live/$domain follows this
  convention:

  
it is the name given to --cert-name,
  
if --cert-name is not set by the user it is the first domain given to --domains,
  
if the first domain is a wildcard domain (eg. *.example.com) the certificate name will be
    example.com,
  
if a name collision would occur with a certificate already named example.com, the new certificate
    name will be constructed using a numerical sequence as example.com-001.


For historical reasons, the containing directories are created with permissions of 0700 meaning that
  certificates are accessible only to servers that run as the root user. If you will never downgrade to an older
    version of Certbot, then you can safely fix this using
  chmod 0755 /etc/letsencrypt/{live,archive}.
For servers that drop root privileges before attempting to read the private key file, you will also need to use
  chgrp and chmod 0640 to allow the server to read
  /etc/letsencrypt/live/$domain/privkey.pem.
The following files are available:

  

    
privkey.pem
    
Private key for the certificate.WarningThis must be kept secret at all times! Never share it
      with anyone, including Certbot developers. You cannot put it into a safe, however - your server still needs to
      access this file in order for SSL/TLS to work.NoteAs of Certbot version 0.29.0, private keys for new certificate
      default to 0600. Any changes to the group mode or group owner (gid) of this file will be preserved on
      renewals.This is what Apache needs for SSLCertificateKeyFile, and
      Nginx for ssl_certificate_key.
  
  

    
fullchain.pem
    
All certificates, including server certificate (aka leaf certificate or end-entity certificate).
      The server certificate is the first one in this file, followed by any intermediates.This is what Apache >=
      2.4.8 needs for SSLCertificateFile, and what
      Nginx needs for ssl_certificate.
  
  

    
cert.pem and chain.pem (less common)
    
cert.pem contains the server certificate by itself, and chain.pem contains the
      additional intermediate certificate or certificates that web browsers will need in order to validate the server
      certificate. If you provide one of these files to your web server, you must provide both of them,
      or some browsers will show “This Connection is Untrusted” errors for your site, some of the time.Apache < 2.4.8 needs these for SSLCertificateFile. and SSLCertificateChainFile,
      respectively.If you’re using OCSP stapling with Nginx >= 1.3.7, chain.pem should be provided as
      the ssl_trusted_certificate
      to validate OCSP responses.
  


Note
All files are PEM-encoded. If you need other format, such as DER or PFX, then you could convert using
  openssl. You can automate that with --deploy-hook if you’re using automatic renewal.
 

INSTALL CERTBOT FULL

Ubuntu 20.04

Introduction

Let’s Encrypt is a Certificate Authority (CA) that facilitates obtaining and installing free TLS/SSL certificates, thereby enabling encrypted HTTPS on web servers. It simplifies the process by providing a software client, Certbot, that attempts to automate most (if not all) of the required steps. Currently, the entire process of obtaining and installing a certificate is fully automated on both Apache and Nginx.

In this guide, we’ll use Certbot to obtain a free SSL certificate for Apache on Ubuntu 20.04, and make sure this certificate is set up to renew automatically.

This tutorial uses a separate virtual host file instead of Apache’s default configuration file for setting up the website that will be secured by Let’s Encrypt. We recommend creating new Apache virtual host files for each domain hosted in a server, because it helps to avoid common mistakes and maintains the default configuration files as a fallback setup.

Prerequisites

To follow this tutorial, you will need:

• One Ubuntu 20.04 server set up by following this initial server setup for Ubuntu 20.04 tutorial, including a sudo non-root user and a firewall.

• A fully registered domain name. This tutorial will use your_domain as an example throughout. You can purchase a domain name on Namecheap, get one for free on Freenom, or use the domain registrar of your choice.

• Both of the following DNS records set up for your server. You can follow this introduction to DigitalOcean DNS for details on how to add them.

  • An A record with your_domain pointing to your server’s public IP address.
  • An A record with www.your_domain pointing to your server’s public IP address.

• Apache installed by following How To Install Apache on Ubuntu 20.04. Be sure that you have a virtual host file for your domain. This tutorial will use /etc/apache2/sites-available/your_domain.conf as an example.

Step 1 — Installing Certbot

In order to obtain an SSL certificate with Let’s Encrypt, we’ll first need to install the Certbot software on your server. We’ll use the default Ubuntu package repositories for that.

We need two packages: certbot, and python3-certbot-apache. The latter is a plugin that integrates Certbot with Apache, making it possible to automate obtaining a certificate and configuring HTTPS within your web server with a single command.

sudo apt install certbot python3-certbot-apache

Copy

You will be prompted to confirm the installation by pressing Y, then ENTER.

Certbot is now installed on your server. In the next step, we’ll verify Apache’s configuration to make sure your virtual host is set appropriately. This will ensure that the certbot client script will be able to detect your domains and reconfigure your web server to use your newly generated SSL certificate automatically.

Step 2 — Checking your Apache Virtual Host Configuration

In order to be able to automatically obtain and configure SSL for your web server, Certbot needs to find the correct virtual host within your Apache configuration files. Your server domain name(s) will be retrieved from the ServerName and ServerAlias directives defined within your VirtualHost configuration block.

If you followed the virtual host setup step in the Apache installation tutorial, you should have a VirtualHost block set up for your domain at /etc/apache2/sites-available/your_domain.conf with the ServerName and also the ServerAlias directives already set appropriately.

To check this up, open the virtual host file for your domain using nano or your preferred text editor:

sudo nano /etc/apache2/sites-available/your_domain.conf

Copy

Find the existing ServerName and ServerAlias lines. They should look like this:

/etc/apache2/sites-available/your_domain.conf

>...
ServerName your_domain
ServerAlias www.your_domain
...

If you already have your ServerName and ServerAlias set up like this, you can exit your text editor and move on to the next step. If you’re using nano, you can exit by typing CTRL+X, then Y and ENTER to confirm.

If your current virtual host configuration doesn’t match the example, update it accordingly. When you’re done, save the file and quit the editor. Then, run the following command to validate your changes:

sudo apache2ctl configtest

Copy

You should get a Syntax OK as a response. If you get an error, reopen the virtual host file and check for any typos or missing characters. Once your configuration file’s syntax is correct, reload Apache so that the changes take effect:

sudo systemctl reload apache2

Copy

With these changes, Certbot will be able to find the correct VirtualHost block and update it.

Next, we’ll update the firewall to allow HTTPS traffic.

Step 3 — Allowing HTTPS Through the Firewall

If you have the UFW firewall enabled, as recommended by the prerequisite guides, you’ll need to adjust the settings to allow HTTPS traffic. Upon installation, Apache registers a few different UFW application profiles. We can leverage the Apache Full profile to allow both HTTP and HTTPS traffic on your server.

To verify what kind of traffic is currently allowed on your server, you can use:

sudo ufw status

Copy

If you have followed one of our Apache installation guides, your output should look something like this, meaning that only HTTP traffic on port 80 is currently allowed:

>OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere                  
Apache                     ALLOW       Anywhere             
OpenSSH (v6)               ALLOW       Anywhere (v6)             
Apache (v6)                ALLOW       Anywhere (v6)

To additionally let in HTTPS traffic, allow the “Apache Full” profile and delete the redundant “Apache” profile:

sudo ufw allow 'Apache Full'
sudo ufw delete allow 'Apache'

Copy

Your status will now look like this:

sudo ufw status

Copy

>OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere                  
Apache Full                ALLOW       Anywhere                  
OpenSSH (v6)               ALLOW       Anywhere (v6)             
Apache Full (v6)           ALLOW       Anywhere (v6)        

You are now ready to run Certbot and obtain your certificates.

Step 4 — Obtaining an SSL Certificate

Certbot provides a variety of ways to obtain SSL certificates through plugins. The Apache plugin will take care of reconfiguring Apache and reloading the configuration whenever necessary. To use this plugin, type the following:

sudo certbot --apache

Copy

This script will prompt you to answer a series of questions in order to configure your SSL certificate. First, it will ask you for a valid e-mail address. This email will be used for renewal notifications and security notices:

>OutputSaving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): you@your_domain

After providing a valid e-mail address, hit ENTER to proceed to the next step. You will then be prompted to confirm if you agree to Let’s Encrypt terms of service. You can confirm by pressing A and then ENTER:

>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: A

Next, you’ll be asked if you would like to share your email with the Electronic Frontier Foundation to receive news and other information. If you do not want to subscribe to their content, type N. Otherwise, type Y. Then, hit ENTER to proceed to the next step.

>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: N

The next step will prompt you to inform Certbot of which domains you’d like to activate HTTPS for. The listed domain names are automatically obtained from your Apache virtual host configuration, that’s why it’s important to make sure you have the correct ServerName and ServerAlias settings configured in your virtual host. If you’d like to enable HTTPS for all listed domain names (recommended), you can leave the prompt blank and hit ENTER to proceed. Otherwise, select the domains you want to enable HTTPS for by listing each appropriate number, separated by commas and/ or spaces, then hit ENTER.

>Which names would you like to activate HTTPS for?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: your_domain
2: www.your_domain
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 

You’ll see output like this:

>Obtaining a new certificate
Performing the following challenges:
http-01 challenge for your_domain
http-01 challenge for www.your_domain
Enabled Apache rewrite module
Waiting for verification...
Cleaning up challenges
Created an SSL vhost at /etc/apache2/sites-available/your_domain-le-ssl.conf
Enabled Apache socache_shmcb module
Enabled Apache ssl module
Deploying Certificate to VirtualHost /etc/apache2/sites-available/your_domain-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/your_domain-le-ssl.conf
Deploying Certificate to VirtualHost /etc/apache2/sites-available/your_domain-le-ssl.conf

Next, you’ll be prompted to select whether or not you want HTTP traffic redirected to HTTPS. In practice, that means when someone visits your website through unencrypted channels (HTTP), they will be automatically redirected to the HTTPS address of your website. Choose 2 to enable the redirection, or 1 if you want to keep both HTTP and HTTPS as separate methods of accessing your website.

>Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2

After this step, Certbot’s configuration is finished, and you will be presented with the final remarks about your new certificate, where to locate the generated files, and how to test your configuration using an external tool that analyzes your certificate’s authenticity:

>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://your_domain and
https://www.your_domain

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=your_domain
https://www.ssllabs.com/ssltest/analyze.html?d=www.your_domain
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/your_domain/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/your_domain/privkey.pem
   Your cert will expire on 2020-07-27. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Your certificate is now installed and loaded into Apache’s configuration. Try reloading your website using https:// and notice your browser’s security indicator. It should point out that your site is properly secured, typically by including a lock icon in the address bar.

You can use the SSL Labs Server Test to verify your certificate’s grade and obtain detailed information about it, from the perspective of an external service.

In the next and final step, we’ll test the auto-renewal feature of Certbot, which guarantees that your certificate will be renewed automatically before the expiration date.

Step 5 — Verifying Certbot Auto-Renewal

Let’s Encrypt’s certificates are only valid for ninety days. This is to encourage users to automate their certificate renewal process, as well as to ensure that misused certificates or stolen keys will expire sooner rather than later.

The certbot package we installed takes care of renewals by including a renew script to /etc/cron.d, which is managed by a systemctl service called certbot.timer. This script runs twice a day and will automatically renew any certificate that’s within thirty days of expiration.

To check the status of this service and make sure it’s active and running, you can use:

sudo systemctl status certbot.timer

Copy

You’ll get output similar to this:

>Output● certbot.timer - Run certbot twice daily
     Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled)
     Active: active (waiting) since Tue 2020-04-28 17:57:48 UTC; 17h ago
    Trigger: Wed 2020-04-29 23:50:31 UTC; 12h left
   Triggers: ● certbot.service

Apr 28 17:57:48 fine-turtle systemd[1]: Started Run certbot twice daily.

To test the renewal process, you can do a dry run with certbot:

sudo certbot renew --dry-run

Copy

If you see no errors, you’re all set. When necessary, Certbot will renew your certificates and reload Apache to pick up the changes. If the automated renewal process ever fails, Let’s Encrypt will send a message to the email you specified, warning you when your certificate is about to expire.

Conclusion

In this tutorial, you’ve installed the Let’s Encrypt client certbot, configured and installed an SSL certificate for your domain, and confirmed that Certbot’s automatic renewal service is active within systemctl. If you have further questions about using Certbot, their documentation is a good place to start.

In this tutorial, we will show you how to install an SSL certificate on Webmin. If you’ve already generated a CSR code for your certificate, skip the first section and continue with the SSL installation steps. The last part includes useful tips on where to buy the best SSL Certificate for Webmin.

Table of Contents

1. Generate a CSR code on Webmin
2. Install an SSL Certificate on Webmin
3. Test your SSL installation
4. Where to buy the best SSL Certificate for Webmin?

Generate a CSR code on Webmin

When applying for an SSL Certificate, one of your first steps is to generate a Certificate Signing Request (CSR) and send it to the Certificate Authority. The CSR is a small text file with necessary details about your domain and company.

SSL providers use the CSR code to verify the validity of the applicants. If the information within the CSR is correct and up to date, the CAs will sign the SSL Certificate.

You have two options:

1. Use our CSR Generator to create the CSR automatically.
2. Follow our step-by-step tutorial on how to generate CSR in Webmin.

Next, you need to copy the newly generated CSR code including the —–BEGIN CERTIFICATE REQUEST—– and —–END CERTIFICATE REQUEST—– tags into a text editor of your choice. For example, Notepad

Now, you can use the CSR code during the SSL application. If something is wrong with your CSR, you can use our CSR decoder tool to find the error.

Install an SSL Certificate on Webmin

After you’ve successfully applied for your SSL Certificate, and received all the necessary certificate files from the CA, it’s time to install them on your Webmin server.

Step 1. Prepare your SSL files

Download the zip archive and extract the files on your local computer. You must have the following files:

• crt (your primary certificate)
• ca-bundle (your root and intermediate certificates)

Note: yourwebsite_com is your domain name here.

Step 2. Upload your files

1. Log into your Webmin server via the web browser
2. In the left menu, click Others and then select Upload and Download
3. On the main page, select the Upload to server tab
4. In the Files to upload section, locate and add your primary certificate file (the one with .crt extension) and your Ca bundle file (the one with .ca-bundle extension)

Step 3. Configure Apache using Webmin

1. If you don’t have Apache installed, use the Un-used Modules menu from the left pane to install it

2. Go to Servers > Apache Webservers, and from the main page, select the Global Configuration tab

3. In the Global Configuration tab, click the Configure Apache Modules icon

4. A large list containing various apache modules will open. Here, you need to find and tick the “ssl” checkbox, and then click the Enable Selected Modules button

5. It may take a few seconds until the

   Apache Webserver’s

   main page loads. When it’s ready, select

   Create virtual host

   and add the following parameters:

   • Port: select port 443 (the default port for HTTPS connection)
   • Document Root: enter the path to the document root folder
   • Server Name: specify your domain name

6. Click the Create Now button to add a new virtual host

7. A new Existing virtual hosts tab will appear. Inside the tab, locate the virtual host that you’ve just created, and click on the “globe” button next to it

8. From the

   Virtual Server Options

   page choose

   SSL Options

   and adjust the parameters as shown below and then click

   Save

   • Enable SSL? – tick the YES radio button
   • SSL protocols – uncheck the obsolete the SSLv2 and SSLv3 protocols
   • Certificate/private key file – indicate the server path to your primary certificate file (.crt), and your private key file (.key, generated along with the CSR)
   • Certificate authorities file – specify the server path to your bundle file

Step 4. Restart Apache

To complete the SSL installation, you need to restart Apache.

In the left pane, go to System>Boot and Shutdown and tick the Apache checkbox.

Next, scroll down to the very bottom of the page and click Restart.

That’s it! You’ve successfully added an SSL Certificate to your Webmin server.

Test your SSL installation

After you install an SSL Certificate on Webmin, it’s highly recommended to test your SSL installation for potential vulnerabilities. Use one of these advanced SSL tools to scan your website and get instant SSL reports.

Where to buy the best Webmin SSL Certificate?

If you’re looking for a great shopping experience, then SSL Dragon is your best SSL seller. Our intuitive and user-friendly website will smoothly guide you through the entire range of SSL Certificates. All our products are issued by reputable Certificate Authorities and are compatible with Webmin.

Get an SSL certificate now

Enjoy the lowest prices on the market, and dedicated customer support for any certificate you choose. And, if your struggling to find the perfect cert for your website, use our SSL Wizard and Advanced Certificate Filter tools to get a helping hand.

If you find any inaccuracies, or you have details to add to these SSL installation instructions, please feel free to send us your feedback at info@ssldragon.com. Your input would be greatly appreciated! Thank you.

asustor-certbot

Automated Let's Encrypt certificate renewal via certbot on an Asustor NAS box

Note: this project no longer recommends attempting to use certbot on an Asustor NAS due to the increasing difficulties with certbot installation on an Asustor NAS. Alternative options include the Asustor App Central installable "Let's Encrypt ACME Client" app (a wrapper around https://github.com/acmesh-official/acme.sh) and other options that are listed here on the letsencrypt website.

Why does this even exist when there's a certificate management built into the ADM (Asustor Data Master) linux o/s? Here are a few reasons.

The cons of doing certificate management the Asustor way:

1. The behaviour of the ceritificate manager built into ADM is dependent on this Asustor supplied binary: /usr/builtin/bin/certificate. For automated certificate renewal, ADM sets up a crontab job that looks like this: 0 0 * * * TAG=CERTIFICATE /usr/builtin/bin/certificate update-cert so that this process is run continually daily at midnight.

   What does this process do? It renews certificates when all of the requirements for successful certificate renewal are correctly aligned.

   What happens when certificates fail to renew? The process fails silently. Asustor support were unable to describe what happens when certificate renewal fails other than to say "logging of SSL certificate renewal errors is not enabled". /usr/builtin/bin/certificate appears to be an undocumented Asustor binary that has unknown behaviour other than it being confirmed by Asustor that nothing is logged anywhere when certificate renewal fails.

2. Successful certificate renewal via the /usr/builtin/bin/certificate binary is dependent on a web service listening on the NAS on port 80. Port 80 needs to be permanently open to the NAS and a web server needs to be running on the NAS listening on port 80 at all times (typically apache on an Asustor NAS) in order for certificate renewal to succeed. This is a security risk.

   What other requirements are there for successful certificate renewal to occur via /usr/builtin/bin/certificate? Other than port 80 needing to be being permanently open, the requirements are unknown because this binary is undocumented and poorly supported by Asustor.

3. There's lack of flexiblity when relying on /usr/builtin/bin/certificate to perform certificate renewal. Since this binary is undocumented, there is no known way to perform any additional required actions when certificates fail to renew or do renew successfully.

The pros of doing certificate management the certbot way:

1. certbot is well documented.
2. certbot logs everything it does including renewal failure and success.
3. certbot is chainable / extendable. It is possible to perform additional required actions when certificates fail to renew or renew successfully via regular shell scripts.
4. when certbot runs in 'standalone' or 'renew' mode with a http challenge, it spins up a temporary webserver on demand and it is possible to specify which custom port that the LetsEncrypt CA should perform its http callbacks on. Certbot's temporary webserver will always listen on port 80 or port 433 however the CA http callback custom port can be port forwarded / mapped to port 80 / 443.
5. certbot supports obtaining and renewing certificates over an ssl connection.
6. certbot supports dns challenge if that method is preferred over http challenge.
7. certbot is open: https://github.com/certbot/certbot.

Installing certbot on the NAS

1. certbot is written in python, install python from App Central and verify the install python --version.
2. once you have python installed check you have pip installed i.e. pip --version.
3. install certbot with pip i.e. pip install cryptography && pip install certbot.

Note that depending on your Asustor NAS box model and the available tools installed on the NAS box, Certbot installation might not be straightforward. See further details here.

On my AS-202TE, certbot is located here after installation: /usr/local/AppCentral/python/bin/certbot.

Shell scripts included in this github repo

1. https://github.com/jjssoftware/asustor-certbot/blob/master/nas-certbot-renewal.sh

   This is a certbot Let's Encrypt certificate renewal script. It simply calls certbot to perform certificate renewal for any certificates previously created by certbot. This script can be crontab scheduled. Further details are in the script.

2. https://github.com/jjssoftware/asustor-certbot/blob/master/nas-certbot-deploy.sh

   This is a certbot renewal-hooks/deploy script. This script is called by certbot when certificate renewal succeeds. Any custom actions that need to be performed upon successful certificate renewal can be included in a renewal-hooks/deploy script. Further details are in the script.

Can use OpenSSL to create your CSR, it doesn’t need to be created on that same device you’re trying to install it on. You should be able to do this with most devices such as Windows, MacOS, or most servers.

https://www.openssl.org/source/

https://www.noip.com/support/knowledgebase/apache-openssl

Apache OpenSSL

Generating a Certificate Signing Request (CSR) using Apache OpenSSL

A CSR is a file containing your certificate application information, including your Public Key. Generate your CSR and then copy and paste the CSR file into the web form in the enrollment process.

To generate a pair of private key and public Certificate Signing Request (CSR) for a web server, “server”, use the following command:

openssl req -new -nodes -keyout myserver.key -out server.csr

This creates two files. The file myserver.key contains a private key; do not disclose this file to anyone. Carefully protect the private key. In particular, be sure to backup the private key, as there is no means to recover it should it be lost. The private key is used as input in the command to generate a Certificate Signing Request (CSR). You will now be asked to enter details to be entered into your CSR. What you are about to enter is what is called a Distinguished Name or a DN.

For some fields there will be a default value, If you enter ‘.’, the field will be left blank.

—–

Country Name (2 letter code) [AU]: US State or Province Name (full name) [Some-State]: Your State Locality Name (eg, city) []: Your City Organization Name (eg, company) [Internet Widgits Pty Ltd]: Your Company Name Organizational Unit Name (eg, section) []: IT Common Name (eg, YOUR name) []: yourdomain.com Email Address []:

Please enter the following ‘extra’ attributes to be sent with your certificate request

A challenge password []:(leave this blank)

—–

Use the name of the web server as the Common Name (CN). If the domain name is mydomain.com append the domain to the hostname (use the fully qualified domain name).

The fields email address, optional company name and challenge password can be left blank for a web server certificate.

Your CSR will now have been created. Open the server.csr in a text editor and copy and paste the contents into the online enrollment form when requested.

How to generate a CSR using macOS Server

How to generate a CSR using macOS Server

https://www.noip.com/support/knowledgebase/generate-csr-using-macos-server

Below are the current steps to generate a CSR using macOS Server.

1. Click “Certificates” in the Server sidebar.

2. Click the dropdown and choose “Show All Certificates”.

3. Click the add button, then click “Get a Trusted Certificate”.

4. Click “Next”, and enter your information in the fields.

5. Click “Next”, and click “Finish”.

6. Double-click the pending certificate, from the certificates list.

7. Click Save, and then, click the triangle next to the Certificate. You can now copy and paste the text into your No-IP account.

    

For more information on CSR generation using macOS Server, please see their official site here.

How to Receive and Install an SSL Certificate

If you haven’t yet, you’ll first need to purchase a certificate.

• RapidSSL Basic DV will cover one hostname or domain, such as, example.ddns.net.
• RapidSSL Wildcard DV will cover your domain (example.com) and can cover all sub-domains (name.example.com).
• GeoTrust QuickSSL Premium covers only a single hostname or domain, but with a much higher warranty. This has a different method of validation.
• No-IP Vital Encrypt DV SSL will cover one hostname or domain, such as, example.ddns.net. This certificate is included automatically if you have our Plus, Pro, or Enhanced service.

SSL coverage is not automatic so you will need to have it issued to you, and install it, for it to work properly. You can learn how, below.

Locate Your SSL

From your No-IP account, click My Services on the left menu bar, then SSL Certificates. On this page, you will find your certificates. Your goal is to create, and a submit a CSR.

Generate a CSR

If you would like both your domain (example.com) and the www sub-domain (www.example.com) covered by the SSL you will need to add alternative names to your certificate request, please follow our SAN CSR guide for instructions.

You will need to generate a CSR. You can do this from the device that will receive the certificate. We have several guides for different operating systems on how to create a CSR. If you don’t see your server in our knowledge base you can also check out our certificate provider’s knowledgebase.

If you run into any issues submitting the CSR, here’s a list of CSR Upload Errors you may encounter.

The CSR must use the signature algorithm SHA256.

Submit a CSR

Once you have created a CSR, navigate back to your No-IP account under My Services, then SSL Certificates. Locate the SSL that needs the CSR added and click the Add CSR button.

In the pop up that appears is where you will paste the CSR you have generated.

Click the Add CSR button to proceed. Next, you will need to enter your contact information for the SSL.

Click the Confirm button when finished.

SSL Validation and Receiving Your Certificate

You will be given a TXT value for verification. If you have our DNS service on your domain, we will add this record automatically to the hostname listed in the CSR. If the DNS on your domain is managed by another provider, you will need to add this TXT record on their system.

You will need to wait for the verification to complete. This can take up to 24 hours. When verification completes, you will get an email from Digicert with your certificate, and your order ID.

If your SSL is an No-IP Vital Encrypt SSL, you won’t get an email. You will be able to download the certificate straight from the SSL page in your No-IP account.

Installation

Our certificate provider has an extensive knowledge base with instructions on installing your new certificate. Find your server in the list, and follow the instructions.

Once installed and configured on your server, connections to your device will now be secured.

Port Forwarding

Port 80 Redirect

How to Setup and Configure Dynamic DNS (DDNS) in a Draytek Router

How to Port Forward a Draytek Router

How to Setup and Configure Dynamic DNS in a Netgear Router (Genie Firmware)

How to Port Forward a Netgear Router (Old Firmware)

How to Port Forward a ZyXEL Router

How to Port Forward a D-Link Router

How to Port Forward an ASUS Router

How to Port Forward a Linksys Router

How to Port Forward a TP-Link Router

Routers & Firewalls

D-Link Routers With No-IP Support

Port 80 Redirect

Double Network Address Translation (NAT)

My D-Link Router Does Not Include No-IP As An Integrated Dynamic DNS Provider

D-Link Router Configuration for Dynamic DNS

How to Setup DDNS in a Hikvision Camera

How to Setup DDNS in a Trendnet Camera

How to Setup DDNS in a Dahua Device

How to Configure DDNS (Dynamic DNS) in a Router

How to Setup and Configure Dynamic DNS (DDNS) in a Draytek Router

How to Port Forward a Draytek Router

How to Setup and Configure Dynamic DNS in a Netgear Router (Genie Firmware)

How to Port Forward a Netgear Router with Genie Firmware

How to Port Forward a Netgear Router (Old Firmware)

How to Port Forward a ZyXEL Router