Jak (w miarę) bezboleśnie udostępnić stronę przez połączenie szyfrowane HTTPS

Enigma

W ostatnim czasie nacisk na udostępnianie stron internetowych za pośrednictwem szyfrowanego protokołu HTTPS jest coraz większy. Oczywiście w przypadku witryn, na których użytkownicy wprowadzają swoje dane (loginy, hasła, dane osobowe), szyfrowanie to podstawa, ale coraz więcej „zwykłych” stron WWW również przechodzi na protokół HTTPS.

Ja również dałem się w to wciągnąć i od kilku dni WPzen jest dostępny tylko przez HTTPS. Niestety, natknąłem się przy tej okazji na chyba wszystkie możliwe problemy, o których opowiem w dalszej części wpisu.

Jakiś czas temu Google ogłosił, że strony korzystające z połączenia szyfrowanego HTTPS będą (w niewielkim stopniu, ale jednak) faworyzowane przez wyszukiwarkę – aczkolwiek ja bym tego nie traktował jako głównego argumentu za przejściem na HTTPS. Mozilla również wykonuje ruchy, które mają na celu zachęcenie właścicieli witryn internetowych do korzystania z szyfrowania. W kampanię informacyjną angażuje się coraz więcej dużych firm i organizacji zajmujących się ogólnie pojętym bezpieczeństwem w internecie – aczkolwiek część z nich ma w tym oczywiście swój interes.

Udostępnienie szyfrowanego połączenia z naszą stroną nie jest ani jakoś szczególnie skomplikowane, ani specjalnie drogie. Większość firm hostingowych już dawno wprowadziła w swoich panelach administracyjnych wygodne narzędzia do instalacji certyfikatów SSL, a koszt zakupu najtańszego certyfikatu jest niewiele wyższy od ceny dobrej kawy.

Co to jest certyfikat SSL?

Certyfikat SSL to specjalnie przygotowany zestaw informacji, który pozwala jednoznacznie stwierdzić, że serwer, z którym się łączymy, jest dokładnie tym serwerem, z którym chcemy się połączyć. Jednocześnie poświadcza on wiarygodność domeny, a także zapewnia bezpieczeństwo danych przesyłanych pomiędzy użytkownikiem (przeglądarką) a serwerem.

Certyfikaty SSL są wystawiane przez zaufane firmy, takie jak Comodo, Symantec, GeoTrust czy GlobalSign, które gwarantują ich autentyczność.

Można oczywiście używać szyfrowanego protokołu HTTPS bez posiadania certyfikatu (korzystamy z certyfikatu firmy hostingowej lub podpisujemy go sami), ale wtedy wchodząc na naszą stronę użytkownik zostanie poinformowany o niezaufanym certyfikacie.

Jaki certyfikat SSL wybrać?

Istnieje kilka rodzajów certyfikatów SSL. Do zabezpieczenia zwykłej strony internetowej wystarczy nam tak naprawdę najprostszy (i najtańszy) certyfikat Comodo PositiveSSL (lub analogiczny certyfikat innej firmy). Droższe opcje różnią się na przykład obsługą subdomen w ramach wybranej domeny, a najbardziej prestiżowe (EV – Extended Validation) wyświetlają tzw. „zielony pasek” w przeglądarce, w którym widnieje nazwa firmy będącej właścicielem domeny.

Jeśli chodzi o weryfikację danych właściciela domeny, to można wyróżnić trzy rodzaje certyfikatów SSL:

  • DV (Domain Validation) – weryfikacja elektroniczna, potwierdzająca własność domeny (plik przesyłany na serwer); takie certyfikaty są wydawane w ciągu kilku minut
  • OV (Organization Validation) – weryfikacja wymaga przesłania kopii dokumentów potwierdzających dane firmy, które są potem widoczne w informacjach o certyfikacie
  • EV (Extended Validation) – weryfikacja wymaga przesłania bardziej szczegółowych danych dotyczących firmy, a także kopii wymaganych dokumentów w języku angielskim; czasem weryfikacja wymaga bezpośredniego kontaktu z firmą wystawiającą certyfikat

Ja na potrzeby bloga WPzen wybrałem najtańszą opcję, czyli certyfikat Comodo PositiveSSL (DV).

Gdzie kupić certyfikat SSL?

Większość stron, na których możemy kupić certyfikat SSL, są tak naprawdę tylko pośrednikami pomiędzy kupującymi a wystawcami. Osobiście polecam poszukać najkorzystniejszych finansowo ofert, a następnie spośród nich wybrać firmę cieszącą się najlepszą reputacją.

Jeśli język angielski jest dla nas problemem, powinniśmy (mimo nieco wyższych cen) rozejrzeć się za jakąś rodzimą firmą, bo w razie ewentualnych problemów (na przykład takich, jak moje) trzeba będzie się jakoś dogadać z anglojęzycznym wsparciem. Warto też zerknąć do cennika firmy hostingowej, z której usług korzystamy, bo często w pakiecie znajduje się bezpłatna instalacja certyfikatu na serwerze obsługiwanym przez tę samą firmę.

Ja wybrałem ofertę SSLs.com, marki należącej do grupy Namecheap. Certyfikat Comodo PositiveSSL kosztuje tam $8,95 za rok (około 35 złotych), ale w opcji trzyletniej zapłacimy tylko $4,99 za rok (czyli niecałe 20 złotych).

W polskich sklepach ceny certyfikatów SSL są nieco wyższe. Dwie duże polskie firmy hostingowe oferują też własne certyfikaty, które można kupić w całkiem rozsądnej cenie. Nie wiem jednak nic na ich temat, więc nie będę nawet próbował porównywać ich z certyfikatami wystawianymi przez renomowane firmy.

Jak aktywować certyfikat SSL?

Po zakupie (a u niektórych sprzedawców w trakcie zakupu) certyfikatu SSL musimy go aktywować, czyli przypisać do naszej domeny. Zakładam, że wybraliśmy certyfikat DV, czyli nie musimy przesyłać nigdzie żadnych dokumentów.

Aby dokonać aktywacji musimy przesłać firmie, od której kupiliśmy certyfikat, CSR (Certificate Signing Request), czyli żądanie podpisania certyfikatu. Wygenerowanie CSR wymaga podania kilku informacji, takich jak nazwa domeny, kontaktowy adres e-mail, imię i nazwisko lub nazwa firmy, kraj czy miejscowość. CSR można wygenerować samemu za pomocą pakietu OpenSSL, ale większość firm hostingowych udostępnia taką funkcję w panelu administracyjnym serwera.

Razem z CSR generowany jest również klucz prywatny, którego nie wolno nam zgubić – bez niego nie zainstalujemy certyfikatu na serwerze.

Po przesłaniu CSR zostaniemy poproszeni o umieszczenie na naszym serwerze specjalnego pliku weryfikacyjnego, tak aby firma wystawiająca certyfikat mogła sprawdzić, czy naprawdę jesteśmy w posiadaniu zgłaszanej domeny (a przynajmniej czy jesteśmy w stanie nią zarządzać). Po zakończeniu weryfikacji otrzymujemy w wiadomości e-mail pliki z certyfikatem.

Jeśli kupujemy certyfikat w naszej firmie hostingowej, aktywacja może sprowadzać się do podania naszych danych – reszta będzie wykonana automatycznie.

Jak zainstalować certyfikat SSL na serwerze?

Jeśli zdecydowaliśmy się na zakup certyfikatu w firmie hostingowej obsługującej nasz serwer, może się okazać, że do naszej dyspozycji jest funkcja umożliwiająca instalację certyfikatu jednym kliknięciem. Jeśli jednak taka funkcja nie jest dostępna, będziemy musieli zainstalować certyfikat „ręcznie”.

Wprowadzamy certyfikat i klucz prywatny (czasem w jednym polu, czasem w osobnych polach) oraz CA Root Certificate, czyli certyfikat identyfikujący organizację wystawiającą nasz certyfikat. Nasz certyfikat i certyfikaty CA dostaliśmy po aktywacji (wystarczy skopiować i wkleić w odpowiednie pola zawartość otrzymanych plików), a klucz prywatny wygenerowaliśmy podczas tworzenia CSR.

W przypadku cetyfikatów Comodo pliki z certyfikatami CA są trzy i nazywają się `AddTrustExternalCARoot.crt`, `COMODORSAAddTrustCA.crt` i `COMODORSADomainValidationSecureServerCA.crt`.

Jeśli mamy problem z instalacją certyfikatu na serwerze, zawsze możemy poprosić o pomoc firmę hostingową. Warto też zajrzeć do dokumentacji – najczęściej znajduje się w niej szczegółowa instrukcja instalacji certyfikatów SSL.

Po zainstalowaniu certyfikatu możemy sprawdzić czy wszystko zostało zrobione poprawnie – wystarczy wpisać w przeglądarce adres naszej strony z prefiksem `https`, na przykład `https://nasza-domena.pl`. Jeśli nie zobaczymy informacji o niezaufanym certyfikacie, to znaczy, że certyfikat został poprawnie zainstalowany na naszym serwerze (nie oznacza to jednak, że strona jest już dostępna przez połączenie szyfrowane).

Jak „przełączyć” naszą stronę na szyfrowane połączenie HTTPS?

Po tym nieco przydługim wstępie możemy w końcu zająć się konfiguracją naszej strony, tak aby wszyscy odwiedzający przeglądali ją korzystając z szyfrowanego połączenia. Nie jest to skomplikowane i nie powinno zająć nam więcej niż godzinę (chyba że wystąpią problemy, o których w dalszej części wpisu).

Jeśli nie chcemy robić wszystkiego samodzielnie, to możemy skorzystać z darmowej wtyczki Really Simple SSL, która większość modyfikacji wykona za nas.

Przed przystąpieniem do dalszych kroków należy wykonać kopię bezpieczeństwa.

Zmiana adresu strony w ustawieniach WordPressa

Pierwszym krokiem jest zmiana adresu naszej strony w konfiguracji WordPressa. Możemy to zrobić w panelu administracyjnym w sekcji Ustawienia → Ogólne. Nowy adres wprowadzamy w polach Adres WordPressa (URL)Adres Witryny (URL). Po zapisaniu zmian zostaniemy wylogowani z panelu.

Jeśli zdecydowaliśmy się na użycie wtyczki Really Simple SSL, to zrobi to ona za nas.

Zmiana adresów URL w treści strony

Oczywiście we wpisach wciąż możemy mieć stare linki do naszej strony, a także (co ważniejsze) osadzone obrazki z adresami z prefiksem `http`, które będą powodować problemy z szyfrowaniem (wszystkie pliki na stronie muszą być pobierane również przez protokół HTTPS). W związku z tym musimy zamienić w bazie danych naszej strony wszystkie wystąpienia starej nazwy domeny na nową, z prefiksem `https`.

Ja zwykle robię to za pomocą tego skryptu, ale równie dobrze można skorzystać z wtyczki Better Search Replace. Wystarczy zamienić wszystkie wystąpienia ciągu `http://nasza-domena.pl` na `https://nasza-domena.pl`. Jeśli nasz serwis zawiera dużo treści, to operacja ta może chwilę potrwać.

Od tej chwili nasza strona powinna być dostępna bez problemów za pośrednictwem protokołu HTTPS – aby to sprawdzić wystarczy wpisać w przeglądarce jej adres poprzedzony `https` zamiast `http` (na przykład `https://nasza-domena.pl/`). Jeśli w pasku adresu przeglądarki zobaczymy informację, że strona nie jest szyfrowana, to najprawdopodobniej oznacza to, że jakieś pliki na naszej stronie są wciąż pobierane za pośrednictwem nieszyfrowanego protokołu HTTP (tzw. mixed content). Więcej na ten temat w części wpisu poświęconej najczęściej występującym problemom.

Przekierowanie użytkowników z http na https

Przez jakiś czas w wyszukiwarkach wciąż będą widniały linki do naszej strony z prefiksem `http`. Co więcej, na różnych stronach w Sieci na pewno znajdują się odnośniki do naszej witryny, z którymi nie jesteśmy w stanie nic zrobić. Warto więc przekierować wszystkich użytkowników wchodzących na naszą stronę na nowy adres z prefiksem `https`.

Aby to zrobić wystarczy do pliku `.htaccess` (najlepiej na samym jego początku) dodać następującą regułę:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Warto zauważyć, że jest to przekierowanie z kodem 301 (Moved Permanently), które mówi przeglądarce i robotom wyszukiwarek, że strona została na stałe przeniesiona pod wskazany adres.

Alternatywnie można skorzystać z wtyczki Really Simple SSL, która doda do naszej strony odpowiednie przekierowania.

Zmiana domyślnego adresu strony w Google Analytics

Google Analytics - domyślny URLJeśli korzystamy z Google Analytics, to nie musimy nic zmieniać w kodzie śledzącym. Warto natomiast w ustawieniach usługi (Administracja → Ustawienia usługi → Domyślny URL) zmienić domyślny adres naszej strony, a konkretnie jego prefiks.

Ponowne dodanie strony w Google Search Console

Niestety, narzędzie Google Search Console nie pozwala na zmianę adresu strony, tak więc musimy dodać naszą witrynę jeszcze raz, jako nową stronę. Trzeba pamiętać również o przesłaniu mapy strony, co powinno przyśpieszyć aktualizację adresów naszej witryny w indeksie Google.

Zmiana domeny w Disqus

Jeśli korzystamy z serwisu Disqus, to po zmianie adresu naszej strony wszystkie komentarze po prostu znikną. Dzieje się tak dlatego, że komentarze są przypisane do adresów URL wpisów, a te się zmieniły. Na szczęście Disqus udostępnia narzędzia, za pomocą których we w miarę wygodny sposób zmienimy adresy URL na nowe (z prefiksem `https`). Wystarczy wejść do panelu administracyjnego Disqus, przejść do zarządzania naszą stroną i na zakładce Community znaleźć opcję Migration Tools. Wbrew pozorom nie należy korzystać z Domain Migration Tool, ale z jednego z dwóch pozostałych narzędzi (URL Mapper lub Redirect Crawler).

I to właściwie wszystko, co musimy zrobić, aby nasza strona działała przez bezpieczne, szyfrowane połączenie HTTPS.

Możliwe problemy

W teorii wszystko to wygląda dość prosto, ale w praktyce różnie z tym bywa. Nie jestem oczywiście w stanie omówić wszystkich możliwych problemów, ale postaram się wspomnieć o tych najczęstszych oraz o tych, z którymi zetknąłem się podczas przełączania bloga WPzen na połączenie szyfrowane.

Mixed content

To chyba najczęściej występujący problem w witrynach udostępnianych przez połączenie szyfrowane. Występuje on gdy strona jest ładowana przez HTTPS, ale zawiera pliki (skrypty JavaScript, arkusze stylów CSS, obrazki itp.) ładowane przez HTTP. Problem ten objawia się różnie w zależności od używanej przeglądarki, ale w konsoli błędów zawsze znajdziemy infromację o zasobach, które są ładowane przez HTTP.

Problem z obrazkami znajdującymi się na naszym serwerze rozwiąże opisana wyżej zmiana adresów URL w treści wpisów. Jeśli chodzi o skrypty i arkusze stylów, to prawdopodobnie nasz motyw lub któraś z używanych przez nas wtyczek ładuje je w nieprawidłowy sposób. Najprostszym sposobem na rozwiązanie tego problemu jest skorzystanie z wtyczki Really Simple SSL, która automatycznie zamieni „w locie” `http` na `https`. Ten sposób nie zadziała jednak, gdy gdzieś w kodzie mamy „na sztywno” wprowadzone jakieś adresy URL – dotyczy to zarówno adresów prowadzących do naszej domeny, jak i do domen zewnętrznych.

Znikające polubienia (Like) z Facebooka

Facebook przypisuje polubienia do adresów URL, tak więc po zmianie adresu naszej strony znikną nam wszystkie „lajki”. Niestety, jedyne co jesteśmy w stanie z tym zrobić, to spróbować „oszukać” Facebooka zgodnie z oficjalną dokumentacją. Trick polega na przekazaniu w znaczniku `og:url` starego adresu URL. Jeśli do generowania znaczników OpenGraph korzystamy z wtyczki Yoast SEO, to wystarczy do pliku `functions.php` naszego motywu dodać taki kod:

function wpzen_og_url($url) {
	if(is_singular()) {
		global $post;
		if($post->post_date < '2016-02-10') {
			$url = str_replace('https://', 'http://', $url);
		}
	}
	return $url;
}
add_filter('wpseo_opengraph_url', 'wpzen_og_url');

Widoczną w czwartej linii datę należy zmienić na datę wprowadzenia połączenia szyfrowanego (czyli zmiany adresu URL naszej strony), tak aby tylko starsze wpisy miały stary adres w znaczniku `og:url`, a nowe używały już adresu z prefiksem `https`.

Teraz korzystając z debuggera możemy sprawdzić jak Facebook widzi naszą stronę. Wszystko wygląda w porządku, poza ostrzeżeniem o przekierowaniu na nowy adres. Dlatego też wyłączymy przekierowania na nowy adres dla bota Facebooka (ale tylko dla niego!). Aby to zrobić wystarczy zmodyfikować regułę, którą wcześniej dodaliśmy do pliku `.htaccess`, aby wyglądała tak:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{HTTP_USER_AGENT} !facebookexternalhit/[0-9]
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

I to wszystko – nasze „lajki” powinny wrócić. Oczywiście nowe polubienia będą już przypisywane do nowych adresów URL (z prefiksem `https`) – po to dodaliśmy warunek na datę wprowadzenia zmian. Warto pamiętać, że polubienia nie wrócą od razu – Facebook musi odświeżyć sobie swój własnych cache, w czym możemy mu pomóc sprawdzając poszczególne wpisy w debuggerze.

Opisywany problem nie dotyczy polubień strony na Facebooku (fanpage) – tam wszystko pozostanie bez zmian.

Problemy z aktywacją certyfikatu

W moim przypadku pojawił się problem z aktywacją certyfikatu – nie było możliwe przesłanie danych z formularza, po czym mój certyfikat zmienił status na „Failed” i nie dało się już nic z nim zrobić. Konieczna była rozmowa z przemiłą panią ze wsparcia SSLs.com, która przeprosiła mnie za niedogodności i od razu zaproponowała przeprowadzenie ręcznej aktywacji i weryfikacji domeny. Po mniej więcej 10 minutach mój certyfikat był już aktywny.

Problemy z migracją adresów URL w Disqus

Jak już wspomniałem, po zmianie adresów URL wszystkie komentarze po prostu znikają i trzeba wykonać zmianę adresów URL w panelu Disqus. Ja skorzystałem (błędnie!) z narzędzia Domain Migration Tool, które zamiast zamienić `http` na `https` w adresach moich wpisów, dodało `https` do istniejących URLi, przez co wszystkie były nieprawidłowe. Co więcej, utworzone zostały puste wątki z poprawnymi adresami. Na szczęście łatwo dało się to „odkręcić” korzystając z narzędzia URL Mapper.

Zdjęcie: Michele M. F.

Bezpośredni link