Signed Exchanges mit Web Packager einrichten

Informationen zum Bereitstellen von signierten Anzeigenplattformen (SXGs) mit Web Packager

Katie Hempenius
Katie Hempenius
X

Ein Signed Exchange (SXG) ist ein Übermittlungsmechanismus, mit dem der Ursprung einer Ressource unabhängig von der Art der Übermittlung authentifiziert werden kann. In der folgenden Anleitung wird beschrieben, wie Sie signierte Anzeigenplattformen mit dem Web Packager einrichten. Es gibt eine Anleitung für selbst signierte und CanSignHttpExchanges-Zertifikate.

SXGs mit einem selbst signierten Zertifikat bereitstellen

Die Verwendung eines selbstsignierten Zertifikats zum Bereitstellen von SXGs wird hauptsächlich zu Demonstrations- und Testzwecken verwendet. SXGs, die mit einem selbst signierten Zertifikat signiert sind, generieren Fehlermeldungen im Browser, wenn sie außerhalb von Testumgebungen verwendet werden. Sie sollten daher nicht an Crawler gesendet werden.

Vorbereitung

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 für signierte Austausche verwendet werden kann.

Anleitung

  1. Erstellen 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 Zertifikatssignierung (Certificate Signing Request, CSR).

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

    Eine Zertifikatsignaturanfrage ist ein Block codierten Texts, der die Informationen enthält, die zum Anfordern eines Zertifikats von einer Zertifizierungsstelle(CA) erforderlich sind. Auch wenn Sie kein Zertifikat von einer Zertifizierungsstelle anfordern, müssen Sie trotzdem eine Anfrage zur Zertifikatsignierung erstellen.

    Mit dem Befehl oben wird eine Anfrage zur Zertifikatsignierung für eine Organisation namens Web Packager Demo mit dem gemeinsamen Namen example.com erstellt. Der gemeinsame Name sollte der voll qualifizierte Domainname der Website sein, die die Inhalte enthält, die Sie als SXG-Datei verpacken möchten.

    Bei einer SXG-Produktionsumgebung ist dies eine Website, deren Inhaber Sie sind. In einer Testumgebung wie der in dieser Anleitung beschriebenen kann es sich jedoch um jede Website 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")

    Mit diesem Befehl werden die in Schritt 1 und 2 erstellten privaten Schlüssel und CSR verwendet, um die Zertifikatdatei 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 CanSignHttpExchanges-Erweiterung. Außerdem definiert das Flag -extfile example.com als alternativen Antragstellernamen.

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

    openssl x509 -in cert.pem -noout -text

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

Web Packager-Server für Tests einrichten

Vorbereitung

  1. Installieren Sie Web Packager.

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

  2. Erstellen Sie webpkgserver.

    cd webpackager/cmd/webpkgserver
go build .

    webpkgserver ist ein bestimmtes Binary im Web Packager-Projekt.

  3. Prüfen Sie, ob webpkgserver korrekt installiert wurde.

    ./webpkgserver --help

    Dieser Befehl sollte Informationen zur Verwendung von webpkgserver zurückgeben. Wenn das nicht funktioniert, sollten Sie als Erstes prüfen, ob Ihr GOPATH richtig konfiguriert ist.

Anleitung

  1. Rufen Sie das Verzeichnis webpkgserver auf. Möglicherweise befinden Sie sich bereits in diesem Verzeichnis.

    cd /path/to/cmd/webpkgserver

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

    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' in den Pfad zum von Ihnen erstellten PEM-Zertifikat cert.pem. Ändern Sie die Zeile mit TLS.PEMFile nicht. Dies ist eine andere Konfigurationsoption.
    • Ändern Sie die Zeile KeyFile = 'priv.key' so, dass sie den Pfad zum von Ihnen erstellten privaten Schlüssel priv.key widerspiegelt. Ändern Sie die Zeile, in der TLS.KeyFile erwähnt wird, nicht. Dies ist eine andere Konfigurationsoption.
    • Ändern Sie die Zeile #CertURLBase = '/webpkg/cert' in CertURLBase = 'data:'. CertURLBase gibt den Bereitstellungsort des SXG-Zertifikats an. Anhand dieser Informationen wird der Parameter cert-url im Header Signature der 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 bequemste Methode, das SXG-Zertifikat bereitzustellen.
    • Ändern Sie die Zeile Domain = 'example.org' so, dass sie die Domain enthält, für die Sie ein Zertifikat erstellt haben. Wenn Sie die Anleitung in diesem Artikel genau befolgt haben, sollte dies zu example.com geändert werden. webpkgserver ruft nur Inhalte von der mit webpkgserver.toml angegebenen Domain ab. Wenn Sie versuchen, Seiten aus einer anderen Domain abzurufen, ohne webpkgserver.toml zu aktualisieren, wird in den webpkgserver-Protokollen die Fehlermeldung URL doesn't match the fetch targets angezeigt.

    Optional

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

    • Wenn webpkgserver Anweisungen zum Vorladen von Stylesheet- und Script-Unterressourcen als SXGs einfügen soll, ändern Sie die Zeile #PreloadCSS = false in PreloadCSS = true. Ändern Sie außerdem die Zeile #PreloadJS = false in PreloadJS = true.

      Alternativ können Sie Link: rel="preload"-Header und <link rel="preload">-Tags manuell in die HTML-Seite einfügen.

    • Standardmäßig ersetzt webpkgserver vorhandene <link rel="preload">-Tags durch die entsprechenden <link>-Tags, die zum Abrufen dieser Inhalte 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-Preloads beibehalten möchten, ändern Sie #KeepNonSXGPreloads (default = false) in KeepNonSXGPreloads = true. Wenn du diese Option aktivierst, kann es sein, dass das SXG gemäß diesen Anforderungen nicht für den Google SXG-Cache infrage kommt.

  4. Starten Sie webpkgserver.

    ./webpkgserver

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

    Ihre Protokollmeldungen können leicht abweichen. Insbesondere das Verzeichnis, in dem webpkgserver Zertifikate im Cache speichert, variiert je nach Betriebssystem.

    Wenn diese Meldungen nicht angezeigt werden, sollten Sie als Erstes webpkgserver.toml prüfen.

    Wenn Sie webpkgserver.toml aktualisieren, sollten Sie 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 mit cert.pem verknüpften Zertifikatsfehler zu ignorieren. So können SXGs mit einem Testzertifikat getestet werden. Wenn Chrome ohne diesen Befehl gestartet wird, wird bei der Prüfung der SXG in den DevTools der Fehler Certificate verification error: ERR_CERT_INVALID angezeigt.

    Hinweis:

    Möglicherweise müssen Sie diesen Befehl anpassen, damit er den Speicherort von Chrome auf Ihrem Computer und den Speicherort von cert.pem widerspiegelt. Wenn Sie alles 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 Hash-String enthält, haben Sie den Speicherort des SXG-Zertifikats nicht korrekt angegeben.

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

    Dadurch wird eine Anfrage an die webpackager-Instanz unter http://localhost:8080 für ein SXG gesendet, das den Inhalt von https://example.com enthält. /priv/doc/ ist der Standard-API-Endpunkt, der von webpackager verwendet wird.

    Screenshot des Tabs „Netzwerk“ in den DevTools mit einem SXG und seinem Zertifikat

    Auf dem Tab Netzwerk sind die folgenden Ressourcen aufgeführt:

    • Eine Ressource vom Typ signed-exchange. Das ist das SXG.
    • Eine Ressource vom Typ cert-chain+cbor. Das ist das SXG-Zertifikat. SXG-Zertifikate müssen das Format application/cert-chain+cbor haben.
    • Eine Ressource vom Typ document. Das sind die Inhalte, die über SXG gesendet wurden.

    Wenn du diese Ressourcen nicht siehst, leere den Browsercache und lade http://localhost:8080/priv/doc/https://example.com dann neu.

    Klicken Sie auf den Tab Vorschau, um weitere Informationen zum signierten Austausch und seiner Signatur zu erhalten.

    Screenshot des Tabs „Vorschau“ mit einem SXG

Signed Exchanges mit einem CanSignHttpExchanges-Zertifikat bereitstellen

In diesem Abschnitt wird beschrieben, wie Sie SXGs mit einem CanSignHttpExchanges-Zertifikat bereitstellen. Für die Produktionsnutzung von SXGs ist ein CanSignHttpExchanges-Zertifikat erforderlich.

Der Kürze halber wird in dieser Anleitung davon ausgegangen, dass Sie die im Abschnitt Unterzeichnete Exchanges mit einem selbst signierten Zertifikat einrichten beschriebenen Konzepte kennen.

Vorbereitung

  • Sie haben ein CanSignHttpExchanges-Zertifikat. Auf dieser Seite sind die Zertifizierungsstellen aufgeführt, die diese Art von Zertifikat anbieten.

  • Wenn Sie kein Zertifikat haben, können Sie Ihren Webpkg-Server so konfigurieren, dass er Zertifikate automatisch von Ihrer Zertifizierungsstelle abholt. Eine Anleitung dazu, was in webpkgserver.toml gehört, findest du auf dieser Seite.

  • Es ist zwar keine Voraussetzung, aber wir empfehlen dringend, 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 eingestuft werden. Wenn Sie TLS.PEMFile und TLS.KeyFile konfigurieren, kann webpkgserver HTTPS verwenden und das SXG-Zertifikat daher direkt an den Browser senden.

Anleitung

  1. Erstellen Sie eine PEM-Datei, indem Sie das SXG-Zertifikat Ihrer Website mit dem CA-Zertifikat Ihrer Website verketten. Weitere Informationen dazu

    PEM ist ein Dateiformat, das häufig als „Container“ zum Speichern mehrerer Zertifikate verwendet wird.

  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 der Speicherort der PEM-Datei mit der vollständigen Zertifikatskette angegeben ist.
    • Ändern Sie die Zeile KeyFile = 'priv.key' so, dass der Speicherort des privaten Schlüssels Ihrer PEM-Datei angegeben ist.
    • Passen Sie die Zeile Domain = 'example.org' an Ihre Website an.
    • Optional: Wenn webpkgserver das SXG-Zertifikat alle 90 Tage (45 Tage für Google) automatisch verlängern soll, konfigurieren Sie die Optionen im Bereich [SXG.ACME] von webpkgserver.toml. Diese Option gilt nur für Websites mit einem eingerichteten DigiCert- oder Google ACME-Konto.

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

    Es gibt zwei Haupttypen von Anfragen, die von webpkgserver verarbeitet werden: Anfragen für SXGs (die über den /priv/doc/-Endpunkt bereitgestellt werden) und Anfragen für das SXG-Zertifikat (die über den /webpkg/cert/-Endpunkt bereitgestellt werden). Die Regeln für die URL-Weiterleitung für jeden dieser Anfragetypen unterscheiden sich geringfügig. Weitere Informationen finden Sie unter Hinter einem Front-End-Edge-Server ausführen.

    Hinweis:

    Standardmäßig stellt webpkgserver das SXG-Zertifikat unter /webpkg/cert/$CERT_HASH bereit, z. B. unter /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 =