Découvrez comment diffuser des échanges signés (SXG) à l'aide de Web Packager.
Un échange signé (SXG) est un mécanisme de diffusion qui permet d'authentifier l'origine d'une ressource indépendamment de la manière dont elle a été diffusée.
Les instructions suivantes expliquent comment configurer des échanges signés à l'aide de Web Packager. Des instructions sont fournies pour les certificats autosignés et CanSignHttpExchanges
.
Diffuser des SXG à l'aide d'un certificat autosigné
L'utilisation d'un certificat autosigné pour diffuser des SXG est principalement utilisée à des fins de démonstration et de test. Les SXG signés avec un certificat autosigné génèrent des messages d'erreur dans le navigateur lorsqu'ils sont utilisés en dehors des environnements de test et ne doivent pas être diffusés auprès des robots d'exploration.
Prérequis
Pour suivre ces instructions, vous devez avoir installé openssl et Go dans votre environnement de développement.
Générer un certificat autosigné
Cette section explique comment générer un certificat autosigné pouvant être utilisé avec des échanges signés.
Instructions
Générez une clé privée.
openssl ecparam -out priv.key -name prime256v1 -genkey
La clé privée sera enregistrée sous le nom de fichier
priv.key
.Créez une requête de signature de certificat (CSR).
openssl req -new -sha256 -key priv.key -out cert.csr -subj '/O=Web Packager Demo/CN=example.com'
Une requête de signature de certificat est un bloc de texte encodé qui transmet les informations nécessaires pour demander un certificat à une autorité de certification(CA). Bien que vous ne demandiez pas de certificat à une autorité de certification, vous devez tout de même créer une demande de signature de certificat.
La commande ci-dessus crée une requête de signature de certificat pour une organisation nommée
Web Packager Demo
avec le nom communexample.com
. Le nom commun doit correspondre au nom de domaine complet du site contenant le contenu que vous souhaitez empaqueter en tant que SXG.Dans une configuration SXG de production, il s'agit d'un site dont vous êtes propriétaire. Toutefois, dans un environnement de test comme celui décrit dans ces instructions, il peut s'agir de n'importe quel site.
Créez un certificat avec l'extension
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")
Cette commande utilise la clé privée et la CSR créées aux étapes 1 et 2 pour créer le fichier de certificat
cert.pem
. L'indicateur-extfile
associe le certificat à l'extension de certificatCanSignHttpExchanges
(1.3.6.1.4.1.11129.2.1.22
est l'identifiant de l'objet pour l'extensionCanSignHttpExchanges
). De plus, l'option-extfile
définit égalementexample.com
comme nom alternatif du sujet.Si vous souhaitez connaître le contenu de
cert.pem
, vous pouvez l'afficher à l'aide de la commande suivante:openssl x509 -in cert.pem -noout -text
Vous avez terminé de créer des clés privées et des certificats. Vous aurez besoin des fichiers
priv.key
etcert.pem
dans la section suivante.
Configurer le serveur Web Packager pour les tests
Prérequis
Installez Web Packager.
git clone https://github.com/google/webpackager.git
Créez
webpkgserver
.cd webpackager/cmd/webpkgserver go build .
webpkgserver
est un binaire spécifique du projet Web Packager.Vérifiez que
webpkgserver
a été correctement installé../webpkgserver --help
Cette commande doit renvoyer des informations sur l'utilisation de
webpkgserver
. Si cela ne fonctionne pas, la première étape de dépannage consiste à vérifier que votre GOPATH est correctement configuré.
Instructions
Accédez au répertoire
webpkgserver
(vous vous y trouvez peut-être déjà).cd /path/to/cmd/webpkgserver
Créez un fichier
webpkgsever.toml
en copiant l'exemple.cp ./webpkgserver.example.toml ./webpkgserver.toml
Ce fichier contient les options de configuration pour
webpkgserver
.Ouvrez
webpkgserver.toml
avec l'éditeur de votre choix et apportez les modifications suivantes:- Remplacez la ligne
#AllowTestCert = false
parAllowTestCert = true
. - Modifiez la ligne
PEMFile = 'path/to/your.pem'
pour refléter le chemin d'accès au certificat PEM,cert.pem
, que vous avez créé. Ne modifiez pas la ligne mentionnantTLS.PEMFile
. Il s'agit d'une autre option de configuration. - Modifiez la ligne
KeyFile = 'priv.key'
pour refléter le chemin d'accès de la clé privée,priv.key
, que vous avez créée. Ne modifiez pas la ligne mentionnantTLS.KeyFile
. Il s'agit d'une autre option de configuration. - Remplacez la ligne
#CertURLBase = '/webpkg/cert'
parCertURLBase = 'data:'
.CertURLBase
indique l'emplacement de diffusion du certificat SXG. Ces informations permettent de définir le paramètrecert-url
dans l'en-têteSignature
de l'élément SXG. Dans les environnements de production,CertURLBase
est utilisé comme suit:CertURLBase = 'https://mysite.com/'
. Toutefois, pour les tests locaux,CertURLBase = 'data:'
peut être utilisé pour demander àwebpkgserver
d'utiliser une URL de données pour intégrer le certificat dans le champcert-url
. Pour les tests locaux, il s'agit du moyen le plus pratique de diffuser le certificat SXG. - Modifiez la ligne
Domain = 'example.org'
pour refléter le domaine pour lequel vous avez créé un certificat. Si vous avez suivi à la lettre les instructions de cet article, ce paramètre doit être remplacé parexample.com
.webpkgserver
n'extrait que le contenu du domaine indiqué parwebpkgserver.toml
. Si vous essayez d'extraire des pages à partir d'un autre domaine sans mettre à jourwebpkgserver.toml
, le message d'erreurURL doesn't match the fetch targets
s'affiche dans les journauxwebpkgserver
.
Optional
Si vous souhaitez activer ou désactiver le préchargement des sous-ressources, les options de configuration
webpkgserver.toml
suivantes sont pertinentes:Pour que
webpkgserver
insère des directives de préchargement des sous-ressources de feuille de style et de script en tant que SXG, remplacez la ligne#PreloadCSS = false
parPreloadCSS = true
. Remplacez également la ligne#PreloadJS = false
parPreloadJS = true
.Au lieu d'utiliser cette option de configuration, vous pouvez ajouter manuellement des en-têtes
Link: rel="preload"
et des balises<link rel="preload">
au code HTML d'une page.Par défaut,
webpkgserver
remplace les balises<link rel="preload">
existantes par les balises<link>
équivalentes nécessaires pour extraire ce contenu au format SXG.webpkgserver
définira les directivesallowed-alt-sxg
etheader-integrity
si nécessaire. Les auteurs HTML n'ont pas besoin de les ajouter manuellement. Pour remplacer ce comportement et conserver les préchargements non-SXG existants, remplacez#KeepNonSXGPreloads (default = false)
parKeepNonSXGPreloads = true
. N'oubliez pas que l'activation de cette option peut rendre l'échange signé inéligible au cache d'échanges signés Google, conformément à ces exigences.
- Remplacez la ligne
Démarrez
webpkgserver
../webpkgserver
Si le serveur a démarré correctement, les messages de journal suivants doivent s'afficher :
shell Listening at 127.0.0.1:8080 Successfully retrieved valid OCSP. Writing to cache in /private/tmp/webpkg
Vos messages de journal peuvent être légèrement différents. En particulier, le répertoire que
webpkgserver
utilise pour mettre en cache les certificats varie selon le système d'exploitation.Si vous ne voyez pas ces messages, la première étape de dépannage consiste à vérifier
webpkgserver.toml
.Si vous mettez à jour
webpkgserver.toml
, vous devez redémarrerwebpkgserver
.Lancez Chrome à l'aide de la commande suivante :
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`
Cette commande indique à Chrome d'ignorer les erreurs de certificat associées à
cert.pem
. Cela permet de tester les SXG à l'aide d'un certificat de test. Si Chrome est lancé sans cette commande, l'inspection de l'élément SXG dans DevTools affiche l'erreurCertificate verification error: ERR_CERT_INVALID
.Remarque :
Vous devrez peut-être ajuster cette commande pour refléter l'emplacement de Chrome sur votre ordinateur, ainsi que l'emplacement de
cert.pem
. Si vous avez correctement effectué cette opération, un avertissement s'affiche sous la barre d'adresse. L'avertissement devrait ressembler à ceci:You are using an unsupported command-line flag: --ignore-certificate-errors-spki-list=9uxADcgc6/ho0mJLRMBcOjfBaN21k0sOInoMchr9CMY=.
Si l'avertissement n'inclut pas de chaîne de hachage, vous n'avez pas indiqué correctement l'emplacement du certificat SXG.
Ouvrez l'onglet Network (Réseau) des outils pour les développeurs, puis accédez à l'URL suivante :
http://localhost:8080/priv/doc/https://example.com
.Une requête est envoyée à l'instance
webpackager
exécutée àhttp://localhost:8080
pour une SXG contenant le contenu dehttps://example.com
./priv/doc/
est le point de terminaison de l'API par défaut utilisé parwebpackager
.Les ressources suivantes sont listées dans l'onglet Network (Réseau) :
- Ressource de type
signed-exchange
. Il s'agit de l'échange signé. - Ressource de type
cert-chain+cbor
. Il s'agit du certificat SXG. Les certificats SXG doivent utiliser le formatapplication/cert-chain+cbor
. - Ressource de type
document
. Il s'agit du contenu diffusé via SXG.
Si vous ne voyez pas ces ressources, essayez de vider le cache du navigateur, puis de recharger
http://localhost:8080/priv/doc/https://example.com
.Cliquez sur l'onglet Aperçu pour en savoir plus sur l'échange signé et sa signature.
- Ressource de type
Diffuser des échanges signés à l'aide d'un certificat CanSignHttpExchanges
Les instructions de cette section expliquent comment diffuser des SXG à l'aide d'un certificat CanSignHttpExchanges
. L'utilisation en production des SXG nécessite un certificat CanSignHttpExchanges
.
Par souci de concision, nous partons du principe que vous comprenez les concepts abordés dans la section Configurer des échanges signés à l'aide d'un certificat autosigné.
Prérequis
Vous disposez d'un certificat
CanSignHttpExchanges
. Cette page répertorie les autorités de certification qui proposent ce type de certificat.Si vous ne disposez pas de certificat, vous pouvez configurer votre webpkgserver pour qu'il récupère automatiquement les certificats auprès de votre autorité de certification. Vous pouvez suivre les instructions concernant ce qui doit être ajouté à
webpkgserver.toml
sur cette page.Bien que cela ne soit pas obligatoire, il est vivement recommandé d'exécuter
webpkgserver
derrière un serveur de bordure. Si vous n'utilisez pas de serveur de bord, vous devez configurer les optionsTLS.PEMFile
etTLS.KeyFile
danswebpkgserver.toml
. Par défaut,webpkgserver
s'exécute via HTTP. Toutefois, les certificats SXG doivent être diffusés via HTTPS pour être considérés comme valides par le navigateur. La configuration deTLS.PEMFile
et deTLS.KeyFile
permet àwebpkgserver
d'utiliser HTTPS et donc de diffuser le certificat SXG directement dans le navigateur.
Instructions
Créez un fichier PEM en concatenant le certificat SXG de votre site, suivi du certificat CA de votre site. Pour en savoir plus, cliquez ici.
PEM est un format de fichier couramment utilisé comme "conteneur" pour stocker plusieurs certificats.
Créez un nouveau fichier
webpkgsever.toml
en copiant l'exemple.cp ./webpkgserver.example.toml ./webpkgserver.toml
Ouvrez
webpkgserver.toml
avec l'éditeur de votre choix et apportez les modifications suivantes:- Modifiez la ligne
PEMFile = cert.pem
pour refléter l'emplacement du fichier PEM contenant votre chaîne de certificats complète. - Modifiez la ligne
KeyFile = 'priv.key'
pour refléter l'emplacement de la clé privée correspondant à votre fichier PEM. - Modifiez la ligne
Domain = 'example.org'
pour qu'elle reflète votre site. - (Facultatif) Pour que
webpkgserver
renouvelle automatiquement le certificat SXG tous les 90 jours (45 jours pour Google), configurez les options de la section[SXG.ACME]
dewebpkgserver.toml
. Cette option ne s'applique qu'aux sites pour lesquels un compte DigiCert ou Google ACME est configuré.
- Modifiez la ligne
Configurez votre serveur Edge pour transférer le trafic vers l'instance
webpkgserver
.webpkgserver
gère deux principaux types de requêtes: les requêtes pour les SXG (qui sont gérées par le point de terminaison/priv/doc/
) et les requêtes pour le certificat SXG (qui sont gérées par le point de terminaison/webpkg/cert/
). Les règles de réécriture d'URL pour chacun de ces types de requêtes varient légèrement. Pour en savoir plus, consultez la section Exécuter derrière le serveur de bord de l'interface utilisateur.Remarque :
Par défaut,
webpkgserver
diffuse le certificat SXG sur/webpkg/cert/$CERT_HASH
(par exemple,/webpkg/cert/-0QmE0gvoedn92gtwI3s7On9zPevJGm5pn2RYhpZxgY
). Pour générer$CERT_HASH
, exécutez la commande suivante :shell openssl base64 -in cert.pem -d | openssl dgst -sha256 -binary | base64 | tr /+ _- | tr -d =