Jak skonfigurować Signed Exchange przy użyciu programu Web Packager

Dowiedz się, jak korzystać z technologii Signed Exchange (SXG) za pomocą programu Web Packager.

Katie Hempenius
Katie Hempenius

Signed Exchange (SXG) to mechanizm dostarczania, który umożliwia uwierzytelnianie źródła zasobu niezależnie od sposobu jego dostarczenia. Poniżej znajdziesz instrukcje konfigurowania Signed Exchange za pomocą programu pakowania internetowego. Znajdziesz w nim instrukcje dotyczące zarówno certyfikatów podpisanych samodzielnie, jak i CanSignHttpExchanges.

Wyświetlaj SXG za pomocą certyfikatu podpisanego samodzielnie

Używanie podpisanego samodzielnie certyfikatu do obsługi SXG jest używane głównie do demonstracji i testowania. Komponenty SXG podpisane samodzielnie podpisanym certyfikatem generują komunikaty o błędach w przeglądarce, gdy są używane poza środowiskami testowymi. Nie powinny być udostępniane robotom.

Wymagania wstępne

Aby wykonać te instrukcje, musisz mieć w swoim środowisku programistycznym zainstalowane protokoły openssl i Go.

Generowanie certyfikatu podpisanego samodzielnie

W tej sekcji dowiesz się, jak wygenerować certyfikat podpisany samodzielnie, którego można używać z technologią Signed Exchange.

Instrukcje

  1. Wygeneruj klucz prywatny.

    openssl ecparam -out priv.key -name prime256v1 -genkey
    

    Klucz prywatny zostanie zapisany jako plik o nazwie priv.key.

  2. Utwórz żądanie podpisania certyfikatu.

    openssl req -new -sha256 -key priv.key -out cert.csr -subj '/O=Web Packager Demo/CN=example.com'
    

    Żądanie podpisania certyfikatu to blok zakodowanego tekstu, który przekazuje informacje niezbędne do wysłania żądania wystawienia certyfikatu do urzędu certyfikacji. Chociaż nie będziesz prosić o certyfikat z urzędu certyfikacji, musisz utworzyć żądanie podpisania certyfikatu.

    Powyższe polecenie tworzy żądanie podpisania certyfikatu dla organizacji Web Packager Demo, która ma wspólną nazwę example.com. Nazwa powinna być w pełni i jednoznaczną nazwą domeny witryny zawierającej treści, które chcesz spakować jako SXG.

    W wersji produkcyjnej SXG była to witryna należąca do Ciebie. Jednak w środowisku testowym takim jak opisane w tych instrukcjach może to być dowolna witryna.

  3. Utwórz certyfikat z rozszerzeniem CanSignHttpExchanges.

    openssl x509 -req -days 90 -in cert.csr -signkey priv.key -out cert.pem -extfile <(echo -e "1.3.6.1.4.1.11129.2.1.22 = ASN1:NULL\nsubjectAltName=DNS:example.com")
    

    To polecenie używa klucza prywatnego i żądania podpisania certyfikatu utworzonego w krokach 1 i 2, aby utworzyć plik certyfikatu cert.pem. Flaga -extfile wiąże certyfikat z rozszerzeniem certyfikatu CanSignHttpExchanges (1.3.6.1.4.1.11129.2.1.22 to identyfikator obiektu rozszerzenia CanSignHttpExchanges). Dodatkowo flaga -extfile definiuje example.com jako alternatywną nazwę podmiotu.

    Jeśli chcesz poznać zawartość pliku cert.pem, możesz ją wyświetlić, używając tego polecenia:

    openssl x509 -in cert.pem -noout -text
    

    Klucze prywatne i certyfikaty zostały utworzone. W następnej sekcji potrzebujesz plików priv.key i cert.pem.

Skonfiguruj serwer Web Packager na potrzeby testowania

Wymagania wstępne

  1. Zainstaluj Web Packager.

    git clone https://github.com/google/webpackager.git
    
  2. Kompilacja webpkgserver.

    cd webpackager/cmd/webpkgserver
    go build .
    

    webpkgserver to konkretny plik binarny w projekcie narzędzia Web Packager.

  3. Sprawdź, czy program webpkgserver został prawidłowo zainstalowany.

    ./webpkgserver --help
    

    To polecenie powinno zwrócić informacje o wykorzystaniu pola webpkgserver. Jeśli to nie pomoże, najlepiej najpierw sprawdź, czy ścieżka GOPATH jest prawidłowo skonfigurowana.

Instrukcje

  1. Przejdź do katalogu webpkgserver (możliwe, że już jesteś w tym katalogu).

    cd /path/to/cmd/webpkgserver
    
  2. Utwórz plik webpkgsever.toml, kopiując przykład.

    cp ./webpkgserver.example.toml ./webpkgserver.toml
    

    Ten plik zawiera opcje konfiguracji usługi webpkgserver.

  3. Otwórz plik webpkgserver.toml w wybranym edytorze i wprowadź te zmiany:

    • Zmień wiersz #AllowTestCert = false na AllowTestCert = true.
    • Zmień wiersz PEMFile = 'path/to/your.pem', aby odzwierciedlał ścieżkę do utworzonego certyfikatu PEM (cert.pem). Nie zmieniaj wiersza, w którym znajduje się wzmianki o TLS.PEMFile – jest to inna opcja konfiguracji.
    • Zmień wiersz KeyFile = 'priv.key', aby odzwierciedlał ścieżkę do utworzonego klucza prywatnego priv.key. Nie zmieniaj wiersza zawierającego TLS.KeyFile – jest to inna opcja konfiguracji.
    • Zmień wiersz #CertURLBase = '/webpkg/cert' na CertURLBase = 'data:'. CertURLBase wskazuje lokalizację udostępniania certyfikatu SXG. Ta informacja jest używana do ustawiania parametru cert-url w nagłówku Signature kodu SXG. W środowiskach produkcyjnych dyrektywa CertURLBase jest używana w ten sposób: CertURLBase = 'https://mysite.com/'. W przypadku testów lokalnych możesz jednak użyć polecenia CertURLBase = 'data:', aby nakazać webpkgserver użycie adresu URL danych do wbudowania certyfikatu w polu cert-url. W przypadku testów lokalnych jest to najwygodniejszy sposób dostarczania certyfikatu SXG.
    • Zmień wiersz Domain = 'example.org', aby odzwierciedlał domenę, dla której został utworzony certyfikat. Jeśli dokładnie wykonasz instrukcje podane w tym artykule, zmień ustawienie na example.com. webpkgserver będzie pobierać treści tylko z domeny wskazanej przez webpkgserver.toml. Jeśli spróbujesz pobrać strony z innej domeny bez aktualizacji webpkgserver.toml, w dziennikach webpkgserver pojawi się komunikat o błędzie URL doesn't match the fetch targets.

    Opcjonalny

    Jeśli chcesz włączyć lub wyłączyć wstępne wczytywanie zasobów podrzędnych, dostępne są te opcje konfiguracji webpkgserver.toml:

    • Aby wstawić dyrektywy wstawienia webpkgserver służące do wstępnego wczytywania arkuszy stylów i zasobów podrzędnych skryptów jako zasobów SXG, zmień wiersz #PreloadCSS = false na PreloadCSS = true. Dodatkowo zmień wiersz #PreloadJS = false na PreloadJS = true.

      Zamiast korzystać z tej opcji konfiguracji, możesz ręcznie dodać do kodu HTML strony nagłówki Link: rel="preload" i tagi <link rel="preload">.

    • Domyślnie webpkgserver zastępuje istniejące tagi <link rel="preload"> odpowiednimi tagami <link> niezbędnymi do pobrania tych treści jako SXG. W ten sposób webpkgserver ustawi dyrektywy allowed-alt-sxg i header-integrity odpowiednio do potrzeb – autorzy kodu HTML nie będą musieli dodawać ich ręcznie. Aby zastąpić to zachowanie i zachować wartości wstępne wczytywania innych niż SXG, zmień #KeepNonSXGPreloads (default = false) na KeepNonSXGPreloads = true. Pamiętaj, że jeśli ta opcja jest włączona, zgodnie z tymi wymaganiami SXG może nie kwalifikować się do korzystania z pamięci podręcznej Google SXG.

  4. Uruchom aplikację webpkgserver.

    ./webpkgserver
    

    Jeśli serwer uruchomił się prawidłowo, powinny pojawić się te komunikaty logu: shell Listening at 127.0.0.1:8080 Successfully retrieved valid OCSP. Writing to cache in /private/tmp/webpkg

    Komunikaty dziennika mogą wyglądać nieco inaczej. W szczególności katalog używany przez webpkgserver do buforowania certyfikatów różni się w zależności od systemu operacyjnego.

    Jeśli nie widzisz tych komunikatów, sprawdź najpierw webpkgserver.toml.

    Po zaktualizowaniu webpkgserver.toml należy ponownie uruchomić aplikację webpkgserver.

  5. Uruchom Chrome za pomocą tego polecenia: shell /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \ --user-data-dir=/tmp/udd \ --ignore-certificate-errors-spki-list=`openssl x509 -noout -pubkey -in cert.pem | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64`

    To polecenie instruuje Chrome, aby ignorował błędy certyfikatów związane z cert.pem. W ten sposób można testować SXG z użyciem certyfikatu testowego. Jeśli Chrome zostanie uruchomiony bez tego polecenia, sprawdzenie SXG w Narzędziach deweloperskich spowoduje wyświetlenie błędu Certificate verification error: ERR_CERT_INVALID.

    Uwaga:

    Konieczne może być dostosowanie tego polecenia tak, aby odzwierciedlało lokalizację Chrome na komputerze oraz lokalizację cert.pem. Jeśli zostało to zrobione poprawnie, pod paskiem adresu pojawi się ostrzeżenie. Ostrzeżenie powinno być podobne do tego: You are using an unsupported command-line flag: --ignore-certificate-errors-spki-list=9uxADcgc6/ho0mJLRMBcOjfBaN21k0sOInoMchr9CMY=.

    Jeśli ostrzeżenie nie zawiera ciągu skrótu, oznacza to, że lokalizacja certyfikatu SXG nie została prawidłowo wskazana.

  6. Otwórz kartę Sieć w Narzędziach deweloperskich i wejdź na ten URL: http://localhost:8080/priv/doc/https://example.com.

    Spowoduje to wysłanie żądania do instancji webpackager uruchomionej w http://localhost:8080 dotyczącej obiektu SXG zawierającego zawartość https://example.com. /priv/doc/ to domyślny punkt końcowy interfejsu API używany przez webpackager.

    Zrzut ekranu przedstawiający kartę DevTools Network (Sieć) z SXG i jego certyfikatem.

    Na karcie Sieć wymienione są te zasoby:

    • Zasób typu signed-exchange. To jest SXG.
    • Zasób typu cert-chain+cbor. To jest certyfikat SXG. Certyfikaty SXG muszą mieć format application/cert-chain+cbor.
    • Zasób typu document. To treści dostarczone przez SXG.

    Jeśli nie widzisz tych zasobów, wyczyść pamięć podręczną przeglądarki, a następnie załaduj ponownie http://localhost:8080/priv/doc/https://example.com.

    Kliknij kartę Podgląd, aby wyświetlić więcej informacji o Signed Exchange i jego podpisie.

    Zrzut ekranu karty Podgląd z sekcją SXG

Wyświetlaj podpisane wymiany za pomocą certyfikatu CanSignHttpExchanges

Instrukcje w tej sekcji wyjaśniają, jak wyświetlać SXG za pomocą certyfikatu CanSignHttpExchanges. Wykorzystanie SXG w środowisku produkcyjnym wymaga certyfikatu CanSignHttpExchanges.

Dla zachowania zwięzłości te instrukcje zostały napisane przy założeniu, że znasz pojęcia omówione w sekcji Konfigurowanie podpisanych giełd przy użyciu certyfikatu podpisanego samodzielnie.

Wymagania wstępne

  • Masz certyfikat CanSignHttpExchanges. Ta strona zawiera listę urzędów certyfikacji, które oferują ten typ certyfikatu.

  • Jeśli nie masz certyfikatu, możesz skonfigurować serwer WWW, aby automatycznie pobierał certyfikaty z urzędu certyfikacji. Możesz śledzić wskazówki, co się wydarzy webpkgserver.toml na tej tej stronie.

  • Chociaż nie jest to wymagane, zdecydowanie zalecamy uruchamianie webpkgserver za serwerem brzegowym. Jeśli nie używasz serwera granicznego, musisz skonfigurować opcje TLS.PEMFile i TLS.KeyFile w webpkgserver.toml. Domyślnie webpkgserver działa przez HTTP. Jednak aby przeglądarka mogła uznać je za ważne, certyfikaty SXG muszą być przesyłane przy użyciu protokołu HTTPS. Skonfigurowanie TLS.PEMFile i TLS.KeyFile umożliwia webpkgserver używanie HTTPS i dlatego wyświetla certyfikat SXG bezpośrednio w przeglądarce.

Instrukcje

  1. Utwórz plik PEM, łącząc certyfikat SXG witryny z certyfikatem CA witryny. Więcej instrukcji na ten temat znajdziesz tutaj.

    PEM to format pliku powszechnie używany jako „kontener” do przechowywania wielu certyfikatów.

  2. Utwórz nowy plik webpkgsever.toml, kopiując przykład.

    cp ./webpkgserver.example.toml ./webpkgserver.toml
    
  3. Otwórz plik webpkgserver.toml w wybranym edytorze i wprowadź te zmiany:

    • Zmień wiersz PEMFile = cert.pem, aby odzwierciedlał lokalizację pliku PEM zawierającego pełny łańcuch certyfikatów.
    • Zmień wiersz KeyFile = 'priv.key', aby odzwierciedlał lokalizację klucza prywatnego odpowiadającego Twojemu plikowi PEM.
    • Zmień wiersz Domain = 'example.org', aby odzwierciedlał Twoją witrynę.
    • (Opcjonalnie) Aby usługa webpkgserver automatycznie odnawiała certyfikat SXG co 90 dni (45 dni w przypadku Google), skonfiguruj opcje w sekcji [SXG.ACME] w webpkgserver.toml. Ta opcja dotyczy tylko witryn z konfiguracją konta DigiCert lub Google ACME.
  4. Skonfiguruj serwer brzegowy, aby przekierowywał ruch do instancji webpkgserver.

    webpkgserver obsługuje 2 główne typy żądań: żądania dotyczące SXG (które są obsługiwane przez punkt końcowy /priv/doc/) i żądania certyfikatu SXG (obsługiwane przez punkt końcowy /webpkg/cert/). Reguły przepisywania adresów URL w przypadku każdego z tych typów żądań różnią się nieznacznie. Więcej informacji znajdziesz w artykule o uruchamianiu za serwerem brzegowym.

    Uwaga:

    Domyślnie webpkgserver udostępnia certyfikat SXG w domenie /webpkg/cert/$CERT_HASH, np. /webpkg/cert/-0QmE0gvoedn92gtwI3s7On9zPevJGm5pn2RYhpZxgY. Aby wygenerować $CERT_HASH, uruchom to polecenie: shell openssl base64 -in cert.pem -d | openssl dgst -sha256 -binary | base64 | tr /+ _- | tr -d =