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

Dowiedz się, jak obsługiwać Signed Exchange (SXG) za pomocą narzędzia Web Packager.

Katie Hempenius
Katie Hempenius
X

Technologia Signed Exchange (SXG) to mechanizm dostarczania, uwierzytelnienie pochodzenia zasobu niezależnie od sposobu jego dostarczenia. Poniżej opisujemy, jak skonfigurować Signed Exchange za pomocą Web Packager. Instrukcje dla zarówno samodzielnie podpisanych, jak i CanSignHttpExchanges certyfikatów.

Obsługa SXG z użyciem certyfikatu podpisanego samodzielnie

Używanie samodzielnie podpisanego certyfikatu do obsługi SXG jest używane głównie w celach demonstracyjnych i testowych. Usługi SXG podpisane samodzielnie za pomocą certyfikatu spowoduje generowanie w przeglądarce komunikatów o błędach, jeśli będą używane poza testami i nie powinny być udostępniane robotom.

Wymagania wstępne

Aby wykonać te instrukcje, musisz mieć openssl i Zainstalowana w środowisku programistycznym aplikacja Go.

Generowanie certyfikatu podpisanego samodzielnie

W tej sekcji wyjaśniono, jak wygenerować samodzielnie podpisany certyfikat, który można wykorzystać używany w technologii Signed Exchange.

Instrukcje

  1. wygenerować klucz prywatny,

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

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

  2. Utworzenie podpisywania certyfikatu request (CSR).

    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 zażądania certyfikatu od urzędu certyfikacji. Chociaż nie będziesz żądać certyfikatu od CA, musisz utworzyć żądanie podpisania certyfikatu.

    Powyższe polecenie tworzy żądanie podpisania certyfikatu dla organizacji o nazwie Web Packager Demo, która ma wspólny nazwa example.com. (typowa nazwa) powinna być w pełni kwalifikowaną nazwą domeny witryny, która zawiera które chcesz spakować w formacie SXG.

    W przypadku konfiguracji SXG w wersji produkcyjnej jest to witryna, która należy do Ciebie. Jednak w przypadku takiego jak opisane w tych instrukcjach, może to być dowolny witrynie.

  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 do utworzenia pliku certyfikatu cert.pem. Flaga -extfile wiąże certyfikat z rozszerzenie certyfikatu CanSignHttpExchanges (1.3.6.1.4.1.11129.2.1.22 to obiekt identyfikator dla rozszerzenia CanSignHttpExchanges). Dodatkowo flaga -extfile również określa example.com jako Subject Alternative Nazwa.

    Jeśli chcesz poznać zawartość cert.pem, możesz wyświetlić je za pomocą to polecenie:

    openssl x509 -in cert.pem -noout -text

    To już koniec tworzenia kluczy prywatnych i certyfikatów. Potrzebujesz do tego priv.key i cert.pem plików w następnej sekcji.

Skonfiguruj serwer pakietu internetowego na potrzeby testowania

Wymagania wstępne

  1. Zainstaluj program pakietu internetowego.

    git clone https://github.com/google/webpackager.git

  2. Kompilacja webpkgserver.

    cd webpackager/cmd/webpkgserver
go build .

    webpkgserver to konkretny plik binarny w projekcie Web Packager.

  3. Sprawdź, czy aplikacja webpkgserver została prawidłowo zainstalowana.

    ./webpkgserver --help

    To polecenie powinno zwrócić informacje o użyciu webpkgserver. Jeśli To nie zadziała. Na początek sprawdź, czy Twoje Konfiguracja GOPATH jest skonfigurowana .

Instrukcje

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

    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 aplikację webpkgserver.toml w wybranym edytorze i wykonaj te czynności: zmiany:

    • Zmień linię #AllowTestCert = false na AllowTestCert = true.
    • Zmień linię PEMFile = 'path/to/your.pem' tak, by odzwierciedlała ścieżkę utworzony certyfikat PEM cert.pem. Nie zmieniaj wartości wiersz zawierający TLS.PEMFile – jest to inna opcja konfiguracji.
    • Zmień linię KeyFile = 'priv.key' tak, by odzwierciedlić ścieżkę klucz prywatny priv.key utworzony przez Ciebie. Nie zmieniaj linii wspomina o TLS.KeyFile – jest to inna opcja konfiguracji.
    • Zmień linię #CertURLBase = '/webpkg/cert' na CertURLBase = 'data:'. CertURLBase wskazuje lokalizację usługi SXG. certyfikat. Służą one do ustawiania parametru cert-url w: Signature. w nagłówku SXG. W środowiskach produkcyjnych używany jest interfejs CertURLBase w ten sposób: CertURLBase = 'https://mysite.com/'. Jednak w przypadku reklam lokalnych testowania, CertURLBase = 'data:' może służyć do instruowania funkcji webpkgserver aby użyć danych Adres URL aby wstawić certyfikat w polu cert-url. W przypadku testów lokalnych jest to najprostszy sposób dostarczania certyfikatu SXG.
    • Zmodyfikuj wiersz Domain = 'example.org', tak aby odpowiadał domenie utworzył(a) certyfikat dla. Jeśli instrukcje w tym artykule zostały wykonane dosłownego artykułu, należy zmienić na example.com. webpkgserver będzie pobierać treści tylko ze wskazanej domeny webpkgserver.toml Jeśli próbujesz pobrać strony z innej domeny bez aktualizowania webpkgserver.toml, logi webpkgserver będą widoczne komunikat o błędzie URL doesn't match the fetch targets

    Opcjonalny

    Jeśli chcesz włączyć lub wyłączyć zasób podrzędny wstępne ładowanie, te opcje konfiguracji webpkgserver.toml są odpowiednie:

    • Aby korzystać z webpkgserver instrukcji wstawiania do wstępnego wczytywania arkusza stylów i zasobów podrzędnych skryptu jako SXG, zmień wiersz #PreloadCSS = false do: PreloadCSS = true. Dodatkowo zmień linię #PreloadJS = false na PreloadJS = true.

      Zamiast używać tej opcji konfiguracji, możesz ręcznie dodaj nagłówki Link: rel="preload" i tagi <link rel="preload"> do w kodzie HTML strony.

    • Domyślnie tag webpkgserver zastępuje istniejące tagi <link rel="preload"> z odpowiednimi tagami <link> niezbędnymi do pobrania tej treści jako SXG. Dzięki temu webpkgserver ustawi allowed-alt-sxg. oraz header-integrity w razie potrzeby – autorzy kodu HTML nie muszą dodawać ich ręcznie. Do zastąpić to zachowanie i zachować istniejące wstępne załadowania inne niż SXG, zmienić #KeepNonSXGPreloads (default = false) do KeepNonSXGPreloads = true. Pamiętaj, że włączenie tej opcji może sprawić, że SXG nie będzie kwalifikować się do pamięci podręcznej Google SXG wymagania.

  4. Uruchom webpkgserver.

    ./webpkgserver

    Jeśli serwer się uruchomił, w logu powinny pojawić się te komunikaty: 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żywane przez webpkgserver do buforowania certyfikatów różni się w zależności od systemu operacyjnego.

    Jeśli nie widzisz tych komunikatów, w pierwszej kolejności skorzystaj z możliwości rozwiązania tego problemu. krok to sprawdzić webpkgserver.toml.

    Jeśli zaktualizujesz aplikację webpkgserver.toml, musisz 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ł powiązane błędy certyfikatu dzięki cert.pem. Umożliwia to testowanie SXG za pomocą testu certyfikat. Jeśli Chrome został uruchomiony bez tego polecenia, sprawdź SXG w Narzędziach deweloperskich wyświetli błąd Certificate verification error: ERR_CERT_INVALID.

    Uwaga:

    Konieczne może być dostosowanie tego polecenia, aby odpowiadało lokalizacji Chrome na Twojego komputera oraz lokalizację urządzenia cert.pem. Jeśli zostało to już zrobione prawidłowo, pod paskiem adresu powinno 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 krzyżykowego, to znaczy, że nie został on prawidłowo wskazać lokalizację certyfikatu SXG.

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

    Spowoduje to wysłanie żądania do instancji webpackager działającej pod adresem http://localhost:8080 w przypadku SXG zawierającego treść https://example.com /priv/doc/ to domyślny punkt końcowy API używany przez webpackager

    Zrzut ekranu karty Network (Sieć) w Narzędziach deweloperskich, na której widać platformę SXG i jej certyfikat.

    Na karcie Network (Sieć) dostępne są te zasoby:

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

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

    Kliknij kartę Preview (Podgląd), aby wyświetlić więcej informacji o technologii Signed Exchange i jej podpis.

    Zrzut ekranu przedstawiający kartę Podgląd z SXG

Udostępnianie podpisanej wymiany za pomocą certyfikatu CanSignHttpExchanges

Instrukcje w tej sekcji wyjaśniają, jak obsługiwać SXG za pomocą Certyfikat CanSignHttpExchanges. Użycie w środowisku produkcyjnym SXG wymaga: Certyfikat CanSignHttpExchanges.

Dla zachowania zwięzłości instrukcje napisano przy założeniu, znasz pojęcia omówione w artykule Konfiguracja Signed Exchanges używając samodzielnie podpisanego tagu certyfikat .

Wymagania wstępne

  • Masz certyfikat CanSignHttpExchanges. Ten Strona zawiera listę urzędów certyfikacji, które oferują dany typ certyfikatu.

  • Jeśli nie masz certyfikatu, możesz skonfigurować serwer webpkgserver tak, automatycznie pobiera certyfikaty z urzędu certyfikacji. Możesz śledzić trasa dojazdu w: webpkgserver.toml w tym .

  • Chociaż nie jest to wymagane, zdecydowanie zalecamy webpkgserver za serwerem brzegowym. Jeśli nie używasz serwera granicznego, będzie musiał skonfigurować opcje TLS.PEMFile i TLS.KeyFile w webpkgserver.toml Domyślnie webpkgserver działa przez HTTP. SXG certyfikaty muszą być udostępniane przez HTTPS, aby przeglądarka mogła je uznać za prawidłowe. Jeśli skonfigurujesz TLS.PEMFile i TLS.KeyFile, usługa webpkgserver będzie mogła używać HTTPS i tym samym udostępniasz certyfikat SXG bezpośrednio przeglądarce.

Instrukcje

  1. Utwórz plik PEM, łącząc certyfikat SXG witryny z: certyfikat CA Twojej witryny. Więcej instrukcji na ten temat można znaleźć 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 aplikację webpkgserver.toml w wybranym edytorze i wybierz następujące zmiany:

    • Zmień wiersz PEMFile = cert.pem, aby odzwierciedlić lokalizację pliku PEM. zawierający pełny łańcuch certyfikatów.
    • Zmień linię KeyFile = 'priv.key', aby odzwierciedlić lokalizację klucz prywatny odpowiadający Twojemu plikowi PEM.
    • Zmodyfikuj wiersz Domain = 'example.org', tak 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 certyfikatem DigiCert lub zakładanie konta Google ACME.

  4. Skonfiguruj serwer brzegowy tak, aby przekierowywał ruch do webpkgserver instancji.

    webpkgserver obsługuje 2 główne typy żądań: w przypadku usług SXG (obsługiwanych przez punkt końcowy /priv/doc/) i żądań certyfikat SXG (obsługiwany przez punkt końcowy /webpkg/cert/). Reguły przepisywania adresów URL w przypadku każdego z tych typów żądań nieco się różnią. Dla: więcej informacji znajdziesz w sekcji Uruchamianie za krawędzią interfejsu

    Uwaga:

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