Wprawdzie z certyfikatów Let’s Encrypt korzystam już od jakiegoś czasu, to cały czas zwlekałem z tym wpisem w oczekiwaniu na wyjście usługi z fazy otwartej bety, która wprawdzie cały czas trwa, ale wydaje mi się, że projekt dojrzał już na tyle, że śmiało można z niego korzystać również w środowisku produkcyjnym.

Dodatkowym argumentem przemawiającym za przygotowaniem i opublikowaniem tego wpisu jest fakt, że właśnie skończyłem wdrażanie na kolejnym serwerze, a więc przy tej okazji zaktualizowałem swoje notatki o najświeższe zmiany…

Bezpłatny certyfikat SSL Let’s Encrypt

Do niedawna, jeśli do jakiegoś „mniej komercyjnego projektu” potrzebowałem podpisanego certyfikatu SSL (nie starczał samodzielnie wygenerowany i/lub Universal SSL z CloudFlare) zazwyczaj korzystałem z bezpłatnych certyfikatów StartSSL.

Teraz w takich przypadkach częściej korzystam z certyfikatów Let’s Encrypt, które dzięki zautomatyzowaniu większości czynności związanych z generowaniem nowego certyfikatu (jak i odnawiania) można wdrożyć na serwerze/stronie szybko i wygodnie.

Bezpłatny, automatyczny, otwarty

Certyfikaty Let’s Encrypt nie dość, że są bezpłatne, to oczywiście są prawidłowo rozpoznawane przez większość współczesnych przeglądarek, zapewniając tym samym naszej stronie „zieloną kłódkę”.

Jeśli dodać do tego stale rosnącą liczbę partnerów wspierających projekt, to raczej można być spokojnym o jego przyszłość.

Instalacja Let’s Encrypt

Całą procedure standardowo będę opierał o system Debian/Raspbian (Linux), ale jest ona dość uniwersalna, mogą się zmienić tylko niektóre polecenia, w większości mniej istotne. W razie czego, na tej stronie znajdźcie pełną dokumentację projektu…

No to GIT

Na początek – jeśli nie macie w systemie – musimy zainstalować m.in. klienta usługi GIT (+ BC):

sudo apt-get -y install git bc

Gdy ten element za nami pobieramy najnowsze pliki projektu do naszego systemu:

sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt

Warto od razu utworzyć dowiązanie symboliczne, dzięki czemu późniejsze korzystanie z programu będzie sprawniejsze:

sudo ln -s /opt/letsencrypt/letsencrypt-auto /usr/local/bin/letsencrypt

Dzięki temu zamiast korzystać z komendy bazowej:

/opt/letsencrypt/letsencrypt-auto

możemy używać polecenia:

letsencrypt

Jeśli korzystacie z wersji testowych Debiana – Debian Stretch (Debian 9) lub Debian Sid (wieczna wersja testowa) to możecie zainstalować Let’s Encrypt bezpośrednio z repozytoriów:

sudo apt-get install letsencrypt

Lub:

sudo apt-get install letsencrypt python-letsencrypt-apache

Webroot

Z racji tego, że nie mam teraz pod ręką żadnego serwera z czystym webserwerem Apache2 (choć dla webserwera Nginx też jakiś plugin jest, choć nie testowałem – ponoć jest to bardzo wczesna wersja tego modułu), to będę opierał się na bardziej uniwersalnej metodzie – webroot, która zadziała niezależnie od posiadanego webserwera (m.in. Apache2, Nginx).

Nie bardzo tez interesuje mnie opcja z zatrzymywaniem pracy serwera na czas aktualizacji/generowania certyfikatów, by zamiast mojego webserwera mógł połączenie przychodzące odebrać serwer uruchomiony przez Let’s Encrypt na potrzeby weryfikacji domeny.

Musicie też mieć świadomość tego, że podczas generowania certyfikatu serwer usługi Let’s Encrypt będzie komunikował się z Waszym webserwerem, a więc każda domena dla której generujecie certyfikat musi być podpięta do serwera, oraz musi być dostępna z internetu.

Generowanie certyfikatu

Pierwsze uruchomienie to oprócz wygenerowania pierwszego certyfikatu również kilka dodatkowych operacji, które mają przygotować nasz system system (instalacja niezbędnych pakietów, aktualizacja systemu, itp.).

Jeśli korzystacie z webserwera Nginx, to zanim zaczniecie generować pierwszy certyfikat do plików konfiguracyjnych danej domeny musicie dodać poniższy fragment:

location ^~ /.well-known/ {
 allow all;
}

Gdy macie więcej domen, warto rozważyć wykorzystanie Nginx Snippets, dzięki czemu tego typu zmiany można przeprowadzać edytując tylko jeden plik.

Na koniec jeszcze:

sudo service nginx reload

Gdy przygotowania za nami możemy wygenerować certyfikat:

sudo letsencrypt certonly -a webroot -w /ścieżka/do/głównego/katalogu/strony/ -d domena

Np.:

sudo letsencrypt certonly -a webroot -w /var/www/webinsider/public_html/ -d webinsider.pl -d www.webinsider.pl
Więcej domen/subdomen

Niektórzy już być może zwrócili uwagę na to, że w przykładowym poleceniu użyłem dwukrotnie parametry „-d”, tym samym przypisując certyfikat od razu do 2 rożnych adresów:

  • Domena główna: webinsider.pl
  • Subdomena: www.webinsider.pl

Nic nie stoi na przeszkodzie, by takich domen/subdomen podać jeszcze więcej – chyba jest jakieś ograniczenie w granicach 100, czy coś koło tego:

sudo letsencrypt certonly -a webroot -w /ścieżka/do/głównego/katalogu/strony/ -d domena1 -d domena2 -d domena3 -d domena4 -d domena5

Z racji tego, że podczas generowania certyfikatu w katalogu „.well-known” są generowane pliki wykorzystywane do weryfikacji tego, czy faktycznie korzystamy z podanej domeny (domen), to w powyższym przykładzie wszystkie te domeny muszą wskazywać na jeden wspólny katalog na serwerze (/ścieżka/do/głównego/katalogu/strony/).

Ale i na to jest rada:

Jeden certyfikat wiele stron i katalogów głównych

Jeśli z jakichś przyczyn chcecie wygenerować jeden certyfikat dla kilku niezależnych stron, to można to zrobić powielając parametr „-w”:

sudo letsencrypt certonly -a webroot -w /ścieżka/do/głównego/katalogu/strony1/ -d domena1 -d domena2 -d domena3 -w /ścieżka/do/głównego/katalogu/strony2/ -d domena4 -d domena5

Choć ja osobiście preferuje niezależne certyfikaty dla poszczególnych domen/projektów/stron.

Lokalizacja certyfikatów

Wygenerowane certyfikaty (i ich kolejne wersje) znajdziecie w lokalizacji:

/etc/letsencrypt/archive/nazwa-domeny/

Ale z racji tego, że tam będą się pojawiać kolejne wersje certyfikatu z kolejną cyfrą w nazwie (odnowienia), to nie korzystamy z tej lokalizacji, by niepotrzebnie nie generować sobie dodatkowej roboty po każdej zmianie.

Miejscem które nas interesuje jest katalog:

/etc/letsencrypt/live/nazwa-domeny/

Gdzie znajdują się skróty (linki symboliczne) do aktualnych wersji certyfikatu:

  • cert.pem
  • chain.pem
  • fullchain.pem
  • privkey.pem

I to tej ścieżki i tych „plików” używamy w konfiguracji domen/stron (więcej o tym za chwilę).

Odnawianie certyfikatu

Aktualnie certyfikaty generowane przez Let’s Encrypt ważne tylko są 90 dni, ale na szczęście proces ich odnawiania jest aktualnie dość prosty i wygodny – a dzięki wspomnianemu linkowaniu nie wiąże się z koniecznością wprowadzania zmian w konfiguracji webserwera.

Datę ważności certyfikatu sprawdzicie za pomocą polecenia:

sudo openssl x509 -noout -in /etc/letsencrypt/live/webinsider.pl/fullchain.pem -dates

Ew.:

sudo openssl x509 -noout -in /etc/letsencrypt/live/webinsider.pl/cert.pem -dates

Przykładowy wynik:

notBefore=Mar 5 09:52:00 2016 GMT
notAfter=Jun 3 09:52:00 2016 GMT

Wygasające certyfikaty możecie odnowić globalnie – wszystkie które są ważne mniej niż 30 dni zostaną odnowione:

sudo letsencrypt renew

Można też odnowić wybrany certyfikat, korzystając z polecenia podobnego do tego za pomocą którego tworzyliśmy dany certyfikat, dodając parametr „–renew”:

sudo letsencrypt certonly -a webroot -w /ścieżka/do/głównego/katalogu/strony/ -d domena --renew

Np.:

sudo letsencrypt certonly -a webroot -w /var/www/webinsider/public_html/ -d webinsider.pl -d www.webinsider.pl --renew

Automatyzacja procesu odnawiania

Wprawdzie np. za pomocą kalendarza można zarządzać terminami, i odnawiać w odpowiednim momencie każdy certyfikat, to zdecydowanie wygodniej jest cały proces zautomatyzować.

Z pomocą przyjdzie nam CRON, czyli systemowy harmonogram zadań, w którym możemy dodać automatyczne odnawianie wszystkich certyfikatów, np. o 3 w nocy:

0 3 * * * root letsencrypt renew

Ew. wersja z powiadomieniem na e-mail o wynikach:

0 3 * * * root (sudo letsencrypt renew --rsa-key-size 4096 2>&1 | mail -s 'Letsencrypt @VPS21' [email protected])

Oczywiście w takim przypadku musicie w systemie mieć skonfigurowaną wysyłkę wiadomości e-mail, choćby za pomocą programu MSMTP.

Własny skrypt

Wprawdzie powyższe 2 przykłady dla większości z Was zapewne wyczerpują temat automatycznego odnawiania certyfikatów, to na niektórych serwerach – nawet teraz, gdy jest polecenie automatycznie odnawiające wszystkie certyfikaty – korzystam z prostego skryptu, który pozwala mi lepiej monitorować zmiany:

#!/bin/bash

CERT1="/etc/letsencrypt/live/domena1/fullchain.pem"
CERT2="/etc/letsencrypt/live/domena2/fullchain.pem"

CERT=( "$CERT1" "$CERT2" )

ILE_CERTYFIKATOW="2"

RENEW="0"

printf "\n----- ----- ----- ----- ----- ----- ----- -----\n\n"

x=0
while [ $x -lt $ILE_CERTYFIKATOW ] ; do

CERT_TEMP=${CERT[$x]}

if sudo openssl x509 -noout -in $CERT_TEMP -checkend 5184000
then
echo "Certyfikat OK: "$CERT_TEMP
else
echo "Certyfikat wygasa za mniej niż 30 dni, do odnowienia: "$CERT_TEMP
RENEW="1"

if [ ! $CERTYFIKAT ]
then
CERTYFIKAT="\n\n"$CERT_TEMP
else
CERTYFIKAT=$CERTYFIKAT"\n"$CERT_TEMP
fi

fi

printf "\n----- ----- ----- ----- ----- ----- ----- -----\n\n"


x=$[x + 1]
done

if [ "$RENEW" == "1" ]
then
LETSENCRYPT=$(sudo letsencrypt renew)
printf "$LETSENCRYPT"

printf "Odnowiono certyfikat(y): "$CERTYFIKAT"\n\n\n$LETSENCRYPT" | mail -s "Let's Encrypt: Odnowiono certyfikat(y) @VPS21" [email protected]

else
printf "Wszystkie certyfikaty OK\n\n"
fi

exit 

Ew. wersja alternatywna:

#!/bin/bash

CERT1="/etc/letsencrypt/live/domena1/fullchain.pem"
RENEW1="sudo letsencrypt certonly -a webroot -w /var/www/domena1/public_html/ -d domena1 -d www.domena1 --renew"

CERT2="/etc/letsencrypt/live/domena2/fullchain.pem"
RENEW2="sudo letsencrypt certonly -a webroot -w /var/www/domena2/public_html/ -d domena2 -d www.domena2 --renew"

ILE_CERTYFIKATOW="2"

CERT=( "$CERT1" "$CERT2" )
RENEW=( "$RENEW1" "$RENEW2" )

echo ""
echo "----- ----- ----- ----- ----- ----- ----- -----"
echo ""

x=0;
while [ $x -lt $ILE_CERTYFIKATOW ] ; do

CERT_TEMP=${CERT[$x]}
RENEW_TEMP=${RENEW[$x]}

# 5184000 - 30 dni
if sudo openssl x509 -noout -in $CERT_TEMP -checkend 5184000
then
echo "Certyfikat OK: "$CERT_TEMP
else
echo "Certyfikat wygasa za mniej niż 30 dni, odnawiam: "$CERT_TEMP
$RENEW_TEMP
echo "Odnowiono certyfikat: "$CERTYFIKAT | mail -s "Odnowiono certyfikat @VPS21" [email protected]
fi

echo ""
echo "----- ----- ----- ----- ----- ----- ----- -----"
echo ""

x=$[x + 1]
done

exit 0

Korzystam tu z opisanego jakiś czas temu mechanizmu pozwalającego uzyskać kod zakończenia testu w przypadku gdy certyfikat jest ważny krócej niż zdefiniowany okres (5184000 sekund to 30 dni):

if sudo openssl x509 -noout -in $CERT_TEMP -checkend 5184000

A całość również jest uruchamiana z CRONa:

0 3 * * * root /usr/local/bin/cron-letsencrypt >/dev/null 2>&1

Dodawanie certyfikatu do strony

Nie będę tutaj powielał wszystkich informacji związanych z konfigurowaniem domeny (vHosta) na potrzeby obsługi połączenia szyfrowanego (HTTPS), gdyż o tym już pisałem – w poradniku dotyczącym webserwera Apache2Nginx, i tam odsyłam w razie wątpliwości „co i jak”.

Poniżej podam tylko adresy plików zwianych z certyfikatem które należy wykorzystać do prawidłowego skonfigurowania strony.

Nginx:

ssl_certificate /etc/letsencrypt/live/DOMENA/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/DOMENA/privkey.pem;

Apache2:

SSLCertificateFile /etc/letsencrypt/live/DOMENA/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/DOMENA/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/DOMENA/chain.pem

Ograniczenia i limity (otwartej bety)

Oprócz tego, że certyfikaty ważne są 90 dni, to warto pamiętać jeszcze o kilku innych ograniczeniach, które przynajmniej teraz – w otwartej becie – obowiązują:

  • 10 żądań wystawienia certyfikatu z danego IP w ciągu 3 godzin
  • 5 certyfikatów na domenę (wliczając subdomeny) w ciągu 7 dni

Nie są to jakieś specjalnie duże ograniczenia, ale warto o nich pamiętać, zwłaszcza w trakcie testów – kiedyś, podczas testów zdarzyło mi się zablokować tworzenie nowych certyfikatów dla jednej, na szczęście testowej domeny.

Do testów warto też korzystać z parametru „–test-cert”, dzięki czemu tak tworzone certyfikaty nie wpływają na powyższe limity (choć oczywiście nie nadają się też do stosowania w środowisku produkcyjnym).

A co ze StartSSL?

Z darmowych certyfikatów StartSSL nadal zamierzam korzystać, choć ograniczyłem ich stosowanie do stron, w przypadku których nie mam możliwości korzystania z Let’s Encrypt, np. na hostingach współdzielonych, gdzie najczęściej nie ma możliwości instalacji dodatkowego oprogramowania, a często nawet dostępu do SSH.

W takich przypadkach nie dość, że znacznie utrudnione (o ile w ogóle możliwe, przynajmniej bez tymczasowego przepisania rekordów A w DNSach na VPSa) byłoby samo wygenerowanie certyfikatu z weryfikacją domeny, to zdecydowanie wygodniej aktualizować certyfikat raz na rok, niż co 2-3 miesiące.

Oczywiście są już hostingi na których została wdrożona bezpośrednia obsług certyfikatów Let’s Encrypt, i można je generować bezpośrednio z poziomu np. cPanelu czy DirectAdmin, ale przynajmniej na krajowym podwórku jest to nadal rzadkość (choć można śmiało założyć, że będzie to się szybko zmieniać, i w najbliższym czasie możemy chyba spodziewać się pojawienia się certyfikatów Let’s Encrypt u kolejnych dostawców hostingu).

Zgłoś błąd na stronie

Potrzebujesz profesjonalnej pomocy? Skontaktuj się z nami!

WebInsider poleca księgowość wFirma
WebInsider korzysta z VPSa w HitMe.pl
WebInsider poleca VPSy DigitalOcean
WebInsider poleca serwis Vindicat
Napisz komentarz
wipl_napisz-komentarz_01Jeśli informacje zawarte na tej stronie okazały się pomocne, możesz nam podziękować zostawiając poniżej swój komentarz.

W tej formie możesz również zadać dodatkowe pytania dotyczące wpisu, na które - w miarę możliwości - spróbujemy Ci odpowiedzieć.
Linki partnerskie
Niektóre z linków na tej stronie to tzw. "linki partnerskie", co oznacza, że jeśli klikniesz na link i dokonasz wymaganej akcji (np. zakup/rejestracja) możemy otrzymać za to prowizję. Pamiętaj, że polecamy tylko te produkty i usługi, z których sami korzystamy, i uważamy, że są tego na prawdę warte... :-)
Znaki towarowe i nazwy marek
W niektórych wpisach (oraz innych miejscach na stronie) mogą być przedstawione/użyte znaki towarowe i/lub nazwy marek, które stanowią własność intelektualną tych podmiotów, a zostały użyte wyłącznie w celach informacyjnych.

Potrzebujesz profesjonalnej pomocy? Skontaktuj się z nami!