Signed Exchanges mit Web Packager einrichten

Hier erfahren Sie, wie Sie Signed Exchanges (SXGs) mit Web Packager bereitstellen.

Katie Hempenius
Katie Hempenius
X

Ein Signed Exchange-Paket (SXG) ist ein Übermittlungsmechanismus, der es ermöglicht, den Ursprung einer Ressource unabhängig von der Art der Übermittlung zu authentifizieren. In der folgenden Anleitung wird erläutert, wie Sie Signed Exchanges mit Web Packager einrichten. Anleitungen sind sowohl für selbst signierte Zertifikate als auch für CanSignHttpExchanges-Zertifikate enthalten.

SXGs mit einem selbst signierten Zertifikat bereitstellen

Die Verwendung eines selbst signierten Zertifikats zur Bereitstellung von SXGs dient hauptsächlich zu Demonstrations- und Testzwecken. SXGs, die mit einem selbst signierten Zertifikat signiert sind, generieren im Browser Fehlermeldungen, wenn sie außerhalb von Testumgebungen verwendet werden, und sollten Crawlern nicht angezeigt werden.

Voraussetzungen

Damit Sie dieser Anleitung folgen können, müssen openssl und Go in Ihrer Entwicklungsumgebung installiert sein.

Selbst signiertes Zertifikat generieren

In diesem Abschnitt wird erläutert, wie Sie ein selbst signiertes Zertifikat generieren, das mit Signed Exchanges verwendet werden kann.

Anleitung

  1. Generieren Sie einen privaten Schlüssel.

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

    Der private Schlüssel wird als Datei mit dem Namen priv.key gespeichert.

  2. Erstellen Sie eine Anfrage zur Signierung des Zertifikats (Certificate Signing Request, CSR).

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

    Eine Zertifikatssignieranfrage ist ein Block mit codiertem Text, der die erforderlichen Informationen enthält, um ein Zertifikat von einer Zertifizierungsstelle anzufordern. Sie werden zwar kein Zertifikat von einer Zertifizierungsstelle anfordern, müssen aber eine Anfrage zur Zertifikatsignierung stellen.

    Mit dem obigen Befehl wird eine Anfrage zur Zertifikatsignierung für eine Organisation namens Web Packager Demo mit dem allgemeinen Namen example.com erstellt. Der allgemeine Name sollte der voll qualifizierte Domainname der Website sein, die den Inhalt enthält, den du als SXG packen möchtest.

    Bei einer SXG-Produktionsversion ist das eine Website, deren Inhaber du bist. In einer Testumgebung, wie in dieser Anleitung beschrieben, kann es sich jedoch um einen beliebigen Standort handeln.

  3. Erstellen Sie ein Zertifikat mit der Erweiterung 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")

    Dieser Befehl verwendet den privaten Schlüssel und die in den Schritten 1 und 2 erstellte CSR, um die Zertifikatsdatei cert.pem zu erstellen. Das Flag -extfile verknüpft das Zertifikat mit der Zertifikatserweiterung CanSignHttpExchanges (1.3.6.1.4.1.11129.2.1.22 ist die Objekt-ID für die Erweiterung CanSignHttpExchanges). Außerdem definiert das Flag -extfile auch example.com als alternativen Namen.

    Wenn Sie mehr über den Inhalt von cert.pem erfahren möchten, können Sie ihn mit dem folgenden Befehl aufrufen:

    openssl x509 -in cert.pem -noout -text

    Sie haben die privaten Schlüssel und Zertifikate erstellt. Sie benötigen die Dateien priv.key und cert.pem im nächsten Abschnitt.

Web Packager-Server zum Testen einrichten

Voraussetzungen

  1. Installieren Sie Web Packager.

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

  2. webpkgserver erstellen.

    cd webpackager/cmd/webpkgserver
go build .

    webpkgserver ist eine spezifische Binärdatei im Web Packager-Projekt.

  3. Prüfe, ob webpkgserver richtig installiert wurde.

    ./webpkgserver --help

    Mit diesem Befehl sollten Informationen zur Verwendung von webpkgserver zurückgegeben werden. Sollte dies nicht funktionieren, sollten Sie zuerst überprüfen, ob Ihr GOPATH richtig konfiguriert ist.

Anleitung

  1. Wechseln Sie zum Verzeichnis webpkgserver. Sie befinden sich möglicherweise bereits in diesem Verzeichnis.

    cd /path/to/cmd/webpkgserver

  2. Erstellen Sie durch Kopieren des Beispiels eine webpkgsever.toml-Datei.

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

    Diese Datei enthält die Konfigurationsoptionen für webpkgserver.

  3. Öffnen Sie webpkgserver.toml mit einem Editor Ihrer Wahl und nehmen Sie die folgenden Änderungen vor:

    • Ändern Sie die Zeile #AllowTestCert = false in AllowTestCert = true.
    • Ändern Sie die Zeile PEMFile = 'path/to/your.pem' so, dass sie den Pfad zum PEM-Zertifikat cert.pem widerspiegelt, das Sie erstellt haben. Ändern Sie nicht die Zeile mit TLS.PEMFile – dies ist eine andere Konfigurationsoption.
    • Ändern Sie die Zeile KeyFile = 'priv.key' so, dass sie dem Pfad des privaten Schlüssels priv.key entspricht, den Sie erstellt haben. Ändern Sie nicht die Zeile mit TLS.KeyFile, da dies eine andere Konfigurationsoption ist.
    • Ändern Sie die Zeile #CertURLBase = '/webpkg/cert' in CertURLBase = 'data:'. CertURLBase gibt den Bereitstellungsort des SXG-Zertifikats an. Mit diesen Informationen wird der Parameter cert-url im Header Signature des SXG festgelegt. In Produktionsumgebungen wird CertURLBase so verwendet: CertURLBase = 'https://mysite.com/'. Für lokale Tests kann CertURLBase = 'data:' jedoch verwendet werden, um webpkgserver anzuweisen, eine Daten-URL zu verwenden, um das Zertifikat im Feld cert-url einzufügen. Für lokale Tests ist dies die gängigste Methode, um das SXG-Zertifikat bereitzustellen.
    • Ändern Sie die Zeile Domain = 'example.org' so, dass sie die Domain widerspiegelt, für die Sie ein Zertifikat erstellt haben. Wenn Sie der Anleitung in diesem Artikel wortgetreu gefolgt sind, sollte dies in example.com geändert werden. webpkgserver ruft nur Inhalte von der Domain ab, die durch webpkgserver.toml angegeben ist. Wenn Sie versuchen, Seiten aus einer anderen Domain abzurufen, ohne webpkgserver.toml zu aktualisieren, wird in den webpkgserver-Logs die Fehlermeldung URL doesn't match the fetch targets angezeigt.

    Optional

    Wenn Sie das Vorabladen von Unterressourcen aktivieren oder deaktivieren möchten, sind die folgenden webpkgserver.toml-Konfigurationsoptionen relevant:

    • Wenn Sie webpkgserver-Einfügeanweisungen zum Vorabladen von Stylesheet- und Skript-Unterressourcen als SXGs haben möchten, ändern Sie die Zeile #PreloadCSS = false in PreloadCSS = true. Ändern Sie außerdem die Zeile #PreloadJS = false in PreloadJS = true.

      Als Alternative zu dieser Konfigurationsoption kannst du Link: rel="preload"-Header und <link rel="preload">-Tags manuell in den HTML-Code einer Seite einfügen.

    • Standardmäßig ersetzt webpkgserver vorhandene <link rel="preload">-Tags durch die entsprechenden <link>-Tags, die zum Abrufen dieses Inhalts als SXG erforderlich sind. Dabei legt webpkgserver die Anweisungen allowed-alt-sxg und header-integrity nach Bedarf fest. HTML-Autoren müssen diese nicht manuell hinzufügen. Wenn Sie dieses Verhalten überschreiben und vorhandene Nicht-SXG-Vorabladevorgänge beibehalten möchten, ändern Sie #KeepNonSXGPreloads (default = false) in KeepNonSXGPreloads = true. Hinweis: Wenn du diese Option aktivierst, kann der SXG den Google-SXG-Cache gemäß diesen Anforderungen möglicherweise nicht verwenden.

  4. Starten Sie webpkgserver.

    ./webpkgserver

    Wenn der Server erfolgreich gestartet wurde, sollten Sie die folgenden Logmeldungen sehen: shell Listening at 127.0.0.1:8080 Successfully retrieved valid OCSP. Writing to cache in /private/tmp/webpkg

    Ihre Logeinträge sehen möglicherweise etwas anders aus. Insbesondere das Verzeichnis, das webpkgserver zum Speichern von Zertifikaten im Cache verwendet, variiert je nach Betriebssystem.

    Wenn diese Meldungen nicht angezeigt werden, prüfen Sie zuerst webpkgserver.toml noch einmal zur Fehlerbehebung.

    Wenn du webpkgserver.toml aktualisierst, musst du webpkgserver neu starten.

  5. Starten Sie Chrome mit dem folgenden Befehl: 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`

    Mit diesem Befehl wird Chrome angewiesen, die Zertifikatsfehler im Zusammenhang mit cert.pem zu ignorieren. So ist es möglich, SXGs mit einem Testzertifikat zu testen. Wenn Chrome ohne diesen Befehl gestartet wird, wird bei der Prüfung der SXG in den Entwicklertools der Fehler Certificate verification error: ERR_CERT_INVALID angezeigt.

    Hinweis:

    Möglicherweise müssen Sie diesen Befehl anpassen, um den Speicherort von Chrome auf Ihrem Computer und den Speicherort von cert.pem anzugeben. Wenn Sie dies richtig gemacht haben, sollte unter der Adressleiste eine Warnung angezeigt werden. Die Warnung sollte in etwa so aussehen: You are using an unsupported command-line flag: --ignore-certificate-errors-spki-list=9uxADcgc6/ho0mJLRMBcOjfBaN21k0sOInoMchr9CMY=.

    Wenn die Warnung keinen Hashstring enthält, haben Sie den Speicherort des SXG-Zertifikats nicht richtig angegeben.

  6. Öffne in den Entwicklertools den Tab Netzwerk und rufe dann die folgende URL auf: http://localhost:8080/priv/doc/https://example.com.

    Dadurch wird eine Anfrage an die webpackager-Instanz, die unter http://localhost:8080 ausgeführt wird, für einen SXG mit dem Inhalt von https://example.com gestellt. /priv/doc/ ist der von webpackager verwendete Standard-API-Endpunkt.

    Screenshot des DevTools-Tabs „Network“ (Netzwerk) mit einem SXG und dem zugehörigen Zertifikat

    Die folgenden Ressourcen werden auf dem Tab Network aufgeführt:

    • Eine Ressource vom Typ signed-exchange. Das ist der SXG.
    • Eine Ressource vom Typ cert-chain+cbor. Dies ist das SXG-Zertifikat. SXG-Zertifikate müssen das Format application/cert-chain+cbor haben.
    • Eine Ressource vom Typ document. Diese Inhalte wurden über SXG bereitgestellt.

    Wenn Sie diese Ressourcen nicht sehen, leeren Sie den Browser-Cache und laden Sie http://localhost:8080/priv/doc/https://example.com neu.

    Klicken Sie auf den Tab Vorschau, um weitere Informationen zu Signed Exchange und seiner Signatur zu erhalten.

    Screenshot des Tabs „Preview“, der einen SXG zeigt

Signed Exchange-Anzeigen mit einem CanSignHttpExchanges-Zertifikat bereitstellen

In diesem Abschnitt wird erläutert, wie SXGs mit einem CanSignHttpExchanges-Zertifikat bereitgestellt werden. Für die Verwendung von SXGs in der Produktion ist ein CanSignHttpExchanges-Zertifikat erforderlich.

Der Einfachheit halber wird bei dieser Anleitung davon ausgegangen, dass Sie die im Abschnitt Mit einem selbst signierten Zertifikat einrichten beschriebenen Konzepte verstehen.

Voraussetzungen

  • Sie haben ein CanSignHttpExchanges-Zertifikat. Auf dieser Seite sind die Zertifizierungsstellen aufgeführt, die diesen Zertifikattyp anbieten.

  • Wenn Sie kein Zertifikat haben, können Sie Ihren Webserver so konfigurieren, dass Zertifikate automatisch von Ihrer Zertifizierungsstelle abgerufen werden. Eine Anleitung für den Inhalt von webpkgserver.toml finden Sie auf dieser Seite.

  • Es ist zwar keine Voraussetzung, aber es wird dringend empfohlen, webpkgserver hinter einem Edge-Server auszuführen. Wenn Sie keinen Edge-Server verwenden, müssen Sie die Optionen TLS.PEMFile und TLS.KeyFile in webpkgserver.toml konfigurieren. Standardmäßig wird webpkgserver über HTTP ausgeführt. SXG-Zertifikate müssen jedoch über HTTPS bereitgestellt werden, damit sie vom Browser als gültig angesehen werden. Wenn du TLS.PEMFile und TLS.KeyFile konfigurierst, kann webpkgserver HTTPS verwenden und somit das SXG-Zertifikat direkt an den Browser senden.

Anleitung

  1. Erstellen Sie eine PEM-Datei, indem Sie das SXG-Zertifikat Ihrer Website gefolgt vom CA-Zertifikat Ihrer Website verketten. Weitere Informationen dazu finden Sie hier.

    Das Dateiformat PEM wird häufig als „Container“ zum Speichern mehrerer Zertifikate verwendet.

  2. Erstellen Sie eine neue webpkgsever.toml-Datei, indem Sie das Beispiel kopieren.

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

  3. Öffnen Sie webpkgserver.toml mit einem Editor Ihrer Wahl und nehmen Sie die folgenden Änderungen vor:

    • Ändern Sie die Zeile PEMFile = cert.pem so, dass sie den Speicherort der PEM-Datei mit Ihrer vollständigen Zertifikatskette angibt.
    • Ändern Sie die Zeile KeyFile = 'priv.key' entsprechend dem Speicherort des privaten Schlüssels, der Ihrer PEM-Datei entspricht.
    • Passen Sie die Zeile Domain = 'example.org' an Ihre Website an.
    • (Optional) Wenn webpkgserver das SXG-Zertifikat alle 90 Tage (45 Tage bei Google) automatisch verlängern soll, konfigurieren Sie die Optionen im Abschnitt [SXG.ACME] von webpkgserver.toml. Diese Option gilt nur für Websites, auf denen ein DigiCert- oder Google ACME-Konto eingerichtet ist.

  4. Konfigurieren Sie Ihren Edge-Server so, dass er Traffic an die Instanz webpkgserver weiterleitet.

    Es gibt zwei Haupttypen von Anfragen, die von webpkgserver verarbeitet werden: Anfragen für SXGs (die vom Endpunkt /priv/doc/ bereitgestellt werden) und Anfragen für das SXG-Zertifikat (die vom Endpunkt /webpkg/cert/ bereitgestellt werden). Die Regeln zum Umschreiben von URLs für jeden dieser Anfragetypen können leicht variieren. Weitere Informationen finden Sie unter Hinter dem Front-End-Edge-Server ausführen.

    Hinweis:

    Standardmäßig stellt webpkgserver das SXG-Zertifikat unter /webpkg/cert/$CERT_HASH bereit, z. B. /webpkg/cert/-0QmE0gvoedn92gtwI3s7On9zPevJGm5pn2RYhpZxgY. Führen Sie den folgenden Befehl aus, um $CERT_HASH zu generieren: shell openssl base64 -in cert.pem -d | openssl dgst -sha256 -binary | base64 | tr /+ _- | tr -d =