Komplet komend do szyfrowania dysków, plików i kluczy w Debianie — LUKS/cryptsetup dla całych partycji, GPG dla pojedynczych plików, oraz kroki, żeby sprawdzić, czy naprawdę działa.
Standard szyfrowania blokowego w Linuksie. Szyfruje całą partycję — najlepsze rozwiązanie dla dysków systemowych, zewnętrznych nośników i backupów.
Pakiet cryptsetup obsługuje standard LUKS.
sudo apt update && sudo apt install cryptsetup -y
Nadpisuje dane na /dev/sdX1 — rób to tylko na pustej partycji.
sudo cryptsetup luksFormat /dev/sdX1
Tworzy zmapowane urządzenie pod /dev/mapper/.
sudo cryptsetup luksOpen /dev/sdX1 sejf
Po otwarciu wolumenu zakładasz na nim zwykły system plików.
sudo mkfs.ext4 /dev/mapper/sejf sudo mount /dev/mapper/sejf /mnt/sejf
Zawsze zamykaj wolumen po odłączeniu nośnika.
sudo umount /mnt/sejf sudo cryptsetup luksClose sejf
LUKS wspiera do 8 slotów kluczy — warto mieć zapasowy.
sudo cryptsetup luksAddKey /dev/sdX1
Gdy nie potrzebujesz szyfrować całego dysku — GPG szyfruje pojedyncze pliki, symetrycznie (hasłem) albo asymetrycznie (kluczem publicznym).
Najprostsza metoda — plik chroniony jednym hasłem.
gpg -c dokument.pdf # tworzy dokument.pdf.gpg
Poprosi o hasło ustawione przy szyfrowaniu.
gpg -d dokument.pdf.gpg > dokument.pdf
Kreator poprowadzi Cię przez wybór typu i długości klucza.
gpg --full-generate-key
Do odszyfrowania będzie potrzebny klucz prywatny odbiorcy.
gpg -e -r odbiorca@przyklad.pl dokument.pdf
Podgląd wszystkich kluczy w Twoim pęku (keyring).
gpg --list-secret-keys --keyid-format LONG
Zapisz w bezpiecznym miejscu, offline — to jedyna kopia.
gpg --export-secret-keys -a TWOJ_ID > backup-klucza.asc
Wygeneruj od razu po utworzeniu klucza — pozwala go unieważnić, jeśli zgubisz klucz prywatny.
gpg --gen-revoke TWOJ_ID > cert-uniewaznienia.asc
Bez tego zaszyfrujesz plik dla kogoś innego i sam go już nie odczytasz.
gpg -e -r odbiorca@przyklad.pl -r twoj@email.pl dokument.pdf
Klucz prywatny sam w sobie powinien być zaszyfrowany hasłem (passphrase) — na wypadek, gdyby ktoś dostał się do Twojego dysku.
Nowoczesny, szybki i bezpieczny algorytm — zalecany domyślnie.
ssh-keygen -t ed25519 -C 'twoj@email.pl'
Dodaje lub zmienia hasło chroniące istniejący klucz prywatny.
ssh-keygen -p -f ~/.ssh/id_ed25519
Wpisujesz hasło raz na sesję, zamiast przy każdym połączeniu.
eval $(ssh-agent -s) ssh-add ~/.ssh/id_ed25519
Jeśli nie chcesz szyfrować całego dysku, możesz zaszyfrować tylko wybrany katalog domowy przy pomocy eCryptfs — bez ponownej instalacji systemu.
Pakiet potrzebny do obsługi zaszyfrowanego katalogu.
sudo apt install ecryptfs-utils -y
Najczystszy sposób — od razu przy zakładaniu konta.
sudo adduser --encrypt-home nowyuser
Migruje wybrane dane istniejącego użytkownika do sejfu eCryptfs.
ecryptfs-setup-private
Zrób kopię zapasową danych poza szyfrowanym nośnikiem. Zgubione hasło lub uszkodzony nagłówek LUKS (LUKS header) oznacza dane nie do odzyskania — nie ma "resetu hasła" w kryptografii. Backup nagłówka: cryptsetup luksHeaderBackup /dev/sdX1 --header-backup-file naglowek.img.
Zaszyfrowany dysk główny nic nie da, jeśli swap albo kasowane pliki zostawiają dane w czystej postaci gdzie indziej.
Losowy klucz generowany przy każdym starcie — swap i tak jest tylko tymczasowy.
swap /dev/sdX2 /dev/urandom swap,cipher=aes-xts-plain64,size=256
Keyfile w initramfs pozwala pominąć ręczne hasło — ale tylko jeśli dysk z keyfile też jest bezpieczny.
sudo dd if=/dev/urandom of=/root/klucz.key bs=512 count=4 sudo cryptsetup luksAddKey /dev/sdX1 /root/klucz.key echo 'sejf /dev/sdX1 /root/klucz.key luks' | sudo tee -a /etc/crypttab
rm tylko odpina wskaźnik — dane fizycznie zostają na dysku, dopóki nie zostaną nadpisane.
shred -u -z -n 3 plik-tajny.txt
shred to za małoNa SSD, przez wear-levelling kontrolera, shred nie gwarantuje nadpisania fizycznych komórek. Dla SSD lepszym rozwiązaniem jest blkdiscard (TRIM całego urządzenia) albo szyfrowanie od początku — wtedy usunięcie klucza LUKS wystarcza, żeby dane stały się nieczytelne.
Krótka checklista, żeby upewnić się, że szyfrowanie faktycznie jest aktywne, zanim zaufasz mu ważne dane.
Potwierdza, że partycja rzeczywiście jest LUKS, a nie zwykłym systemem plików.
Pokazuje, które zaszyfrowane wolumeny są aktualnie odblokowane.
Wypisuje szczegóły: algorytm, tryb szyfru, rozmiar klucza.
Upewnij się, że plik faktycznie jest zaszyfrowany, a nie tylko przemianowany.
sudo cryptsetup isLuks /dev/sdX1 && echo 'To jest LUKS' # mapowanie /dev/sdX1 na TYPE="crypto_LUKS" lsblk -f sudo cryptsetup status sejf # cipher: aes-xts-plain64, keysize: 512 bits file dokument.pdf.gpg dokument.pdf.gpg: PGP RSA encrypted session key
Certbot pobierze certyfikat SSL tylko wtedy, gdy domena naprawdę wskazuje na Twój serwer. Bez poprawnego DNS-u każda próba certbot --apache skończy się błędem.
Domena = nazwa domu DNS = tablica adresowa IP serwera = dokładny adres domu twojadomena.pl --> 123.123.123.123 # ktoś wpisuje https://twojadomena.pl # DNS mówi: "idź na serwer 123.123.123.123"
Wchodzisz tam, gdzie kupiłeś domenę: OVH, home.pl, cyber_Folks, Cloudflare, Namecheap, GoDaddy — szukasz zakładki „DNS” / „Strefa DNS”.
Nazwa @, wartość = IP Twojego serwera, np. 185.50.20.10.
Nazwa www, ta sama wartość IP — inaczej zadziała tylko wersja bez www.
Propagacja DNS to od kilku minut do kilku godzin, zanim zmiana dotrze wszędzie.
Typ Nazwa Wartość ──────────────────────────────── A @ 185.50.20.10 A www 185.50.20.10
Pokazuje, na jakie IP obecnie wskazuje domena.
nslookup twojadomena.pl
Bardziej szczegółowy odpowiednik nslookup.
dig twojadomena.pl
Jeśli odpowiedź pokazuje IP Twojego serwera — DNS działa poprawnie.
ping twojadomena.pl
Certbot pyta DNS, sprawdza odpowiedź serwera i dopiero potem wydaje certyfikat.
sudo certbot --apache
Stare IP — rekord A @ wskazuje na inny adres niż aktualny serwer.
Brak rekordu www — domena główna działa, ale www.twojadomena.pl już nie.
Zamknięty port 80 — Certbot musi dostać się przez http://twojadomena.pl/.well-known/acme-challenge/, więc port 80 musi być otwarty.
DNS wskazuje na serwer, ale to Apache decyduje, którą stronę pokazać dla danej domeny. Bez poprawnego VirtualHost, Certbot nie znajdzie czego szukać — a strona i tak się nie wyświetli.
Tworzysz plik konfiguracyjny dla domeny w katalogu sites-available.
sudo nano /etc/apache2/sites-available/twojadomena.pl.conf
ServerName i ServerAlias to właśnie te domeny, które Certbot później zapyta.
<VirtualHost *:80> ServerName twojadomena.pl ServerAlias www.twojadomena.pl DocumentRoot /var/www/twojadomena.pl ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>
a2ensite tworzy dowiązanie symboliczne do sites-enabled.
sudo a2ensite twojadomena.pl.conf sudo apache2ctl configtest sudo systemctl reload apache2
Certbot łączy się przez port 80, a docelowa strona przez 443 (HTTPS).
sudo ufw allow 'Apache Full' sudo ufw status
Dla subdomen (np. sklep.twojadomena.pl) zwykle wygodniej wskazać na domenę główną niż dublować adres IP.
CNAME sklep twojadomena.pl.
Lokalny dig może pokazywać cache — warto zerknąć też z innego miejsca na świecie.
whatsmydns.net # wpisujesz domenę, patrzysz na wynik z wielu krajów
Certbot poprawnie zadziała tylko w tej kolejności: 1) DNS wskazuje na serwer → 2) VirtualHost istnieje i jest włączony (a2ensite) → 3) port 80 jest otwarty w firewallu → 4) dopiero certbot --apache. Pominięcie któregokolwiek kroku kończy się błędem walidacji domeny.
Sam certyfikat SSL to nie koniec pracy. Warto sprawdzić, czy się odnawia sam, czy ruch faktycznie przechodzi na HTTPS, i czy konfiguracja jest bezpieczna, a nie tylko "zielona kłódka".
Pokazuje domenę, ścieżki do plików i datę ważności.
sudo certbot certificates
Let's Encrypt wydaje certyfikaty tylko na 90 dni — bez auto-odnawiania strona wygaśnie.
sudo certbot renew --dry-run Congratulations, all renewals succeeded
Certbot instaluje to zwykle sam jako systemd timer — warto tylko potwierdzić, że jest aktywny.
systemctl list-timers | grep certbot
Certbot zwykle pyta o to sam podczas instalacji — tak wygląda ręczne wymuszenie w VirtualHost.
<VirtualHost *:80> ServerName twojadomena.pl Redirect permanent / https://twojadomena.pl/ </VirtualHost>
Certbot zwykle włącza to automatycznie, ale warto zweryfikować po ręcznych zmianach.
sudo a2enmod ssl sudo systemctl restart apache2
Zielona kłódka nie znaczy "bezpiecznie" — słabe szyfry i stare protokoły też ją pokazują.
ssllabs.com/ssltest # pełna ocena konfiguracji A–F
Najczęstsza przyczyna: coś innego zajęło port 80 w momencie odnawiania (np. inny serwer WWW albo firewall zablokował ruch tymczasowo), więc walidacja domeny się nie powiodła. Sprawdź logi: sudo cat /var/log/letsencrypt/letsencrypt.log — tam zobaczysz dokładny powód.
Port 80 odpowiada, ale Let's Encrypt dostaje 404 pod /.well-known/acme-challenge/. To prawie zawsze znaczy, że żądanie trafia do złego VirtualHosta albo jest przechwytywane przez reverse proxy — nie że domena czy DNS są błędne.
Apache wybiera vhost po ServerName/ServerAlias — gdy domena nie pasuje do żadnego, ląduje w pierwszym zdefiniowanym dla danego portu.
sudo apache2ctl -S
Symuluje żądanie tak, jakby przyszło na daną domenę — pokazuje, czy problem jest po stronie Apache czy DNS.
curl -i -H 'Host: example.pl' http://127.0.0.1/.well-known/acme-challenge/test.txt
Odseparowuje weryfikację ACME od aplikacji czy reverse proxy — dużo bardziej przewidywalne niż poleganie na DocumentRoot strony.
Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/ <Directory "/var/www/letsencrypt/.well-known/acme-challenge/"> Options None AllowOverride None Require all granted </Directory>
Bez tego cały ruch, także do challenge, trafia prosto do aplikacji za proxy — i ta odpowiada własnym 404.
ProxyPass /.well-known/acme-challenge/ ! ProxyPass / http://127.0.0.1:3000/ ProxyPassReverse / http://127.0.0.1:3000/
Certbot rozdziela uwierzytelnianie i instalację — webroot pozwala wskazać dokładnie ten sam katalog, który dopiero co przetestowałeś.
sudo certbot certonly --webroot -w /var/www/letsencrypt -d example.pl -d www.example.pl
Zanim w ogóle uruchomisz Certbota, upewnij się, że zwykły plik testowy jest publicznie widoczny.
echo 'acme-test' | sudo tee /var/www/letsencrypt/.well-known/acme-challenge/test.txt curl -i http://example.pl/.well-known/acme-challenge/test.txt HTTP/1.1 200 OK ... acme-test
Potwierdzenie widoczne przy pierwszym uruchomieniu Certbota dotyczy wyłącznie zgody na wiadomości od EFF — nie ma żadnego związku z błędem 404 czy weryfikacją domeny. Jeśli certyfikat się nie wydaje, przyczyny szukaj wyłącznie w konfiguracji VirtualHosta i dostępności /.well-known/acme-challenge/.
Let's Encrypt wystawia teraz certyfikaty bezpośrednio dla publicznych adresów IP, np. https://57.128.255.40. Haczyk: taki certyfikat jest ważny tylko 160 godzin (niecały tydzień), więc automatyczne odnawianie musi działać bez zarzutu.
Certyfikaty IP wymagają Certbota 5.4 lub nowszego — starsza wersja z apt tego nie obsłuży.
certbot --version
Nie instaluj równocześnie wersji z apt i ze snapa — usuń starą przed instalacją nowej.
sudo apt remove certbot python3-certbot-apache sudo apt install snapd sudo snap install core sudo snap install --classic certbot sudo ln -sf /snap/bin/certbot /usr/local/bin/certbot hash -r
Certyfikat testowy nie jest zaufany przez przeglądarkę — sprawdza tylko, czy cały proces przechodzi.
sudo certbot certonly --staging --preferred-profile shortlived --webroot --webroot-path /var/www/letsencrypt --ip-address 57.128.255.40
Dopiero po udanej próbie testowej — to samo polecenie, tym razem naprawdę wydaje certyfikat.
sudo certbot certonly --preferred-profile shortlived --webroot --webroot-path /var/www/letsencrypt --ip-address 57.128.255.40
Plugin --apache nie obsługuje jeszcze certyfikatów IP — trzeba podpiąć je ręcznie.
<VirtualHost *:443> ServerName 57.128.255.40 DocumentRoot /var/www/html SSLEngine on SSLCertificateFile /etc/letsencrypt/live/57.128.255.40/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/57.128.255.40/privkey.pem </VirtualHost>
Uruchamia się automatycznie tylko po udanym odnowieniu — konieczne przy 160-godzinnej ważności.
sudo mkdir -p /etc/letsencrypt/renewal-hooks/deploy # plik reload-apache.sh: systemctl reload apache2 sudo chmod 755 .../reload-apache.sh
Certyfikat na IP wymaga nowszego Certbota, ręcznej konfiguracji Apache i odnawiania co kilka dni zamiast co 60. Adres IP musi też pozostać stały — po jego zmianie certyfikat przestaje pasować. To dobre rozwiązanie tymczasowe albo gdy naprawdę nie masz domeny, ale zwykła (nawet darmowa) subdomena jest praktyczniejsza na dłuższą metę.
Jeśli ruch trafia najpierw na VPS z publicznym IP, a stamtąd przez sieć prywatną (np. Tailscale) na Twój serwer domowy — inna usługa (jak tailscaled) może już zajmować port 443 na adresie prywatnym. Sprawdź to poleceniem sudo ss -ltnp | grep ':443'. Najczyściej jest wtedy zakończyć TLS na samym VPS-ie i przekazywać dalej już zwykły ruch HTTP przez sieć prywatną, zamiast wymuszać Apache na współdzielenie portu 443 z inną usługą.
Cały poradnik do tej pory zakładał Apache. Jeśli jednak masz Nginx, albo zastanawiasz się, czy w ogóle Certbot to najlepszy wybór na Debianie 12 — to jest ta sekcja.
Identyczna logika co przy Apache — inny tylko plugin i flaga.
sudo apt update sudo apt install certbot python3-certbot-nginx sudo certbot --nginx -d example.pl -d www.example.pl
Cztery rzeczy, które muszą być prawdą niezależnie od tego, czy masz Apache czy Nginx.
✓ rekordy DNS A (i AAAA) wskazują na serwer ✓ porty 80 i 443 otwarte w firewallu ✓ domena już działa po zwykłym HTTP ✓ poprawny server_name / ServerName w konfiguracji
Debian 12 ma Certbota w repozytorium, ale to starsza gałąź 2.1.x. Certbot oficjalnie rekomenduje Snapa większości użytkowników.
APT → prostsze, "bardziej debianowe", wystarcza do zwykłego Nginx/Apache Snap → nowsza wersja, potrzebna np. do certyfikatów IP # nigdy nie instaluj obu równocześnie
Jeśli dopiero budujesz serwer od zera, Caddy sam pobiera i odnawia certyfikaty oraz przekierowuje HTTP → HTTPS, bez osobnego Certbota.
# Caddy: automatic HTTPS wbudowane w serwer # dobre gdy stawiasz nowy, prosty reverse proxy
Zwykłe certbot --nginx czy --apache nie wystarczy — wildcard wymaga weryfikacji DNS-01.
# wildcard = weryfikacja DNS-01 # potrzebny plugin API operatora DNS (np. certbot-dns-cloudflare)
Zamiast osobnego Certbota dla każdego kontenera, lepiej zintegrować HTTPS z jednym reverse proxy obsługującym ACME centralnie.
# jeden reverse proxy (np. Traefik, Caddy) z ACME # zamiast Certbota osobno w każdym kontenerze
Masz już działający Nginx albo Apache? Zostań przy Certbocie — jest rekomendowany przez samo Let's Encrypt. Stawiasz nowy, prosty serwer od zera? Rozważ Caddy. Masz wiele kontenerów? Zintegruj HTTPS z jednym reverse proxy zamiast mnożyć instancje Certbota.
Pełna rozmowa referencyjna (Certbot na Debianie 12): chatgpt.com/share/6a69df58-f284-83eb-a369-a782349a453b