certbot https certificate renewal

Introduction

As of the time of writing, the certbot client’s https certificate normally expires after 3 months or 90 days. If you used the automated installation method described in this post then certbot client should autorenew the certificate.

Testing HTTPS Renewal

To test the autorenewal, you can run the certbot client using the –dry-run flag as shown below:


imela@whiscardz:~$ sudo certbot renew --dry-run

Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/build.example.org.conf
-------------------------------------------------------------------------------
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator apache, Installer apache
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for logs.example.org
tls-sni-01 challenge for build.example.org

Waiting for verification...
Cleaning up challenges

-------------------------------------------------------------------------------
new certificate deployed with reload of apache server; fullchain is
/etc/letsencrypt/live/build.example.org/fullchain.pem
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/build.example.org/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
-------------------------------------------------------------------------------

IMPORTANT NOTES:
- 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.
imela@whiscardz:~$

 

Autorenewal Cronjob

As of version 0.10.0, Certbot supports a renew action to check all installed certificates for impending expiry and attempt to renew them. The simplest form is simply

certbot renew

This command attempts to renew any previously-obtained certificates that expire in less than 30 days. The same plugin and options that were used at the time the certificate was originally issued will be used for the renewal attempt, unless you specify other plugins or options.

renew acts on multiple certificates and always takes into account whether each one is near expiry. Because of this, renew is suitable (and designed) for automated use, to allow your system to automatically renew each certificate when appropriate. Since renew only renews certificates that are near expiry it can be run as frequently as you want – since it will usually take no action.

The certbot client package installed takes care of this for us by running certbot renew twice a day via a systemd timer. On non-systemd distributions this functionality is provided by a cron script placed in /etc/cron.d. The task runs twice daily and will renew any certificate that’s within thirty days of expiration.

  • Look at the /etc/cron.d/certbot and you will notice that the renewal will run every 12th hour and has the following syntax:

imela@whiscardz:~$ sudo less /etc/cron.d/certbot

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

  • Once the cronjob runs, you will see the enteries in the lets encrypt logs as shown:

imela@whiscardz:~$ sudo ls /var/log/letsencrypt/

2018-01-08 21:08:19,934:INFO:certbot.renewal:Cert not yet due for renewal
2018-01-08 21:08:19,934:DEBUG:certbot.renewal:no renewal failures

  • You can monitor the logs above for any autorenewal errors

References

Renewing certificates

Verifying Certbot Auto-Renewal

How To Secure Apache with Let’s Encrypt on Ubuntu 16.04

How to renew a letsencrypt.org certificate in a cron job?

How do I schedule the Let’s Encrypt certbot to automatically renew my certificate in cron?

Set Up Auto Renewal

CERTBOT RENEWALS FLAWLESSLY USING CRON (LETS ENCRYPT)

Let’s Encrypt! Checking your HTTPS certificate expiration date

Cronjob At minute 0 past every 12th hour.

Crontab Generator

Install HTTPS Certificate using Let’s Encrypt on Apache 2 Ubuntu 14.04

Introduction

To enable HTTPS on your website, you need to get a certificate (a type of file) from a Certificate Authority (CA). Let’s Encrypt is a CA. In order to get a certificate for your website’s domain from Let’s Encrypt, you have to demonstrate control over the domain. With Let’s Encrypt, you do this using software that uses the ACME protocol, which typically runs on your web host.

Certbot Client

Certbot is a fully-featured, extensible client for the Let’s Encrypt CA (or any other CA that speaks the ACME protocol) that can automate the tasks of obtaining certificates and configuring webservers to use them. This client runs on Unix-based operating systems.

System Requirements

Certbot currently requires Python 2.6, 2.7, or 3.3+. By default, it requires root access in order to write to /etc/letsencrypt, /var/log/letsencrypt, /var/lib/letsencrypt; to bind to ports 80 and 443 (if you use the standalone plugin) and to read and modify webserver configurations (if you use the apache or nginx plugins)

Alternate Certbox installation methods

There are various ways of installing certbot such as by OS packages, docker and certbot auto. I’m going to describe installing certbot using Ubuntu 14.04 OS package on Apache 2.4.7.

Pre-requisites Before Running certbot client

You need to make sure that port 443 is accessible from both your local lan and externally from any internet connected device.

To test this, make apache listen to port 443 by editing the /etc/apache2/ports.conf and adding Listen 443 directive and then restarting apache.

Then from you LAN try and telnet to the server’s local ip on port 443. If this works then try and telnet to the server’s public ip from a device on another internet connection and telnet to the server’s public IP on port 443.

If you run the certbot client when port 443 is not open then you will get the following Timeout Error:


imela@example:~/https$ sudo certbot --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache

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

Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for logs.example.org
tls-sni-01 challenge for build.example.org
Enabled Apache socache_shmcb module
Enabled Apache ssl module
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. logs.example.org (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout, build.example.org (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout

IMPORTANT NOTES:
- The following errors were reported by the server:

Domain: logs.example.org
Type: connection
Detail: Timeout

Domain: build.example.org
Type: connection
Detail: Timeout

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
imela@example:~/https$

After making sure the service is reachable from your LAN and from the internet then remove the Listen 443 directive that you added to /etc/apache2/ports.conf and then restart apache. Otherwise you will get the following connection refused error when you run the certbot client:


urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Connection refused

Domain: logs.example.org
Type: connection
Detail: Connection refused

Domain: hub.example.org
Type: connection
Detail: Connection refused

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.

Installing Certbot Client

  • Go to the certbot url and choose the type of webserver and version of Operating system that you are using.
  • In this example, I’m using Apache on Ubuntu 14.04 (trusty) so my instructions will be as shown on this url and highlighted below:

$ sudo apt-get update

$ sudo apt-get install software-properties-common
Reading package lists... Done
Building dependency tree
Reading state information... Done
software-properties-common is already the newest version.
imela@example:~/https$ sudo add-apt-repository ppa:certbot/certbot
This is the PPA for packages prepared by Debian Let's Encrypt Team and backported for Ubuntu(s).
More info: https://launchpad.net/~certbot/+archive/ubuntu/certbot
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmpxt2ru4vb/secring.gpg' created
gpg: keyring `/tmp/tmpxt2ru4vb/pubring.gpg' created
gpg: requesting key 75BCA694 from hkp server keyserver.ubuntu.com
gpg: /tmp/tmpxt2ru4vb/trustdb.gpg: trustdb created
gpg: key 75BCA694: public key "Launchpad PPA for certbot" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
OK
imela@example:~/https$

imela@example:~/https$ sudo apt-get install python-certbot-apache
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
certbot python-acme python-asn1crypto python-augeas python-certbot
python-certifi python-cffi-backend python-chardet python-configargparse
python-configobj python-cryptography python-dialog python-dnspython
python-enum34 python-idna python-ipaddress python-ndg-httpsclient
python-openssl python-parsedatetime python-pkg-resources python-psutil
python-pyasn1 python-pyicu python-requests python-rfc3339 python-setuptools
python-six python-urllib3 python-zope.component python-zope.event
python-zope.hookable
Suggested packages:
python-certbot-doc python-acme-doc python-certbot-apache-doc
python-cryptography-doc python-cryptography-vectors python-enum34-doc
python-openssl-doc python-openssl-dbg python-psutil-doc python-socks
python-setuptools-doc python-ntlm
The following NEW packages will be installed:
certbot python-acme python-asn1crypto python-augeas python-certbot
python-certbot-apache python-certifi python-cffi-backend
python-configargparse python-configobj python-cryptography python-dialog
python-dnspython python-enum34 python-idna python-ipaddress
python-ndg-httpsclient python-parsedatetime python-pyasn1 python-pyicu
python-rfc3339 python-zope.component python-zope.event python-zope.hookable
The following packages will be upgraded:
python-chardet python-openssl python-pkg-resources python-psutil
python-requests python-setuptools python-six python-urllib3
8 upgraded, 24 newly installed, 0 to remove and 11 not upgraded.
Need to get 2,503 kB of archives.
After this operation, 11.2 MB of additional disk space will be used.
Do you want to continue? [Y/n]

Once installed you are now ready to run the certbot client

Running the Certbot Client to Validate and Install the HTTPS Certificate

The client will require root privileges to make changes to the virtualhost file in /etc/apache2/sites-available or enabled as well as enabling SSL on Apache. The client will also create the following directories where it will install the certificate and key:

–work-dir is etc/letsencrypt, –logs-dir is  /var/log/letsencrypt, and –config-dir is /var/lib/letsencrypt

Running the certbot client:


imela@whiscardz:$ sudo certbot --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache

Which names would you like to activate HTTPS for?
-------------------------------------------------------------------------------
1: logs.example.org
2: build.example.org
-------------------------------------------------------------------------------
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for logs.example.org
tls-sni-01 challenge for build.example.org
Enabled Apache socache_shmcb module
Enabled Apache ssl module
Waiting for verification...
Cleaning up challenges
Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf
Enabled Apache socache_shmcb module
Enabled Apache ssl module
Deploying Certificate for logs.example.org to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf
Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf
Deploying Certificate for build.example.org to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf
Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf

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.
-------------------------------------------------------------------------------

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
Redirecting vhost in /etc/apache2/sites-enabled/000-default.conf to ssl vhost in /etc/apache2/sites-available/000-default-le-ssl.conf
Redirecting vhost in /etc/apache2/sites-enabled/000-default.conf to ssl vhost in /etc/apache2/sites-available/000-default-le-ssl.conf

-------------------------------------------------------------------------------
Congratulations! You have successfully enabled https://logs.example.org,
https://build.example.org

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=logs.example.org
https://www.ssllabs.com/ssltest/analyze.html?d=build.example.org

-------------------------------------------------------------------------------

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/build.example.org/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/build.example.org/privkey.pem
Your cert will expire on 2019-05-06. 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"
- 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

imela@whiscardz:$

NOTES

If everything went well then you should be able to go to the subdomain on http and you will be redirected to https.

Incase you dont want to enable http to https redirect then you can choose option 1 and then later edit the virtual host file after testing that your site works ok on https.

Add the following on the lines in bold below on your sites-available http virtualhost file:


<VirtualHost *:80>
ServerName logs.example.org
ProxyPass / http://localhost:9998/
ProxyPassReverse / http://localhost:9998/
ProxyPassReverseCookieDomain localhost logs.example.org
ProxyPreserveHost On
<strong>RewriteEngine on</strong>
<strong>RewriteCond %{SERVER_NAME} =logs.example.org</strong>
<strong>RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]</strong>
</VirtualHost>

The certbot client creates another virtual host file in sites-available for the ssl stuff. Here’s an example of a SSL virtual host:


<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName logs.example.org
ProxyPass / http://localhost:9996/
ProxyPassReverse / http://localhost:9996/
ProxyPassReverseCookieDomain localhost logs.example.org
ProxyPreserveHost On
SSLCertificateFile /etc/letsencrypt/live/build.example.org/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/build.example.org/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/build.example.org/chain.pem
</VirtualHost>
</IfModule>
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName build.example.org
ProxyPass / http://localhost:9998/
ProxyPassReverse / http://localhost:9998/
ProxyPassReverseCookieDomain localhost build.example.org
ProxyPreserveHost On
SSLCertificateFile /etc/letsencrypt/live/build.example.org/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/build.example.org/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateChainFile /etc/letsencrypt/live/build.example.org/chain.pem
</VirtualHost>

The certbot client by default creates one ssl certificate for all your subdomains. If you want each subdomain to have it’s own ssl certificate and key then run the certbot client multiple times each time choosing only 1 sub-domain.

The certificates and keys are located in /etc /etc/letsencrypt/live/$domain and during renewal this is the directory that is updated.

To view a list of the certificates Certbot knows about, run the certificates subcommand:

certbot certificates

Changing a Certificate’s Domains

References

Let’s encrypt getting started

Rate Limits

About Certbot

System Requirements

Running with docker

Apache on Ubuntu 14.04 (trusty)

Where are my certificates?

Certbot Commands

Getting certificates (and choosing plugins)

Managing certificates

Changing a Certificate’s Domains

TLS with Server Name Indication (TLS SNI)

Frequently Asked Questions

Let’s encrypt configuration

Serve http (port 80) and https (port 443) on same VirtualHost

How add SSL/443 to Apache server without virtual host?

Configuring Apache2 to Auto redirect calls to port 80 to port 443

Set up Apache virtual hosts on Ubuntu

How to configure HTTPS on Apache 2

HTTPD – Apache2 Web Server

How To Configure the Apache Web Server on an Ubuntu or Debian VPS

Setting up an SSL server with Apache2

How To Create a SSL Certificate on Apache for Debian 8

TLS with Server Name Indication (TLS SNI)

Http-01: The server could not connect to the client to verify the domain

[solved] Changed Digital Ocean Droplet/IP address and Now Can’t Obtain Certificate

Error installing LetsEncrypt SSL: (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain

[Solved] (tls-sni-01): urn:acme:error:connection :: Failed to connect to host for DVSNI challenge

LetsEncrypt – “Can’t connect to the client for DV”

General Port Forwarding Guide

Failed authorization for renewal

Example VirtualHost Configurations

SSL with Virtual Hosts Using SNI

Apache VirtualHost Examples

Common Apache Misconfigurations

 

Add ssh key to gihub

First you need to generate your ssh key as described in this post.

Then add the public key to your github account in the settings page

Then test whether you can use ssh with your github account from your linux terminal:


imela@curtsey ~ $ ssh -T git@github.com
Warning: Permanently added the RSA host key for IP address '194.50.23.122' to the list of known hosts.
Hi whiscardz! You've successfully authenticated, but GitHub does not provide shell access.

References

Testing your SSH connection

Specify private SSH-key to use when executing shell command with or without Ruby?

Generate ssh keys

Problem

I needed to generate a generic ssh key that I could use on multiple machines as well as on web portals that support ssh keys

Solution

Generate a key that was tired to my email account:


$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

Enter a file in which to save the key (/home/you/.ssh/id_rsa): [Press enter]

Enter passphrase (empty for no passphrase): [Type a passphrase]
Enter same passphrase again: [Type passphrase again]

Adding your ssh key to your keyring:

Start the ssh-agent in the background and add your private key to the ssh agent. Incase you used a key with a different name other than id_rsa then edit accordingly:


$ eval "$(ssh-agent -s)"
Agent pid 59566

$ ssh-add ~/.ssh/id_rsa

References

Generating a new SSH key and adding it to the ssh-agent

How To Set Up SSH Keys

How to generate an SSH key pair in Linux?

Git on the Server – Generating Your SSH Public Key

Encrypt and Decrypt with gpg key

Here’s how to encrypt a document with the recipients public gpg key that you have imported into your keyring:


implementer@whiscardz ~ $ gpg --output test.gpg --encrypt --recipient email@gmail.com test

NOTE: In-case you get a warning whether or not to trust the user’s public key then have a look at this post on signing or trusting gpg keys.

You can also choose not to sign the keys and add the --trust-model always option to the encryption:


$ gpg --output test.gpg --encrypt --recipient email@gmail.com --trust-model always test

 

Decrypting

Here’s how to decrypt a document with the recipients public gpg key. Note you have to have the private key that was used to decrypt.

imela@curtsey ~ $ gpg --output test --decrypt test.gpg

References

Encrypting and decrypting documents

Encrypting and decrypting files with GnuPG

gpg encrypt file without keyboard interaction