Jak przenieść stronę na HTTPS bez błędów certyfikat SSL przekierowania i HSTS

HTTPS – po co w ogóle się w to bawić

HTTP vs HTTPS w praktyce, bez akademickich wykresów

HTTP to zwykła, nieszyfrowana komunikacja. Wszystko, co wysyła przeglądarka do serwera i odwrotnie, można po drodze podejrzeć, zmodyfikować lub przechwycić. HTTPS dodaje do tego warstwę szyfrowania TLS/SSL, która chroni dane przed podglądaniem i podrabianiem.

Technicznie różnica jest „tylko” w tym, że przeglądarka nawiązuje najpierw bezpieczne połączenie TLS (wymiana kluczy, negocjacja algorytmów), a dopiero na tym tunelu idzie zwykły HTTP. Dla użytkownika sprowadza się to do kłódki w pasku i braku ostrzeżeń o „niezabezpieczonej” stronie.

Trzy główne cechy HTTPS, które mają znaczenie w praktyce:

• Szyfrowanie – treść jest nieczytelna dla osób pośredniczących (np. Wi-Fi w kawiarni, operator, proxy w firmie).
• Integralność – dane po drodze nie mogą zostać „po cichu” podmienione, bo przeglądarka to wykryje.
• Uwierzytelnianie – certyfikat SSL/TLS jest dowodem, że łączysz się z właściwą domeną, a nie podstawionym serwerem.

Bez tego wszystkiego każdy formularz logowania, każde dane z karty, każde zapytanie do panelu klienta lecą „otwartym tekstem” lub są podatne na ataki typu man-in-the-middle.

Bezpieczeństwo użytkowników – gdzie HTTPS jest absolutnym mus

HTTPS jest krytyczny wszędzie tam, gdzie użytkownik cokolwiek wprowadza lub odczytuje dane przypisane do konta. Klasyczne przykłady:

• logowanie do panelu (CMS, panel klienta, konta użytkownika),
• formularze płatności (bramki, szybkie przelewy, karty),
• formularze z danymi osobowymi (RODO nie pyta, czy „to tylko newsletter”),
• panele administracyjne, narzędzia do zarządzania treścią, systemy helpdesk.

Połączenie po HTTP naraża te dane na przechwycenie. Wystarczy użytkownik w kawiarni, otwarte Wi‑Fi i prosty sniffer sieci. Jeśli hasła lecą bez szyfrowania, wszyscy przegrywają. Administrator – bo ma wycieki. Użytkownik – bo hasła często są recyklingowane w wielu serwisach. I tak domino leci dalej.

Dlatego dzielenie strony na „część bezpieczną” (panel/logowanie) i „resztę na HTTP” od dawna nie ma sensu. Migracja całej witryny na HTTPS to dziś standard, nie „opcja premium”.

HTTPS, SEO, Core Web Vitals i komunikaty przeglądarek

Google już dawno ogłosił HTTPS jako czynnik rankingowy. Nie jest to magiczny przycisk „+10 pozycji”, ale przy zbliżonej jakości treści zabezpieczona strona ma przewagę nad niezabezpieczoną. Do tego dochodzi kilka praktycznych aspektów:

• Komunikaty „Niezabezpieczona” / „Not secure” – Chrome, Firefox i inne przeglądarki bardzo wyraźnie oznaczają strony bez HTTPS, szczególnie te z formularzami.
• Formularze na HTTP – część przeglądarek wręcz blokuje wysyłanie danych lub wyświetla agresywne ostrzeżenia, co drastycznie obniża konwersję.
• Funkcje przeglądarki i API – wiele nowoczesnych funkcji (np. geolokalizacja, HTTP/2, część API PWA) wymaga HTTPS.

Core Web Vitals nie są bezpośrednio związane z HTTPS, ale bezpieczne połączenie pozwala korzystać z HTTP/2, lepiej integrować CDN, cache i inne mechanizmy, które wpływają na wydajność. Finalnie migracja na HTTPS (jeśli zrobiona rozsądnie) zwykle poprawia nie tylko bezpieczeństwo, ale i szybkość ładowania.

Zaufanie do marki i reakcje użytkowników na czerwone ostrzeżenia

Strona, która w pasku adresu ma czerwony komunikat o braku bezpieczeństwa, to prosty przepis na utratę zaufania. Użytkownik nie analizuje, czy to „tylko blog”, czy panel banku. Widzi ostrzeżenie, więc wychodzi. Szczególnie wrażliwe są:

• sklepy internetowe (porzucone koszyki tylko dlatego, że przeglądarka krzyczy),
• strony z wizerunkiem eksperckim (kancelarie, lekarze, finanse),
• produkty SaaS i panele klientów, gdzie bezpieczeństwo to element oferty.

W kontekście marki HTTPS jest jak porządne drzwi od mieszkania. Drzwi same w sobie nie sprzedają, ale jeśli ich nie ma, robi się bardzo nieprzyjemnie.

Kiedy migracja na HTTPS jest priorytetem, a kiedy można ją odłożyć

Są sytuacje, gdzie migracja powinna znaleźć się na samej górze listy zadań:

• sklep internetowy, nawet mały,
• serwisy z logowaniem i panelem użytkownika,
• strony, które zbierają dane osobowe, CV, dokumenty, skany,
• projekty marketingowe, gdzie płacisz za ruch z reklam – nie ma sensu wysyłać użytkowników na „niezabezpieczoną” stronę.

Można chwilowo odłożyć pełną migrację w sytuacji, gdy:

• przebudowujesz kompletnie architekturę serwisu i za chwilę i tak zmienisz URL-e,
• masz bardzo skomplikowane integracje legacy (stare systemy, kontrolery hardware), które wymagają testów,
• strona jest już „zamrożona” i planowana do wyłączenia.

Nawet wtedy sensowne jest przynajmniej zabezpieczenie panelu logowania i administracji, żeby hasła nie latały otwartym tekstem.

Rodzaje certyfikatów SSL/TLS – który wybrać i za ile

DV, OV, EV – co to jest i co realnie się zmienia

Certyfikat SSL/TLS musi być wydany przez urząd certyfikacji (CA). Różne typy różnią się tym, co ten urząd weryfikuje przed wystawieniem certyfikatu:

• DV (Domain Validation) – sprawdzana jest tylko kontrola nad domeną (np. plik na serwerze, rekord DNS, e‑mail). To najpopularniejszy i najtańszy typ.
• OV (Organization Validation) – oprócz domeny weryfikowana jest organizacja (firma, dane w rejestrach). Certyfikat zawiera nazwę firmy.
• EV (Extended Validation) – najbardziej rozbudowana weryfikacja, często obejmująca dokumenty firmowe, telefoniczne potwierdzenia, audyty.

Z perspektywy szyfrowania DV, OV i EV zapewniają ten sam poziom bezpieczeństwa protokołu. Różnica jest w zaufaniu do podmiotu i w tym, co jest pokazane odbiorcy (nazwa firmy w szczegółach certyfikatu, kiedyś także „zielony pasek”, który dziś praktycznie wygasł).

W praktyce dla większości serwisów (blogi, sklepy, SaaS) w zupełności wystarczy certyfikat DV. OV ma sens przy większych organizacjach i systemach B2B, gdzie polityka bezpieczeństwa lub audyty wymagają konkretnego typu. EV pozostaje głównie domeną banków, instytucji finansowych lub bardzo dużych marek, gdzie dział bezpieczeństwa ma swoje twarde regulacje.

Pojedynczy, wildcard, multi-domain – gdzie który zastosować

Poza poziomem weryfikacji, certyfikaty różnią się zakresem domen:

• Pojedynczy (single-domain) – zabezpiecza jedną pełną nazwę, np. example.com albo www.example.com. Często trzeba wybrać konkretną wersję.
• Wildcard – zabezpiecza domenę i wszystkie poddomeny pierwszego poziomu, np. *.example.com (czyli www.example.com, panel.example.com, api.example.com itp.).
• Multi-domain (SAN/UCC) – jeden certyfikat dla wielu niezależnych domen, np. example.com, example.net, inne-domena.pl.

Kilka typowych scenariuszy:

• Blog lub typowy firmowy one‑pager – wystarczy pojedynczy certyfikat DV dla wybranej wersji (z www lub bez).
• Sklep z kilkoma poddomenami (np. sklep.example.com, panel.example.com, api.example.com) – wildcard jest wygodny i zwykle tańszy niż kilka osobnych certyfikatów.
• Grupa serwisów na różnych domenach, ale tym samym infrastrukturze – multi-domain pozwala łatwiej ogarnąć certyfikaty, szczególnie na load balancerach.

Przesada z wildcardem „na wszelki wypadek” nie zawsze ma sens. Jeśli masz jedną stronę i żadnych planów na rozrastanie się w subdomeny, zwykły pojedynczy DV jest prostszy i tańszy.

Let’s Encrypt a certyfikaty komercyjne – co naprawdę się różni

Let’s Encrypt to bezpłatny urząd certyfikacji wydający wyłącznie certyfikaty DV. Jest obsługiwany przez większość hostingów, wiele paneli ma integrację „na klik”. Główne cechy:

• bezpłatny,
• ważność typowo 90 dni (automatyczne odświeżanie przez narzędzia typu Certbot),
• brak ręcznych formalności (pełna automatyzacja przez HTTP-01, DNS-01 itp.),
• powszechna akceptacja w przeglądarkach.

Certyfikaty komercyjne (płatne) mogą występować jako DV, OV lub EV, single, wildcard, multi-domain. Różnice względem Let’s Encrypt:

• często dłuższa ważność (rok),
• możliwość wsparcia technicznego od dostawcy,
• polisy ubezpieczeniowe, „gwarancje” – bardziej istotne dla korporacji niż dla typowego e‑commerce,
• obsługa specyficznych scenariuszy (np. wymagania compliance, wewnętrzne CA, integracje z appliance).

Dla większości małych i średnich serwisów Let’s Encrypt doskonale wystarcza. Komercyjny certyfikat ma sens, gdy:

• polityka bezpieczeństwa firmy go wymaga,
• potrzebne jest OV/EV,
• infrastruktura jest złożona i wygodniej mieć komercyjne wsparcie od jednego dostawcy.

Jak dobrać typ certyfikatu do serwisu – kryteria wyboru

Przy wyborze certyfikatu zadaj sobie kilka prostych pytań:

• Ile domen i subdomen chcesz zabezpieczyć teraz i w najbliższych 1–2 latach?
• Jaki jest poziom formalnych wymogów (RODO, audyty, wewnętrzne polityki bezpieczeństwa)?
• Jaki masz budżet i jak ważne jest wsparcie zewnętrznego dostawcy?
• Jak wygląda infrastruktura (pojedynczy hosting współdzielony vs własne serwery, load balancery, CDN)?

Prosty blog WordPress na hostingu współdzielonym: Let’s Encrypt DV, pojedynczy certyfikat. Rozbudowany sklep na kilku poddomenach: wildcard DV od Let’s Encrypt lub komercyjny (jeśli polityka firmy tego wymaga). System korporacyjny B2B, audyty bezpieczeństwa: OV lub EV, często z komercyjnego CA.

Kiedy nie przesadzać z EV, a kiedy jednak przemyśleć

EV (Extended Validation) bywa traktowany jak magiczny znaczek „najwyższe bezpieczeństwo”. To przesada. Szyfrowanie jest takie samo, jak w DV i OV. Uzyskana wartość to:

• formalna, pogłębiona weryfikacja tożsamości organizacji,
• spektakularne (dla audytora) wpisy w dokumentacji bezpieczeństwa,
• łatwiejsza argumentacja w działach compliance, szczególnie w finansach.

Nie warto inwestować w EV, jeśli:

• serwis nie działa w szczególnie regulowanej branży,
• publicznie nie sprzedajesz „bezpieczeństwa” jako kluczowego USP,
• budżet jest napięty, a są ważniejsze rzeczy do zrobienia (np. porządne kopie zapasowe).

Rozważyć EV można przy dużych projektach finansowych, platformach inwestycyjnych, poważnych systemach SaaS dla biznesu, gdzie każdy punkt w audycie bezpieczeństwa bywa na wagę złota.

Przygotowanie do migracji – inwentaryzacja i plan działań

Co faktycznie działa pod tą domeną – nie tylko „www”

Migracja strony na HTTPS bez niespodzianek zaczyna się od porządnej inwentaryzacji. Większość problemów bierze się z założenia, że „mamy tylko jedną stronę”. Potem nagle okazuje się, że są jeszcze:

• stare subdomeny (np. m.example.com, old.example.com, beta.example.com),
• panele klientów i partnerów (np. panel.example.com),
• panele administracyjne na oddzielnych hostach,
• aliasy domen (np. example.pl i example.com wskazujące na ten sam serwer).

Na początek spisz:

• główne domeny (np. .pl, .com, .eu),
• istniejące subdomeny, nawet jeśli wydają się „martwe”,

Pełna mapa zasobów – nie tylko strony HTML

HTTPS dotyczy nie tylko „strony głównej”. Szyfrowaniem obejmujesz wszystko, co wchodzi i wychodzi z Twojej domeny. Przyda się więc lista elementów, które faktycznie z niej korzystają:

• API i endpointy techniczne (np. /api/, /webhook/, /xmlrpc.php),
• aplikacje mobilne, które łączą się z Twoją domeną,
• skrypty JS i pliki CSS serwowane z tej samej domeny lub subdomen,
• obrazy, fonty, pliki wideo, kanały RSS, sitemap, pliki do pobrania,
• integracje zewnętrzne, które wywołują Twój adres (bramki płatności, hurtownie, CRM, marketing automation).

Najszybciej zbierzesz listę, łącząc kilka źródeł:

• logi serwera (ostatnie tygodnie/miesiące – dają realny obraz ruchu),
• Google Search Console / inne narzędzia SEO – pokażą podstrony widoczne dla wyszukiwarki,
• panel hostingu lub DNS – listę subdomen i aliasów,
• dokumentację integracji – jeśli istnieje, bo czasem żyje już tylko w głowach programistów.

Chodzi o to, żeby później nie odkrywać nagle, że „stary” adres HTTP jest gdzieś zahardkodowany w aplikacji mobilnej lub u partnera, który 5 lat temu dostał specyfikację w PDF.

Lista integracji i miejsc, gdzie adres strony jest zakodowany na sztywno

Drugi krok to polowanie na twardo wpisane adresy HTTP. Typowe miejsca, które lubią robić psikusy po migracji:

• skrypty i aplikacje frontowe (JS, SPA, PWA), gdzie adres API to np. http://api.example.com,
• konfiguracje w panelach usług zewnętrznych (płatności, newsletter, piksel Facebooka, Google Ads, systemy afiliacyjne),
• konfiguracje wtyczek (np. integracja z magazynem, ERP, CRM),
• joby CRON, skrypty importów/eksportów, roboty integracyjne,
• aplikacje desktopowe lub mobilne partnerów, do których wysłano kiedyś endpoint HTTP.

Dobrym trikiem jest szybki grep/pełnotekstowe wyszukiwanie po repozytorium lub plikach serwera dla fraz http://twojadomena i http://www.twojadomena. To nie rozwiąże wszystkiego, ale często ujawnia stare integracje, o których nikt już nie pamięta.

Priorytety migracji – co musi działać od razu, a co może chwilę poczekać

Nie wszystkie elementy strony są równie krytyczne. Kilka prostych pytań pomaga rozłożyć migrację na etapy:

• Co musi działać bezbłędnie od pierwszego dnia (logowanie, koszyk, płatności, panel klienta)?
• Co może mieć krótką przerwę w działaniu (stary landing na kampanię sprzed roku)?
• Co można po prostu wyłączyć przy okazji (zapomniana subdomena z testami)?

Na tej podstawie tworzysz małą tabelkę priorytetów „A/B/C” i pod nią ustawiasz kolejność testów. Dzięki temu unikniesz sytuacji, w której pół dnia walczysz z mało używaną galerią zdjęć, a w tym czasie klienci nie mogą zapłacić za zamówienie.

Okno migracji i plan cofnięcia zmian

HTTPS można wdrożyć „na żywo”, ale przy większych serwisach lepiej zaplanować okno zmian:

• termin poza szczytem ruchu (noc/wczesny poranek, inna strefa czasowa, jeśli działasz globalnie),
• obecność osoby technicznej, która rozumie serwer i aplikację,
• przygotowana możliwość szybkiego rollbacku (kopie plików, bazy, konfiguracji serwera i DNS).

Rollback nie oznacza paniki, tylko trzeźwe założenie, że zawsze może się trafić coś nieprzewidzianego: dziwna wtyczka, limit u dostawcy CDN, zapomniany firewall. Jeśli da się w 5 minut wrócić do stanu poprzedniego, ciśnienie zdecydowanie spada.

Checklist przedstartowy – co mieć gotowe przed kliknięciem „włącz HTTPS”

Dobrze zrobiona lista kontrolna oszczędza masę czasu. Przykładowy zestaw punktów przed migracją:

• zamówiony i wydany właściwy typ certyfikatu (z odpowiednim zakresem domen),
• potwierdzone narzędzie do odnowienia certyfikatu (auto‑renewal Let’s Encrypt, proces po stronie dostawcy),
• aktualne kopie zapasowe bazy i plików (sprawdzone, że da się je przywrócić),
• dostęp do panelu DNS i panelu hostingu/serwera,
• lista adresów do testów po migracji (kluczowe podstrony, procesy, panele),
• kontakt do dostawcy hostingu / administratora, na wypadek gdyby coś poszło bardzo nie tak.

Do tego dochodzi zwykłe „ogarnięcie zespołu”: informacja dla supportu, marketingu i sprzedaży, że będzie zmiana i przez chwilę coś może wyglądać inaczej (np. zaloguje ich ponownie, cache się wyczyści, statystyki w analityce lekko się poruszą).

Instalacja i konfiguracja certyfikatu SSL na serwerze

Hosting współdzielony – najprostszy scenariusz

Na zwykłym hostingu większość roboty robi panel administracyjny. Typowy przebieg wygląda tak:

1. W panelu wybierasz domenę lub subdomenę.
2. Aktywujesz SSL (często przyciskiem „Włącz SSL / Włącz Let’s Encrypt”).
3. Czekasz kilka minut, aż certyfikat się wygeneruje i zainstaluje.
4. Włączasz wymuszanie HTTPS w ustawieniach hostingu lub później w .htaccess / konfiguracji serwera.

Kluczowa rzecz: upewnij się, jakie dokładnie hosty obejmuje certyfikat. Jeśli masz zarówno example.com, jak i www.example.com, panel powinien wystawić certyfikat z oboma wpisami (SAN). Jeśli tego nie ma, jedna z wersji może później zgłaszać błąd zabezpieczeń.

Serwer VPS / dedykowany – ręczna instalacja certyfikatu

Na własnym serwerze musisz zająć się zarówno instalacją, jak i odnowieniami. Ogólny schemat jest podobny niezależnie od systemu:

• wygenerowanie klucza prywatnego i CSR (requestu certyfikatu),
• weryfikacja domeny w CA (plik na serwerze, rekord DNS, e‑mail),
• odbiór certyfikatu i ewentualnych certyfikatów pośrednich (CA bundle),
• konfiguracja serwera www (Apache, Nginx, LiteSpeed itp.).

Przykładowo dla Nginx konfiguracja vhosta może wyglądać tak (szkicowo):

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/certs/example_com.crt;
    ssl_certificate_key /etc/ssl/private/example_com.key;
    ssl_trusted_certificate /etc/ssl/certs/ca_bundle.crt;

    # reszta konfiguracji...
}

Przy Apache będzie to zmiana vhosta na port 443 i dodanie odpowiednich dyrektyw SSLEngine on, SSLCertificateFile, SSLCertificateKeyFile, SSLCertificateChainFile (w zależności od wersji).

Let’s Encrypt z automatyzacją (Certbot, acme.sh i spółka)

Przy Let’s Encrypt sens ma pełna automatyzacja. Popularne narzędzia:

• Certbot – oficjalny klient EFF, często dostępny w repozytoriach systemu,
• acme.sh – lekki skrypt shell, który działa praktycznie wszędzie,
• wbudowane integracje w panelach (cPanel, Plesk, DirectAdmin, autorskie panele dostawców).

Mechanizm jest prosty: tool łączy się z CA, potwierdza, że panujesz nad domeną (HTTP‑01, DNS‑01), generuje certyfikat, aktualizuje konfigurację serwera, ustawia CRON do odnowienia przed wygaśnięciem. Jeśli instalujesz ręcznie, pilnuj, aby odnowienie nie kończyło się tylko pobraniem nowego certyfikatu – konfiguracja serwera musi zostać przeładowana (systemctl reload nginx lub podobne).

Łańcuch zaufania – certyfikat główny, pośredni, root

Częstym źródłem dziwnych błędów są niepełne łańcuchy certyfikatów. Przeglądarki oczekują:

1. Twojego certyfikatu domenowego,
2. certyfikatu pośredniego (lub kilku),
3. root CA, które zwykle jest już w magazynie systemu/przeglądarki.

Jeśli zainstalujesz tylko certyfikat domenowy bez łańcucha pośredniego, część urządzeń zgłosi błąd lub ostrzeżenie. Dlatego większość dostawców daje bundle – pojedynczy plik z całym łańcuchem, który podajesz w konfiguracji serwera. Warto go użyć, zamiast kombinować samodzielnie.

Bezpieczne protokoły i szyfry – żeby było nie tylko „zielono”, ale też porządnie

Sam certyfikat nie gwarantuje sensownego poziomu bezpieczeństwa. Równie ważna jest konfiguracja protokołów i szyfrów. Minimalne zalecenia na dziś:

• wyłączone stare protokoły: SSLv3, TLS 1.0, TLS 1.1,
• włączone TLS 1.2 i TLS 1.3,
• lista szyfrów bez archaicznych algorytmów (np. bez RC4, 3DES).

Dobre punkty startowe to gotowe „best practices” z serwisów typu Mozilla SSL Configuration Generator. Po wdrożeniu warto odpalić test w SSL Labs i sprawdzić ocenę oraz ostrzeżenia. Nie chodzi o obsesyjne gonienie za „A+”, ale o wyłapanie ewidentnych dziur.

CDN, proxy i load balancery – SSL nie tylko na „ostatnim” serwerze

Jeśli używasz CDN (Cloudflare, Fastly, Akamai itd.) albo reverse proxy/load balancera, certyfikat musi być poprawnie skonfigurowany także tam. Kilka typowych scenariuszy:

• Full SSL – ruch między użytkownikiem a CDN jest szyfrowany, a między CDN a Twoim serwerem także używa HTTPS,
• Flexible SSL – szyfrowany jest tylko odcinek użytkownik → CDN, a dalej leci HTTP (lepiej tego unikać, bo dane po drodze nie są chronione),
• certyfikat na load balancerze, a dalej ruch wewnątrz sieci w HTTP – akceptowalne w sieci prywatnej, jeśli jest odpowiednio zabezpieczona.

Do tego dochodzi poprawne przekazywanie nagłówków typu X-Forwarded-Proto albo X-Forwarded-For, dzięki którym aplikacja wie, że użytkownik faktycznie łączy się przez HTTPS, mimo że ruch w ostatnim odcinku (np. LB → backend) może być HTTP.

Poprawne przekierowania z HTTP na HTTPS (bez pętli i chaosu)

Koncepcja: najpierw kanoniczna domena, potem HTTPS

Jeżeli dotąd strona działała na kilku wariantach (z www/bez www, kilka aliasów domen), migracja na HTTPS to dobry moment, żeby to uporządkować. Ustal jedną wersję kanoniczną, np.:

• https://www.example.com albo
• https://example.com.

Logika przekierowań powinna być możliwie prosta: każdy inny wariant (http://example.com, http://www.example.com, aliasy domen) → 301 na jedną, wybraną wersję HTTPS. Mniej kombinacji, mniejsza szansa na pętle.

Przekierowania w Apache (.htaccess) – najczęstsze wzorce

Na serwerach Apache zwykle korzysta się z .htaccess. Typowy przykład: wymuszenie HTTPS i jednej wersji domeny (załóżmy, że docelowo ma być https://example.com):

<IfModule mod_rewrite.c>
RewriteEngine On

# przekierowanie www → bez www + HTTPS
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www.example.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]
</IfModule>

Ta reguła jednocześnie:

• wymusza HTTPS, jeśli ktoś wejdzie po HTTP,
• zdejmuje www, jeśli ktoś wejdzie na www.example.com,
• zachowuje ścieżkę (/$1) i ewentualne parametry.

Jeśli chcesz odwrotnej sytuacji (docelowo https://www.example.com):

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} !^www.example.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]
</IfModule>

Przekierowania w Nginx – prostsze, ale w innym miejscu

W Nginx przekierowania ustawia się na poziomie bloków server. Dla wariantu docelowego https://example.com możesz użyć:

Najczęściej zadawane pytania (FAQ)

Dlaczego muszę przechodzić na HTTPS, skoro moja strona to tylko blog / wizytówka?

Bo przeglądarka nie rozróżnia „tylko bloga” od panelu banku – widzi po prostu stronę bez szyfrowania i oznacza ją jako niezabezpieczoną. Użytkownik widzi czerwone ostrzeżenie i często po prostu zamyka kartę, zamiast czytać treści czy wypełniać formularz kontaktowy.

HTTPS zabezpiecza każde hasło, każdy adres e‑mail i każde ciasteczko logowania, które „lecą” między przeglądarką a serwerem. Do tego jest lekkim, ale realnym sygnałem rankingowym w Google, wpływa na konwersję formularzy i pozwala korzystać z nowoczesnych funkcji przeglądarki (np. HTTP/2, część API PWA).

Czy przy przejściu na HTTPS tracę pozycje w Google?

Prawidłowo wykonana migracja na HTTPS nie powinna szkodzić SEO. Dla Google jest to zwykła zmiana adresów z HTTP na HTTPS, o ile zadbasz o techniczne podstawy: stałe przekierowania 301, aktualizację mapy strony, poprawne kanoniczne adresy i brak mieszanej zawartości (mixed content).

W praktyce po krótkim okresie „przemielania” indeksu pozycje zwykle wracają do normy, a często lekko się poprawiają dzięki plusowi za HTTPS i lepszej konwersji użytkowników, których przeglądarka już nie straszy komunikatem „Niezabezpieczona”.

Jaki certyfikat SSL wybrać: DV, OV czy EV?

Pod względem szyfrowania wszystkie typy (DV, OV, EV) zapewniają ten sam poziom bezpieczeństwa połączenia. Różnią się tym, jak mocno urząd certyfikacji sprawdza właściciela domeny – DV tylko potwierdza, że kontrolujesz domenę, OV i EV dodatkowo weryfikują firmę w rejestrach, dokumentach itp.

Dla 90% stron (blogi, strony firmowe, sklepy, SaaS) wystarcza DV, często w wersji darmowej (np. Let’s Encrypt). OV ma sens przy większych organizacjach, gdzie wymagają tego procedury bezpieczeństwa lub audyty. EV to zwykle domena banków i dużych instytucji finansowych, które muszą pokazać „papiery” bardzo skrupulatnym działom compliance.

Czym się różni certyfikat pojedynczy, wildcard i multi‑domain?

Certyfikat pojedynczy zabezpiecza jeden konkretny adres, np. tylko example.com albo tylko www.example.com. Wildcard obejmuje domenę i wszystkie jej poddomeny pierwszego poziomu, np. *.example.com (www.example.com, panel.example.com, api.example.com itd.). Certyfikat multi‑domain (SAN) pozwala w jednym certyfikacie połączyć kilka różnych domen, np. example.com, inna-domena.pl.

W praktyce: masz jedną zwykłą stronę – wybierz pojedynczy DV. Masz sklep, panel klienta i API na subdomenach – wildcard jest wygodniejszy. Utrzymujesz kilka serwisów na różnych domenach na tej samej infrastrukturze – rozważ multi‑domain, żeby nie żonglować kilkoma certyfikatami naraz.

Czy Let’s Encrypt jest bezpieczny i kiedy wystarczy darmowy certyfikat?

Let’s Encrypt jest tak samo bezpieczny jak płatne certyfikaty DV – szyfrowanie opiera się na tych samych standardach TLS. Różnica jest w modelu biznesowym (fundacja, nie komercyjny CA) i zakresie usług: brak dodatkowego supportu, gwarancji finansowych czy bardziej „wypasionych” typów weryfikacji.

Darmowy DV z Let’s Encrypt w zupełności wystarcza dla blogów, standardowych stron firmowych, większości sklepów oraz projektów SaaS. Płatne certyfikaty wchodzą w grę, gdy potrzebujesz OV/EV albo formalnie wymaganego CA z konkretną polisą ubezpieczeniową – typowe w większych korporacjach i sektorze finansowym.

Kiedy migracja na HTTPS jest naprawdę pilna, a kiedy można ją odłożyć?

Priorytetem są wszystkie serwisy, gdzie użytkownik się loguje, podaje dane osobowe lub płaci: sklepy internetowe, panele klienta, systemy helpdesk, formularze z danymi wrażliwymi (CV, skany dokumentów). Tam HTTP to proszenie się o kłopoty – od przechwyconych haseł po ostrzeżenia przeglądarek, które zabijają konwersję.

Możesz tymczasowo odłożyć pełną migrację, jeśli serwis i tak jest wygaszany albo za chwilę przechodzi totalny redesign z nową strukturą URL. Nawet wtedy dobrze jest choćby zabezpieczyć logowanie i panel administracyjny, żeby hasła nie latały po sieci „otwartym tekstem”.

Czy mogę mieć jednocześnie HTTP i HTTPS na stronie, np. tylko panel na HTTPS?

Technicznie można, ale w 2026 roku to już anachronizm. Taki miks generuje problemy z SEO, cookie, cache, integracjami i mieszanymi zasobami, a użytkownikom wysyła sprzeczny komunikat: część strony rzekomo „bezpieczna”, reszta – jak się uda.

Dużo sensowniej jest przenieść całą witrynę na HTTPS z jednym, spójnym schematem adresów i przekierowaniem 301 z HTTP na HTTPS. To upraszcza konfigurację, ułatwia analitykę i przede wszystkim usuwa z głowy pytanie „czy ten formularz przypadkiem nie leci po HTTP?”.

Kluczowe Wnioski

• HTTPS to nie „ładniejszy HTTP”, tylko szyfrowany tunel TLS, który chroni dane przed podglądaniem, podmianą po drodze i podszywaniem się pod serwer.
• Mieszanie „bezpiecznego” panelu na HTTPS z resztą strony na HTTP jest dziś bez sensu – cała witryna powinna działać po HTTPS, bo każde logowanie czy formularz na HTTP to proszenie się o wyciek.
• Brak HTTPS uderza w SEO, konwersję i nowe funkcje przeglądarki: strona dostaje etykietę „Niezabezpieczona”, część formularzy jest blokowana, a dostęp do nowoczesnych API bywa zamknięty.
• Komunikaty typu „Not secure” skutecznie odstraszają użytkowników – zwłaszcza w sklepach, usługach eksperckich i SaaS, gdzie wizerunek bezpieczeństwa jest równie ważny jak sama oferta.
• Migracja na HTTPS jest pilna dla sklepów, serwisów z logowaniem, stron zbierających dane osobowe oraz projektów z płatnym ruchem; odłożenie jej ma sens tylko przy dużych przebudowach lub systemach legacy.
• Nawet jeśli pełna migracja musi poczekać, zabezpieczenie przynajmniej logowania i panelu administracyjnego to absolutne minimum, żeby hasła nie fruwały po sieci „otwartym tekstem”.
• Typ certyfikatu (DV, OV, EV) nie zmienia siły szyfrowania – różni się poziomem weryfikacji właściciela domeny i tym, ile formalnego „papieru” stoi za nazwą w certyfikacie.