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…
Spis treści w artykule
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' adres@email)
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" adres@email
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" adres@email
fi
echo ""
echo "----- ----- ----- ----- ----- ----- ----- -----"
echo ""
x=$[x + 1]
done
exit 0
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 Apache2 i Nginx, 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).
- Home Assistant 2024.11, czyli „sekcje” domyślnym widokiem z opcją migracji, WebRTC oraz wirtualna kamera - 1970-01-01
- Black Friday w ZUS, czyli jest jeszcze kilka dni, by złożyć wniosek RWS i skorzystać z wakacji składkowych płacąc ZUS za grudzień 2024 - 1970-01-01
- Wakacje składkowe ZUS a zawieszenie działalności gospodarczej, czyli uważaj, bo być może nie będziesz mógł skorzystać (w 2024) - 1970-01-01
Co Ci daje ten skrypt bo nie rozumiem? Jeśli odpalisz go wysyłając wynik do >/dev/null 2>&1 to w zasadzie uzyskasz to samo ustawiając w cronie komendę renew, a wydaje mi się że w obu przypadkach można wynik działania wysłać do zwykłego logu zamiast do >/dev/null 2>&1
Czy mógł byś wyjaśnić różnicę między SSLCertificateChainFile (jak podałeś), a SSLCACertificateFile? Co tutek to się spotykam raz z tym, raz z tym, a konkretnego wyjaśnienia nigdzie nie widzę.
Zacznę od końca – nigdy się nad tym nie zastanawiałem, po prostu taką konfigurację stosowałem kiedyś w Apache2 (2.2), choć z tego co kojarzę – ale od dawna nie korzystam z Apache2 – to aktualnie (2.4+) chyba SSLCertificateFile zastępuje SSLCertificateChainFile (ale to tylko tak mi się kojarzy).
Co do własnego skryptu – w kontekście samego odnawiania certyfikatów nie daje zupełnie nic, po prostu dzięki niemu (korzystam z trochę bardziej rozbudowanej wersji niż podana jako przykład we wpisie) mam większą kontrolę na powiadomieniami/informacjami o każdorazowym odnowieniu certyfikatu/certyfikatów (powiedzmy, że ładniejsza/bardziej przejrzysta forma, niż standardowe zapisanie wyniku do treści wiadomości).
Dzięki za szybką odpowiedz, a czy sprawdzałeś w praktyce tą komendę: 0 3 * * * root letsencrypt renew
Próbowałem jej wynik zapisać w logu, log tworzy, ale niestety jest pusty – może powinno być bez „root” skoro ustawiam w tablicy crontab -e rota?
Pytam bo nie mam jak sprawdzić czy działa – odnowić będzie można dopiero za 2 mc, a nie chciał bym zapomnieć o tym i mieć nie miłą niespodziankę :-)
A nie prościej/lepiej skorzystać z CRONa systemowego:
Korzystałem z polecenia w takiej wersji:
Z tym, że tu wynik działania trafiał do mnie na e-mail.
A tak to korzystam ze swojego skryptu, który kolejno sprawdza certyfikaty, zapisuje te do odnowienia do zmiennej, i później taką informację wysyła mi na e-mail (przykład tego typu rozwiązania jest we wpisie).
Pamiętaj też, że po modyfikacjach w plikach związanych z CRONem musisz jeszcze go zrestartować (restart usługi w kontekście użytkownika, którego dotyczą zmiany, lub restart CRONa systemowego).
PS. Chyba wszystko o czym piszę sprawdzam w praktyce – podczas wykonywania jakiegoś bardziej złożonego zadania staram się robić notatki (zawsze), które później stanowią bazę dla wpisu. Dodatkowo – zwłaszcza jeśli między powstaniem notatek a wpisem jest większa/dłuższa przerwa – odświeżam informacje z notatek ponownie testując zapisane w nich informacje podczas przygotowywania wpisu (oczywiście jeśli mam taka możliwość, ew. podejrzewam, że cos mogło się zmienić).
A no widzisz, całkiem zapomniałem o tym systemowym /etc/crontab i własnie dlatego wolę tam nic nie ustawiać bo za pół roku znowu zapomnę że go mam :-D Wiesz jak to jest jak się hobbystycznie zarządza jednym serwerem czy dwoma tylko dla siebie – nie grzebię tam codziennie. Teraz mi się przypomniało po co ten „root” w Twojej komendzie :)
Ustawiłem w zwykłej tablicy roota crontab -e
26 14 * * * /opt/letsencrypt/letsencrypt-auto renew >> /sciezka/log
i wygląda na to że działa poprawnie :-)
Docelowo mam zamiar ustawić uruchamianie dwa razy w miesiącu bo codziennie czy co tydzień nie ma sensu – chyba że Twoim skryptem, który najpierw sprawdza, a dopiero odnawia. Ja bym go zmodyfikował żeby odnawiał np. 3 dni przed wygaśnięciem bo po co odnawiać certyfikat który jest ważny jeszcze miesiąc, ale to może kiedyś, na chwilę obecną nie czuję potrzeby używania skryptu jeśli jedna komenda załatwi sprawę i do tego będę mógł przejrzeć w logu co mi odnowiło, a co nie :-)
PS. Pamiętasz może czy apache po odnowieniu certyfikatu łyknie go od razu bez restartu? Czytałem dokładnie o dowiązaniach symbolicznych i przejrzałem wszystko w /etc/letsencrypt/ ale apache to apache więc wolę dopytać czy przypadkiem po podmiance (odnowieniu) certyfikatu nie jest potrzebny /etc/init.d/apache2 restart ?
Dzięki za pomoc :-)
Niestety nie pamiętam aż tak, by udzielić Ci jednoznacznej odpowiedzi, ale zakładam, że właśnie po to jest stosowane dowiązanie symboliczne, by nie trzeba było się tym faktem przejmować (z drugiej strony – krotki restart usługi/webserwera w nocy zapewne nikomu krzywdy nie zrobi ;-)).
Uruchamianie codziennie jest o tyle wygodne, że jakby w jakimś momencie serwer Let’s Encrypt nie działał, to masz jeszcze 30 podejść (między 60 a 90 dniem) by certyfikat został odnowiony. Dodatkowo, w sytuacji gdy będziesz miał więcej certyfikatów, jest prawdopodobne, że będą one miały różne terminy wygasania (chyba, że będzie je synchronizował przez wymuszenie odnowienia wszystkich certyfikatów).
No i takie sprawdzenie raczej nie wygeneruje żadnego istotnego obciążenia dla serwera, a masz właściwe 100% pewność (choć ja i tak stosuje skrypt z info na e-mail gdy będą odnowione certyfikaty + przypomnienie w kalendarzu, by odznaczyć dla danej strony odnowienie certyfikatu gdy otrzymam e-mail o tym).
Co do testów czy działa – sprawdź wyjście, np. na e-mail… Ew. sprawdź log pod kątem danych z CRONa:
Możesz też wrzuć polecenie do skryptu, a do CORNa dodać skrypt – dzięki temu będziesz mógł uruchomić proces ręcznie, i zobaczysz przy okazji w konsoli wynik działania.
Warto też dodać sobie do kalendarza (czy jakiejś listy zadań) przypomnienie – certyfiakty Let’s Encrypt aktualnie ważne są 90 dni, a polecenie odnawiania odnowi każdy, ktory jest ważny mniej niż 30 dni, a więc masz 30 dniowy bufor by się zorientować, że coś jest nie tak z całym procesem.
Zawsze też możesz wymusić odnowienie dodając parametr:
A jak korzystasz z Apache2 (z Nginx też, ale to ponoć mocno eksperymentalna funkcjonalność na razie) to możesz spróbować skorzystać z odpowiednich dla tego webserwera parametrów, dzięki czemu certyfikaty powinny odnawiać się automatycznie (nie testowałem, opieram się tylko i wyłącznie na dokumentacji projektu).
Witaj, wracam ciągle do Twojego poradnika :-) Super to wszystko działa, a i wpis crontaba wyżej wymieniony prze ze mnie sprawdza się świetnie. Mam tylko dwa problemy.
1. Jak usunąć certyfikat? Przeniosłem domenę na inny serwer i tam wygenerowalem nowy. Wystarczy usunąć pliki i dowiązania dla tej konkretnej domeny? A może jest jakaś magiczna komenda, która poinformuje program że ma już jej „tutaj” nie odnawiać?
2. Po przekierowanie z http na https przez 301 pojawia się problem z odnawianiem certyfikatu bo Len’s nie ma dostępu do swojego ukrytego katalogu. Masz na to jakaś radę? Myślę o jakimś wykluczeniu tego katalogu z przekierowania tylko że najbliższe wygasają mi za 2mc i nie bardzo jest jak sprawdzić :(
Witam.
Z tego co kojarzę, to chyba nie ma jakiegoś oddzielnego polecenia/komendy w Let’s Encrypt do kasowania certyfikatu (choć jest „revoke” do unieważniania i teoretycznie pewnie można tego użyć). Ale wydaje mi się, że wystarczy usunąć odpowiednie katalogi – powiązane z domeną – z katalogów:
Jeśli chodzi o przekierowanie 301 z HTTP na HTTPS/SSL to nie bardzo wiem w czym może być problem, bo u mnie większość domen (choćby Webinsider.pl) ma przekierowanie 301 z HTTP na HTTPS/SSL (Nginx) i nie ma problemów z odnawianiem certyfikatów (oczywiście pierwsze generowanie certyfikatu odbywa się po HTTP, po czym dopiero konfiguruje HTTPS/SSL).
Co do testów – zawsze możesz dodać jakąś „testową subdomenę” i na niej testowo (wy)generować certyfikaty testowe.
Doskonała instrukcja. Mam pytanie o katalog główny ze ściezka np. sudo letsencrypt certonly -a webroot -w /ścieżka/do/głównego/katalogu/strony/ -d domena –renew
do jakiego katalogu albo pliku to ma dokładnie prowadzić ?
Do głównego katalogu z plikami strony (tam, gdzie np. index.php czy index.html).
Dziękuje. Problem w tym, że przejąłem aplikację po kimś, która jest zrobiona w Ruby. I tam nie ma pliku index.html albo index.php ?
Dziękuję. Przejąłem aplikacje po kimś, która jest napisana w ruby. I tam nie ma plików index.html ani index.php ?
Ruby to nie moje klimaty, ale zakładam, że jakiś webserwer tam pewnie jest (np. Nginx czy Apache2), a więc są pliki konfiguracyjne vHostów (domen/stron) i w nich będą wskazane katalogi, które są wykorzystywane do serwowania plików (faktycznie istniejące, czy tylko „pozorne”).
Świetny poradnik, bardzo mi pomógł. Fajnie, że są takie osoby, które dzielą się swoją wiedzą. Ze wszystkich poradników odnośnie generowania certyfikatu tls/ssl ten okazał najlepszy, bo wszystko działa jak należy.