Informationen zum Bereitstellen von signierten Anzeigenplattformen (SXGs) mit Web Packager
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
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.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 Namenexample.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-Produktionskonfiguration 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.
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 ZertifikatserweiterungCanSignHttpExchanges
.1.3.6.1.4.1.11129.2.1.22
ist die Objekt-ID für dieCanSignHttpExchanges
-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
undcert.pem
im nächsten Abschnitt.
Web Packager-Server für Tests einrichten
Vorbereitung
Installieren Sie Web Packager.
git clone https://github.com/google/webpackager.git
Erstellen Sie
webpkgserver
.cd webpackager/cmd/webpkgserver go build .
webpkgserver
ist ein bestimmtes Binary im Web Packager-Projekt.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
Rufen Sie das Verzeichnis
webpkgserver
auf. Möglicherweise befinden Sie sich bereits in diesem Verzeichnis.cd /path/to/cmd/webpkgserver
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
.Öffnen Sie
webpkgserver.toml
mit einem Editor Ihrer Wahl und nehmen Sie die folgenden Änderungen vor:- Ändern Sie die Zeile
#AllowTestCert = false
inAllowTestCert = true
. - Ändern Sie die Zeile
PEMFile = 'path/to/your.pem'
in den Pfad zum von Ihnen erstellten PEM-Zertifikatcert.pem
. Ändern Sie die Zeile mitTLS.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üsselpriv.key
widerspiegelt. Ändern Sie die Zeile, in derTLS.KeyFile
erwähnt wird, nicht. Dies ist eine andere Konfigurationsoption. - Ändern Sie die Zeile
#CertURLBase = '/webpkg/cert'
inCertURLBase = 'data:'
.CertURLBase
gibt den Bereitstellungsort des SXG-Zertifikats an. Anhand dieser Informationen wird der Parametercert-url
im HeaderSignature
der SXG festgelegt. In Produktionsumgebungen wirdCertURLBase
so verwendet:CertURLBase = 'https://mysite.com/'
. Für lokale Tests kannCertURLBase = 'data:'
jedoch verwendet werden, umwebpkgserver
anzuweisen, eine Daten-URL zu verwenden, um das Zertifikat im Feldcert-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 zuexample.com
geändert werden.webpkgserver
ruft nur Inhalte von der mitwebpkgserver.toml
angegebenen Domain ab. Wenn Sie versuchen, Seiten aus einer anderen Domain abzurufen, ohnewebpkgserver.toml
zu aktualisieren, wird in denwebpkgserver
-Protokollen die FehlermeldungURL 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
inPreloadCSS = true
. Ändern Sie außerdem die Zeile#PreloadJS = false
inPreloadJS = true
.Alternativ können Sie
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 dieser Inhalte als SXG erforderlich sind. Dabei legtwebpkgserver
die Anweisungenallowed-alt-sxg
undheader-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)
inKeepNonSXGPreloads = true
. Wenn du diese Option aktivierst, kann es sein, dass das SXG gemäß diesen Anforderungen nicht für den Google SXG-Cache infrage kommt.
- Ändern Sie die Zeile
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 Siewebpkgserver
neu starten.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 FehlerCertificate 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.
Ö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 unterhttp://localhost:8080
für ein SXG gesendet, das den Inhalt vonhttps://example.com
enthält./priv/doc/
ist der Standard-API-Endpunkt, der vonwebpackager
verwendet wird.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 Formatapplication/cert-chain+cbor
verwenden. - 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.
- Eine Ressource vom Typ
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 OptionenTLS.PEMFile
undTLS.KeyFile
inwebpkgserver.toml
konfigurieren. Standardmäßig wirdwebpkgserver
über HTTP ausgeführt. SXG-Zertifikate müssen jedoch über HTTPS bereitgestellt werden, damit sie vom Browser als gültig eingestuft werden. Wenn SieTLS.PEMFile
undTLS.KeyFile
konfigurieren, kannwebpkgserver
HTTPS verwenden und das SXG-Zertifikat direkt an den Browser senden.
Anleitung
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.
Erstellen Sie eine neue
webpkgsever.toml
-Datei, indem Sie das Beispiel kopieren.cp ./webpkgserver.example.toml ./webpkgserver.toml
Ö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]
vonwebpkgserver.toml
. Diese Option gilt nur für Websites mit einem eingerichteten DigiCert- oder Google ACME-Konto.
- Ändern Sie die Zeile
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 =