Włączanie protokołu HTTPS na swoich serwerach

Chris Palmer
Chris Palmer

Na tej stronie znajdziesz wskazówki dotyczące konfigurowania protokołu HTTPS na serwerach, w tym następujące kroki:

  • Tworzę 2048-bitową parę kluczy RSA (publiczny i prywatny).
  • Generowanie żądania podpisania certyfikatu (CSR) zawierającego Twój klucz publiczny.
  • Udostępnienie żądania podpisania certyfikatu urzędowi certyfikacji w celu otrzymania ostatecznej wersji lub łańcuch certyfikatów.
  • Instalując końcowy certyfikat w miejscu niedostępnym z internetu, na przykład /etc/ssl (Linux i Unix) lub wszędzie tam, gdzie wymaga tego program IIS (Windows).

Generowanie kluczy i żądań podpisania certyfikatów

W tej sekcji korzystamy z programu wiersza poleceń opensl, który zawiera większość Linux, BSD i Mac OS X do generowania kluczy prywatnych i publicznych oraz żądania podpisania certyfikatu.

Generowanie pary kluczy (publiczny i prywatny)

Najpierw wygeneruj 2048-bitową parę kluczy RSA. Krótszy klucz może zostać złamany przez ataki brute-force, a dłuższe klucze zużywają niepotrzebne zasoby.

Aby wygenerować parę kluczy RSA, użyj tego polecenia:

openssl genrsa -out www.example.com.key 2048

Zostaną wyświetlone te dane wyjściowe:

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

Generowanie żądania podpisania certyfikatu

W tym kroku umieścisz swój klucz publiczny i informacje o organizacji i witrynę do żądania podpisania certyfikatu (CSR). openssl prosi o podanie wymaganych metadanych.

Uruchamiam następujące polecenie:

openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr

Uzyskuje taki obraz:

You are about to be asked to enter information that will be incorporated
into your certificate request

What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:[email protected]

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Aby sprawdzić poprawność żądania podpisania certyfikatu, uruchom to polecenie:

openssl req -text -in www.example.com.csr -noout

Odpowiedź powinna wyglądać tak:

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/[email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
                    f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
                    ...
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
         2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
         ...

Przesyłanie żądania podpisania certyfikatu do urzędu certyfikacji

Różne urzędy certyfikacji (CA) wymagają przesłania do nich żądań podpisania certyfikatu na różne sposoby. Może to być wypełnienie formularza na stronie internetowej lub wysłanie przedstawiciel ds. obsługi klienta e-mailem. Niektóre urzędy certyfikacji lub ich sprzedawcy mogą nawet zautomatyzować część lub wszystkie w tym, w niektórych przypadkach, par kluczy i generowania żądań podpisania certyfikatu.

Wyślij żądanie podpisania certyfikatu do urzędu certyfikacji i postępuj zgodnie z jego instrukcjami, aby otrzymać ostateczną wersję dokumentu. lub łańcuch certyfikatów.

Różne urzędy certyfikacji pobierają różną kwotę za usługę weryfikacji Twojego klucza publicznego.

Dostępne są też opcje mapowania klucza na więcej niż jedną nazwę DNS, w tym kilka różnych nazw (np. wszystkie domeny example.com, www.example.com, example.net, i www.example.net) lub „wildcard” takie jak *.example.com.

Skopiuj certyfikaty na wszystkie serwery frontendu w oknie takiej jak /etc/ssl (Linux i Unix) lub wszędzie tam, gdzie wymaga się serwer IIS (Windows) .

Włącz protokół HTTPS na swoich serwerach

Włączenie protokołu HTTPS na serwerach jest kluczowym krokiem zapewnienia bezpieczeństwa do Twoich stron internetowych.

  • Skonfiguruj serwer pod kątem protokołu HTTPS za pomocą narzędzia konfiguracji serwera Mozilla .
  • Regularnie testuj swoją witrynę za pomocą narzędzia Qualys Testowanie serwera SSL i sprawdzanie dostaniemy co najmniej A lub A+.

W tym momencie musisz podjąć kluczową decyzję dotyczącą operacji. Wybierz jedną z opcji :

  • Przydzielanie osobnego adresu IP dla każdej nazwy hosta, który obsługuje Twój serwer WWW. .
  • Używaj hostingu wirtualnego opartego na nazwach.

Jeśli dla każdej nazwy hosta używasz osobnego adresu IP, możesz zastosować HTTP i HTTPS dla wszystkich klientów. Jednak większość operatorów witryn używa nazw opartych na nazwach na serwerze wirtualnym, aby zachować adresy IP, a także dlatego, że ogólne.

Jeśli nie masz jeszcze usługi HTTPS dostępnej na Twoich serwerach, włącz ją teraz (bez przekierowania HTTP do HTTPS. Patrz: Przekierowanie HTTP do HTTPS ). Skonfiguruj serwer WWW, aby używał wybranych certyfikatów Kupiono i zainstalowano. Plik konfiguracji Mozilli, generatora przydatne.

Jeśli masz wiele nazw hostów lub subdomen, każda z nich musi używać właściwej certyfikat.

Sprawdzaj teraz regularnie i przez cały okres istnienia swojej witryny z konfiguracją z użyciem parametru Qualys Test serwera SSL. Twoja witryna powinna mieć ocenę A lub A+. Wszystkie problemy, które powodują obniżenie oceny, traktuj jako i zachowuj staranność, ponieważ nowe ataki na algorytmy i protokoły nieustannie się rozwijają.

Określ względne adresy URL wewnątrz witryny

Teraz gdy witryna działa zarówno przy użyciu protokołu HTTP, jak i HTTPS, wszystko musi działać tak, bez względu na protokół. Ważnym czynnikiem jest zastosowanie względnych adresów URL linków wewnętrznych.

Upewnij się, że wewnętrzne i zewnętrzne adresy URL nie zależą od konkretnego protokołu. Użyj ścieżek względnych lub wyklucz protokół jako //example.com/something.js.

Wyświetlanie strony zawierającej zasoby HTTP przy użyciu protokołu HTTPS może powodować problemy. Gdy przeglądarka napotka w inny sposób zabezpieczonej stronie korzystającej z niezabezpieczonych zasobów, ostrzega użytkowników, nie jest całkowicie bezpieczny, a niektóre przeglądarki odmawiają wczytywania lub wykonywania i rozdziela układ strony. Możesz jednak bezpiecznie stosować protokół HTTPS na stronie HTTP. Więcej wskazówek dotyczących rozwiązywania tych problemów znajdziesz tutaj: Poprawianie treści mieszanych.

Klikanie linków HTTP do innych stron w Twojej witrynie może powodować obniżenie dla użytkowników z HTTPS do HTTP. Aby rozwiązać ten problem, ustaw wewnętrzne adresy URL jako zależne od protokołu (bez protokołu, zaczynając od //example.com) lub zależne od hosta (zaczynające się od ścieżkę, np. /jquery.js).

Tak
<h1>Welcome To Example.com</h1>
<script src="/https/web.dev/jquery.js"></script>
<link rel="stylesheet" href="/https/web.dev/assets/style.css"/>
<img src="/https/web.dev/images/logo.png"/>;
<p>A <a href="/https/web.dev/2014/12/24">new post on cats!</a></p>
Używaj względnych wewnętrznych adresów URL.
Tak
<h1>Welcome To Example.com</h1>
<script src="//example.com/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="//img.example.com/logo.png"/>;
<p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
Możesz też używać wewnętrznych adresów URL zależnych od protokołu.
Tak
<h1>Welcome To Example.com</h1>
<script src="/https/web.dev/jquery.js"></script>
<link rel="stylesheet" href="/https/web.dev/assets/style.css"/>
<img src="/https/web.dev/images/logo.png"/>;
<p>A <a href="/https/web.dev/2014/12/24">new post on cats!</a></p>
<p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
W miarę możliwości używaj adresów URL HTTPS w linkach do innych witryn.

Aby uniknąć pomyłek, aktualizuj linki za pomocą skryptu, a nie ręcznie. Jeśli że zawartość witryny znajduje się w bazie danych, przetestuj swój skrypt na kopii programistycznej w bazie danych. Jeśli treść witryny składa się tylko z prostych plików, przetestuj skrypt w kopii programistycznej. Przekaż zmiany do wersji produkcyjnej dopiero po że zmiany przejdą kontrolę jakości tak jak zwykle. Możesz użyć skryptu Brama van Damme'a lub podobnego, aby wykrywać treści mieszane w witrynie.

Gdy dodajesz linki do innych witryn (zamiast dodawać ich zasoby), nie zmieniaj protokołu. Nie masz kontroli nad działaniem tych witryn.

Aby migracja przebiegła w przypadku dużych witryn, zalecamy użycie adresów URL zależnych od protokołu. Jeśli nie masz pewności, czy możesz już w pełni wdrożyć protokół HTTPS, wymuszanie na stronie używanie HTTPS dla wszystkich zasobów podrzędnych może się nie udać. Prawdopodobny okres w którym HTTPS jest dla Ciebie nowym i dziwnym, a witryna HTTP musi nadal działać. jak nigdy dotąd. Z czasem ukończysz migrację i zablokujesz protokół HTTPS (patrz dwie następne sekcje).

czy witryna opiera się na skryptach, obrazach lub innych zasobach pochodzących z takiej jak CDN lub jquery.com, masz 2 opcje:

  • W przypadku tych zasobów używaj adresów URL zależnych od protokołu. Jeśli firma zewnętrzna nie protokołu HTTPS, poproś go o to. Większość już tak, w tym jquery.com.
  • Udostępnia zasoby z kontrolowanego przez Ciebie serwera, który oferuje zarówno protokół HTTP, i HTTPS. I tak często jest to dobry pomysł, ponieważ wtedy będzie lepiej nad wyglądem, wydajnością i bezpieczeństwem witryny oraz w trosce o bezpieczeństwo Twojej witryny.
.

Przekieruj HTTP do HTTPS

Aby umożliwić wyszukiwarkom dostęp do witryny przy użyciu protokołu HTTPS, umieść parametr link kanoniczny na stronie nagłówka każdej strony za pomocą tagów <link rel="canonical" href="https://…"/>.

Włącz rygorystyczne zabezpieczenia transportu i bezpieczne pliki cookie

W tym momencie możesz się „wtedy” wykorzystanie protokołu HTTPS:

  • Używaj mechanizmu HTTP Strict Transport Security (HSTS), by uniknąć kosztu błędu 301 .
  • Zawsze ustawiaj flagę Secure w przypadku plików cookie.

Po pierwsze, korzystaj z mechanizmu Strict Transport Security i poinformować klientów, że zawsze łączą się z serwerem przy użyciu protokołu HTTPS, w przypadku odwołania do http://. zapobiega to atakom takim jak: Usuwanie SSL, i pozwala uniknąć kosztów w obie strony w przypadku linii 301 redirect, którą wdrożyliśmy Przekieruj HTTP do HTTPS.

Aby włączyć HSTS, ustaw nagłówek Strict-Transport-Security. Strona HSTS programu OWASP zawiera linki do instrukcji do różnych rodzajów oprogramowania serwerowego.

Większość serwerów WWW oferuje podobną możliwość dodawania niestandardowych nagłówków.

Ważne jest również, aby klienci nigdy nie wysyłali plików cookie (na przykład uwierzytelnianie czy ustawienia witryny) przez HTTP. Na przykład, jeśli użytkownik jeśli plik cookie uwierzytelniania byłby widoczny w postaci zwykłego tekstu, to Twoja gwarancja bezpieczeństwa może zostać zniszczony podczas całej sesji, nawet jeśli wykonane zostały wszystkie inne czynności dobrze!

Aby tego uniknąć, zmień w swojej aplikacji internetowej flagę „Secure” w przypadku plików cookie zestawów. Na tej stronie OWASP dowiesz się, jak ustawić flagę Secure w kilku strukturach aplikacji. Każda platforma aplikacji ma sposób na ustawienie odpowiedniej flagi.

Większość serwerów WWW oferuje prostą funkcję przekierowania. Użyj formatu: 301 (Moved Permanently) aby wskazać wyszukiwarkom i przeglądarkom, że wersja HTTPS jest kanoniczna, i przekieruj użytkowników z protokołu HTTP do wersji HTTPS witryny.

Ranking wyników wyszukiwaniaSzukaj w rankingu

Google stosuje protokół HTTPS jako pozytywną jakość wyszukiwania . Publikujemy również przewodnik na temat przenoszenia, przenoszenia i migracji witryny przy jednoczesnym zachowaniu pozycji w wynikach wyszukiwania. Bing publikuje również wytyczne dotyczące dla webmasterów.

Wyniki

Po odpowiednim dostrojeniu warstw treści i aplikacji (patrz Steve Souders książki), pozostałe adresy TLS w porównaniu z ogólnymi kosztami aplikacji. Można również zmniejszyć i amortyzować te koszty. Porady na temat protokołu TLS zapoznaj się z artykułem na temat wydajności sieci przeglądarki Ilja Grigorika oraz OpenSSL Cookbook i Kuloodporne połączenia SSL i TLS.

W niektórych przypadkach protokół TLS może poprawić wydajność, głównie dzięki HTTP/2 to możliwe. Więcej informacji znajdziesz w filmie Chris Palmer's na temat wydajności HTTPS i HTTP/2 Chrome Dev Summit 2014.

Nagłówki strony odsyłającej

Gdy użytkownicy klikają linki z Twojej witryny HTTPS do innych witryn HTTP, klienty użytkownika nie wysyłaj nagłówka strony odsyłającej. W takim przypadku istnieje kilka sposobów Rozwiąż go:

  • Pozostałe witryny powinny zacząć korzystać z protokołu HTTPS. Jeśli strony odsyłające wypełniają Sekcja Włącz HTTPS na swoich serwerach w w tym przewodniku, w swojej witrynie możesz zmieniać linki w swojej witrynie z http:// na https:// lub użyj linków zależnych od protokołu.
  • Aby rozwiązać różne problemy z nagłówkami stron odsyłających, użyj nowej standard zasad dotyczących stron odsyłających.
.

Przychody z reklam

Operatorzy witryn, którzy zarabiają na wyświetlaniu reklam, chcą mieć pewność, przejście na protokół HTTPS nie zmniejsza liczby wyświetleń reklam. Jednak z powodu różnych czynników obaw związanych z bezpieczeństwem treści, nagłówek HTTP <iframe> nie działa na stronie HTTPS. Dopóki reklamodawcy nie będą publikować treści przez HTTPS, operatorzy witryn nie mogą migrować do HTTPS bez utraty przychodów z reklam; ale dopóki operatorzy witryn nie przejdą na HTTPS, reklamodawców nie ma żadnej motywacji do publikowania HTTPS.

Mogą Państwo rozpocząć proces przełamywania tego braku, wykorzystując do tego reklamodawców, oferują usługi reklamowe przez HTTPS, a reklamodawcy, którzy nie obsługują HTTPS, a przynajmniej uczynić z niej jedną z opcji. Może być konieczne odłożenie ukończenia Ustaw adresy URL IntraSite względne, aż liczba reklamodawców współdziałają ze sobą.