HTTP to HTTPS
Fri 24 July 2020
Public key (Photo credit: Michael Drummond)
The goal was to migrate from HTTP to HTTPS
HTTPS overview
The HTTPS protocol rely on TLS (previously SSL) to ensure data integrity (data cannot be modified unnoticed), confidentiality (requested URL and content are only known by end points) and authentication (end points are the ones they claims to be).
TLS (ex-SSL)
TLS is a transport-layer protocol protocol. To ensure its services, cryptography is used. To do so, keys must be exchanged. I won't go into details into the shared cryptographic material (cryptographic algorithms, keys, handshakes). The most important thing is that cryptographic materials used to authenticate the server can be shared in a publicly available certificate [RFC8446 sec.4.4.2]. The most common type of certificate is known as X.509. The cryptographic material contained in the certificate (mostly the public keys and the associated cryptographic algorithm) are used to initiate the TLS connection (the handshake, described in [RFC8446 sec.4]).
X.509
X.509 certificate contains material used to authenticate an endpoint. To be valid, the certificate must be part of a certification path (as defined in [RFC5280 sec.3.2]). This imply either a certificate authority or a self-signed certificate.
The self-signed certificate is easy to setup but is not trusted by default by most verification tools. Thus, for a public server, a self-signed certificate is not suited.
DevOps corner
To migrate from HTTP to HTTPS, the following steps must be followed:
- create a X.509 certificate
- get your certificate signed by a certificate authority
- publish your newly signed certificate
- configure your web server to use it
- test your web server works
- check that links to your website are still working
- add a reminder in your calendar to update your certificate before it expires
Certbot is a tool that automated most of this steps. Let's encrypt is a non-profit certification authority. It provides certificates with an expiration date in 3 months [1]. Having to renew the certificate every 3 month is not painful as it can also be automated thanks to Certbot.
If running in interactive mode (as suggested by the documentation), Certbot asks for multiples question to modify the configuration. You can even keep 2 versions of your website: one secured with HTTPS and another one using classic HTTP.
Note that if you have multiple sites running on you server (using virtualhost), you can select which one will be migrated to HTTPS.
The first time you run Certbot, it will perform steps 1 to 4. Checking the certificate renew works by performing a dry run will add a line in a crontab, taking care of the step 7.
You still have to perform tests manually. For example, the pelican configuration include a global variable SITEURL that must be updated.
| [1] | Having short-live certificate is generally a good idea (you won't have to live with mistakes for long, if compromised, the certificate cannot be abusively used for long,...). Yet, everything in security is a compromise between high level of security and conviviality (otherwise it is not used as expected), and short live certificate require frequent renewals. |
Category: network security Tagged: Unix Debian tools how to network security
