Configurer des échanges signés à l'aide de Web Packager

Découvrez comment diffuser des échanges signés (SXG) à l'aide de Web Packager.

Katie Hempenius
Katie Hempenius
X

Un échange signé (SXG) est un mécanisme de distribution possible d'authentifier l'origine d'une ressource indépendamment de la manière dont elle a été livrée. Les instructions suivantes expliquent comment configurer les échanges signés à l'aide de Web Packager : Les instructions sont incluses pour les certificats autosignés et les certificats CanSignHttpExchanges.

Livrer des échanges signés à l'aide d'un certificat autosigné

L'utilisation d'un certificat autosigné pour la diffusion d'échanges signés est principalement utilisée pour à des fins de démonstration et de test. SXG signés avec un certificat autosigné génère des messages d'erreur dans le navigateur en dehors des tests et ne doivent pas être diffusées auprès des robots d'exploration.

Prérequis

Pour suivre ces instructions, vous devez openssl et Go doit être installé 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ée avec les échanges signés.

Instructions

  1. Générez une clé privée.

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

    La clé privée sera enregistrée dans un fichier nommé priv.key.

  2. Créer une signature de certificat de requête (CSR).

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

    Une demande de signature de certificat est un bloc de texte encodé qui transmet les informations nécessaires pour demander un certificat auprès d'une autorité de certification. Même si vous ne demanderez pas de certificat autorité de certification, vous devez toujours 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é Web Packager Demo, qui possède le commun nom example.com. La le nom commun doit être le nom de domaine complet du site qui contient le contenu que vous souhaitez empaqueter en tant qu'échange signé.

    Dans une configuration SXG de production, vous êtes propriétaire du site. Toutefois, dans un environnement de test tel que celui décrit dans ces instructions, il peut s'agir de n'importe quel sur votre site.

  3. Créez un certificat comportant 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 requête de signature de certificat créées aux étapes 1 et 2 pour créer la fichier de certificat cert.pem. L'option -extfile associe le certificat à l'extension de certificat CanSignHttpExchanges (1.3.6.1.4.1.11129.2.1.22 est l'objet identifiant pour l'extension CanSignHttpExchanges). De plus, l'option -extfile définit example.com comme alternative à l'objet Nom.

    Si vous êtes curieux de connaître le contenu de cert.pem, vous pouvez l'afficher à l'aide de la commande 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 du priv.key et cert.pem dans la section suivante.

Configurer le serveur Web Packager pour les tests

Prérequis

  1. Installez Web Packager.

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

  2. Créez webpkgserver.

    cd webpackager/cmd/webpkgserver
go build .

    webpkgserver est un binaire spécifique du projet Web Packager.

  3. Vérifiez que webpkgserver a été installé correctement.

    ./webpkgserver --help

    Cette commande doit renvoyer des informations sur l'utilisation de webpkgserver. Si cela ne fonctionne pas, commencez par vérifier que votre GOPATH est configuré correctement.

Instructions

  1. Accédez au répertoire webpkgserver (vous vous trouvez peut-être déjà dans ce du répertoire d'utilisateurs).

    cd /path/to/cmd/webpkgserver

  2. 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.

  3. Ouvrez webpkgserver.toml avec l'éditeur de votre choix et effectuez les opérations suivantes : modifications:

    • Remplacez la ligne #AllowTestCert = false par AllowTestCert = true.
    • Modifiez la ligne PEMFile = 'path/to/your.pem' pour refléter le chemin d'accès vers le certificat PEM, cert.pem, que vous avez créé. Ne modifiez pas ligne mentionnant TLS.PEMFile : il s'agit d'une option de configuration différente.
    • Modifiez la ligne KeyFile = 'priv.key' pour refléter le chemin d'accès la clé privée priv.key que vous avez créée. Ne pas modifier la ligne mentionnant TLS.KeyFile : il s'agit d'une option de configuration différente.
    • Remplacez la ligne #CertURLBase = '/webpkg/cert' par CertURLBase = 'data:'. CertURLBase indique l'emplacement de diffusion de l'échange signé. certificat. Ces informations permettent de définir le paramètre cert-url dans la Signature de l'échange signé. Dans les environnements de production, CertURLBase est utilisé. comme ceci: CertURLBase = 'https://mysite.com/'. Toutefois, pour les requêtes locales, test, CertURLBase = 'data:' peut être utilisé pour indiquer à webpkgserver pour utiliser des données URL pour intégrer le certificat dans le champ cert-url. Pour les tests en local, c’est la façon la plus pratique de servir le certificat SXG.
    • Modifiez la ligne Domain = 'example.org' afin d'indiquer le domaine pour lequel pour lequel vous avez créé un certificat. Si vous avez suivi les instructions de ce l'article tel quel, il doit être remplacé par example.com. webpkgserver ne récupérera que le contenu du domaine indiqué par webpkgserver.toml Si vous essayez d'extraire des pages d'un autre domaine sans mettre à jour webpkgserver.toml, les journaux webpkgserver afficheront le message d'erreur URL doesn't match the fetch targets.

    Optional

    Si vous souhaitez activer ou désactiver les sous-ressources le préchargement, les options de configuration webpkgserver.toml suivantes sont pertinentes:

    • webpkgserver peut insérer des directives pour le préchargement de la feuille de style. et les sous-ressources de script en tant qu'échanges signés, remplacez la ligne #PreloadCSS = false à PreloadCSS = true. Remplacez également la ligne #PreloadJS = false par PreloadJS = true.

      Au lieu d'utiliser cette option de configuration, vous pouvez manuellement ajouter des en-têtes Link: rel="preload" et des balises <link rel="preload"> à une dans le code HTML de la page.

    • Par défaut, webpkgserver remplace les balises <link rel="preload"> existantes avec les balises <link> équivalentes nécessaires pour récupérer ce contenu en tant que Échanges signés Ainsi, webpkgserver définit la allowed-alt-sxg et header-integrity directives selon les besoins : les auteurs HTML n'ont pas besoin de les ajouter manuellement. À ignorer ce comportement et conserver les préchargements non-SXG existants, De #KeepNonSXGPreloads (default = false) à KeepNonSXGPreloads = true. Notez que l'activation de cette option peut rendre l'échange signé le cache d'échanges signés Google exigences.

  4. 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 utilisé par webpkgserver pour mettre en cache les certificats varie selon le système d'exploitation.

    Si vous ne voyez pas ces messages, commencez par résoudre le problème l'étape suivante consiste à vérifier webpkgserver.toml.

    Si vous mettez à jour webpkgserver.toml, vous devez redémarrer webpkgserver.

  5. 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 avec cert.pem. Cela permet de tester les échanges signés certificat. Si Chrome est lancé sans cette commande, l'inspection de l'échange signé dans les outils de développement affichera l'erreur Certificate verification error: ERR_CERT_INVALID.

    Remarque :

    Vous devrez peut-être modifier cette commande pour qu'elle indique l'emplacement de Chrome sur votre machine, ainsi que l'emplacement de cert.pem. Si vous l'avez déjà fait correctement, un avertissement doit s'afficher sous la barre d'adresse. La doit 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 correctement indiqué l'emplacement du certificat SXG.

  6. Ouvrez l'onglet Network (Réseau) des outils de développement, puis accédez à l'URL suivante: http://localhost:8080/priv/doc/https://example.com

    Une requête est alors envoyée à l'instance webpackager qui s'exécute à l'adresse http://localhost:8080 pour un échange signé avec le contenu d'un https://example.com /priv/doc/ est le point de terminaison d'API par défaut utilisé par webpackager

    Capture d&#39;écran de l&#39;onglet DevTools Network montrant un échange signé et son certificat.

    Les ressources suivantes sont répertoriées dans l'onglet Network (Réseau) :

    • Une ressource de type signed-exchange Il s'agit de l'échange signé.
    • Une ressource de type cert-chain+cbor Il s'agit du certificat SXG. Les certificats SXG doivent utiliser le format application/cert-chain+cbor.
    • Une ressource de type document Il s'agit du contenu qui a été envoyé via SXG.

    Si vous ne voyez pas ces ressources, videz le cache du navigateur, puis actualisation de 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.

    Capture d&#39;écran de l&#39;onglet &quot;Preview&quot; (Aperçu) montrant un échange signé

Diffuser des échanges signés à l'aide d'un certificat CanSignHttpExchanges

Les instructions de cette section expliquent comment diffuser des échanges signés à l'aide d'un CanSignHttpExchanges certificat. L'utilisation en production d'échanges signés CanSignHttpExchanges certificat.

Par souci de concision, ces instructions sont rédigées en partant du principe que vous comprenez les concepts abordés dans l'article Configurer des échanges signés à l'aide d'un modèle auto-signé certificat .

Prérequis

  • Vous disposez d'un certificat CanSignHttpExchanges. Ce répertorie les autorités de certification qui offrent ce type de certificat.

  • Si vous n'avez pas de certificat, vous pouvez configurer votre serveur webpkgserver pour automatiquement les certificats auprès de votre autorité de certification. Vous pouvez suivre les itinéraire pour trouver un itinéraire à webpkgserver.toml dans cette page.

  • Bien que cela ne soit pas obligatoire, il est fortement recommandé d'exécuter webpkgserver derrière un serveur Edge. Si vous n'utilisez pas de serveur en périphérie, devra configurer les options TLS.PEMFile et TLS.KeyFile dans webpkgserver.toml Par défaut, webpkgserver s'exécute via HTTP. En revanche, doivent être transmis via HTTPS pour être considérés comme valides par le navigateur. Si vous configurez TLS.PEMFile et TLS.KeyFile, webpkgserver peut utiliser HTTPS et fournit donc le certificat SXG directement au navigateur.

Instructions

  1. Créez un fichier PEM en concaténant le certificat SXG de votre site suivi de le certificat CA de votre site. Vous trouverez des instructions supplémentaires à ce sujet cliquez ici.

    La valeur PEM est format de fichier couramment utilisé comme "conteneur" permettant de stocker plusieurs certificats.

  2. Créez un nouveau fichier webpkgsever.toml en copiant l'exemple.

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

  3. Ouvrez webpkgserver.toml avec l'éditeur de votre choix et effectuez modifications suivantes:

    • Modifiez la ligne PEMFile = cert.pem pour indiquer l'emplacement du fichier PEM. contenant votre chaîne complète de certificats.
    • Modifiez la ligne KeyFile = 'priv.key' pour refléter l'emplacement correspondant à votre fichier PEM.
    • Modifiez la ligne Domain = 'example.org' pour refléter votre site.
    • (Facultatif) Faire en sorte que webpkgserver renouvelle automatiquement le certificat SXG tous les 90 jours (45 jours pour Google), configurez les options dans la section [SXG.ACME] de webpkgserver.toml Cette option ne s'applique qu'aux sites disposant d'un certificat ou Google ACME.

  4. Configurez votre serveur en périphérie pour transférer le trafic vers webpkgserver Compute Engine.

    Il existe deux principaux types de requêtes traitées par webpkgserver: les requêtes pour les échanges signés (qui sont diffusés par le point de terminaison /priv/doc/) et les requêtes pour les certificats SXG (qui sont diffusés par le point de terminaison /webpkg/cert/) ; La Les règles de réécriture d'URL varient légèrement pour chacun de ces types de requêtes. Pour Pour plus d'informations, reportez-vous à la section Exécution derrière le bord du frontal Google Cloud.

    Remarque :

    Par défaut, webpkgserver diffuse le certificat SXG à l'adresse /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 =