Come configurare Signed Exchange utilizzando Web Packager

Scopri come gestire piattaforme SXG (Signed Exchange) utilizzando Web Packager.

Katie Hempenius
Katie Hempenius
X

Un Signed Exchange (SXG) è un meccanismo di consegna che lo rende per autenticare l'origine di una risorsa indipendentemente da come è stata distribuita. Le seguenti istruzioni spiegano come configurare le piattaforme di scambio firmate utilizzando Web Packager. Sono incluse le istruzioni per sia autofirmati sia certificati CanSignHttpExchanges.

Gestire gli SXG utilizzando un certificato autofirmato

L'utilizzo di un certificato autofirmato per la pubblicazione di SXG viene utilizzato principalmente per a scopi dimostrativi e di test. SXG firmati con un certificato autofirmato genererà messaggi di errore nel browser quando vengono utilizzati al di fuori dei test. e non devono essere mostrati ai crawler.

Prerequisiti

Per seguire queste istruzioni dovrai avere openssl e Go installato nel tuo ambiente di sviluppo.

Genera un certificato autofirmato

Questa sezione spiega come generare un certificato autofirmato che può essere utilizzati con gli scambi firmati.

Istruzioni

  1. Generare una chiave privata.

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

    La chiave privata verrà salvata come file denominato priv.key.

  2. Creare una firma per i certificati richiesta (CSR).

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

    Una richiesta di firma di certificato è un blocco di testo codificato che trasmette Informazioni necessarie per richiedere un certificato a un'autorità di certificazione. Anche se non richiederai un certificato a un CA, è ancora necessario creare una richiesta di firma del certificato.

    Il comando riportato sopra crea una richiesta di firma del certificato per un'organizzazione denominato Web Packager Demo che ha il valore comune nome example.com. La comune deve essere il nome di dominio completo del sito che contiene i contenuti che vuoi pacchettizzare come SXG.

    In una configurazione SXG di produzione, questo è un sito di tua proprietà. Tuttavia, in un di test come quello descritto in queste istruzioni, può essere qualsiasi sito.

  3. Crea un certificato con l'estensione 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")

    Questo comando utilizza la chiave privata e la richiesta di firma del certificato (CSR) create nei passaggi 1 e 2 per creare file del certificato cert.pem. Il flag -extfile associa il certificato a l'estensione di certificato CanSignHttpExchanges (1.3.6.1.4.1.11129.2.1.22 è l'oggetto identificatore per l'estensione CanSignHttpExchanges). Inoltre, il flag -extfile definisce example.com come Oggetto alternativo Nome.

    Se ti incuriosiscono i contenuti di cert.pem, puoi visualizzarli utilizzando lo seguente comando:

    openssl x509 -in cert.pem -noout -text

    Hai completato la creazione di chiavi private e certificati. Avrai bisogno della priv.key e cert.pem file nella sezione successiva.

Configura il server Web Packager per i test

Prerequisiti

  1. Installa Web Packager.

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

  2. Crea webpkgserver.

    cd webpackager/cmd/webpkgserver
go build .

    webpkgserver è un file binario specifico all'interno del progetto Web Packager.

  3. Verifica che webpkgserver sia stato installato correttamente.

    ./webpkgserver --help

    Questo comando dovrebbe restituire informazioni sull'utilizzo di webpkgserver. Se non funziona, il primo passaggio per la risoluzione dei problemi è verificare che GOPATH è configurato in modo corretto.

Istruzioni

  1. Vai alla directory webpkgserver (potresti trovarti già in questa directory ).

    cd /path/to/cmd/webpkgserver

  2. Crea un file webpkgsever.toml copiando l'esempio.

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

    Questo file contiene le opzioni di configurazione per webpkgserver.

  3. Apri webpkgserver.toml con un editor di tua scelta e procedi come segue modifiche:

    • Cambia la riga #AllowTestCert = false in AllowTestCert = true.
    • Modifica la linea PEMFile = 'path/to/your.pem' per riflettere il percorso in il certificato PEM cert.pem che hai creato. Non modificare il riga che menziona TLS.PEMFile: si tratta di un'opzione di configurazione diversa.
    • Modifica la linea KeyFile = 'priv.key' per riflettere il percorso della chiave privata priv.key che hai creato. Non cambiare linea che menziona TLS.KeyFile: si tratta di un'opzione di configurazione diversa.
    • Cambia la riga #CertURLBase = '/webpkg/cert' in CertURLBase = 'data:'. CertURLBase indica la località di pubblicazione dell'SXG certificato. Queste informazioni vengono utilizzate per impostare il parametro cert-url in il Signature dell'intestazione SXG. Negli ambienti di produzione, viene utilizzato CertURLBase nel seguente modo: CertURLBase = 'https://mysite.com/'. Tuttavia, per gli annunci locali test, è possibile usare CertURLBase = 'data:' per indicare webpkgserver per utilizzare dati URL per incorporare il certificato nel campo cert-url. Per i test locali, Questo è il modo più pratico per pubblicare il certificato SXG.
    • Modifica la riga Domain = 'example.org' in modo che rifletta il dominio che ha creato un certificato. Se hai seguito le istruzioni in questa questo valore deve essere sostituito con example.com. webpkgserver recupererà solo i contenuti dal dominio indicato da webpkgserver.toml. Se provi a recuperare pagine da un dominio diverso senza aggiornare webpkgserver.toml, i log webpkgserver mostreranno il messaggio di errore URL doesn't match the fetch targets.

    Facoltativo

    Se vuoi abilitare o disabilitare la sottorisorsa di precaricamento, le seguenti opzioni di configurazione di webpkgserver.toml sono pertinenti:

    • Per fare in modo che webpkgserver inserisci istruzioni per il precaricamento del foglio di stile e script sottorisorse come SXG, cambia la riga #PreloadCSS = false a PreloadCSS = true. Inoltre, modifica la riga #PreloadJS = false in PreloadJS = true.

      In alternativa a questa opzione di configurazione, puoi eseguire aggiungi intestazioni Link: rel="preload" e tag <link rel="preload"> a un HTML della pagina.

    • Per impostazione predefinita, webpkgserver sostituisce i tag <link rel="preload"> esistenti con i tag <link> equivalenti necessari per recuperare questi contenuti come SXG In questo modo, webpkgserver imposterà allowed-alt-sxg e header-integrity istruzioni speciali secondo necessità: gli autori HTML non devono aggiungerle a mano. A ignorare questo comportamento e mantenere i precaricamenti non SXG esistenti, modificare Da #KeepNonSXGPreloads (default = false) a KeepNonSXGPreloads = true. Tieni presente che attivando questa opzione, SXG potrebbe non essere idoneo per cache SXG di Google in base a questi requisiti.

  4. Avvia webpkgserver.

    ./webpkgserver

    Se il server è stato avviato correttamente, dovrebbero essere visualizzati i seguenti messaggi di log: shell Listening at 127.0.0.1:8080 Successfully retrieved valid OCSP. Writing to cache in /private/tmp/webpkg

    I messaggi di log potrebbero essere leggermente diversi. In particolare, la directory che webpkgserver utilizza per memorizzare i certificati varia in base al sistema operativo.

    Se non vedi questi messaggi, ti consigliamo di iniziare passaggio è controllare webpkgserver.toml.

    Se aggiorni webpkgserver.toml, devi riavviare webpkgserver.

  5. Avvia Chrome utilizzando questo comando: 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`

    Questo comando indica a Chrome di ignorare gli errori del certificato associati con cert.pem. Ciò consente di testare gli SXG utilizzando un modello certificato. Se Chrome viene avviato senza questo comando, l'ispezione SXG in DevTools verrà visualizzato l'errore Certificate verification error: ERR_CERT_INVALID.

    Nota:

    Potresti dover modificare questo comando per riflettere la posizione di Chrome su della tua macchina, oltre alla posizione di cert.pem. Se l'hai già fatto correttamente, dovrebbe essere visualizzato un avviso sotto la barra degli indirizzi. La dovrebbe essere simile a questo: You are using an unsupported command-line flag: --ignore-certificate-errors-spki-list=9uxADcgc6/ho0mJLRMBcOjfBaN21k0sOInoMchr9CMY=.

    Se l'avviso non include una stringa hash, significa che non hai inserito indicava la posizione del certificato SXG.

  6. Apri la scheda Rete di DevTools, quindi visita il seguente URL: http://localhost:8080/priv/doc/https://example.com.

    Verrà effettuata una richiesta all'istanza webpackager in esecuzione alle ore http://localhost:8080 per uno scambio SXG con i contenuti di https://example.com. /priv/doc/ è l'endpoint API predefinito utilizzato da webpackager.

    Screenshot della scheda Rete DevTools che mostra un SXG e il relativo certificato.

    Le seguenti risorse sono elencate nella scheda Rete:

    • Una risorsa di tipo signed-exchange. Questo è l'SXG.
    • Una risorsa di tipo cert-chain+cbor. Questo è il certificato SXG. I certificati SXG devono essere nel formato application/cert-chain+cbor.
    • Una risorsa di tipo document. Questi sono i contenuti pubblicati tramite SXG.

    Se non trovi queste risorse, prova a svuotare la cache del browser, ricaricamento di http://localhost:8080/priv/doc/https://example.com in corso...

    Fai clic sulla scheda Anteprima per visualizzare ulteriori informazioni su Signed Exchange. e la sua firma.

    Screenshot della scheda Anteprima che mostra un SXG

Gestire le piattaforme di scambio firmate utilizzando un certificato CanSignHttpExchanges

Le istruzioni in questa sezione spiegano come inviare messaggi SXG utilizzando un Certificato CanSignHttpExchanges. L'uso di SXG in produzione richiede Certificato CanSignHttpExchanges.

Per brevità, queste istruzioni sono scritte partendo dal presupposto di aver compreso i concetti discussi nella sezione Configurare piattaforme di scambio pubblicitario firmate utilizzando un modello di attribuzione certificato .

Prerequisiti

  • Hai un certificato CanSignHttpExchanges. Questo indica le CA che offrono questo tipo di certificato.

  • Se non hai un certificato, puoi configurare webpkgserver per il recupero automatico dei certificati dalla CA. Puoi seguire indicazioni stradali per ciò che riguarda webpkgserver.toml in questo pagina.

  • Sebbene non sia un requisito, consigliamo vivamente di eseguire webpkgserver dietro un server perimetrale. Se non utilizzi un Edge Server, dovrai configurare le opzioni TLS.PEMFile e TLS.KeyFile in webpkgserver.toml. Per impostazione predefinita, webpkgserver viene eseguito su HTTP. Tuttavia, SXG I certificati devono essere pubblicati tramite HTTPS per essere considerati validi dal browser. La configurazione di TLS.PEMFile e TLS.KeyFile consente a webpkgserver di utilizzare HTTPS e quindi distribuiscono il certificato SXG direttamente al browser.

Istruzioni

  1. Crea un file PEM concatenando il certificato SXG del tuo sito seguito da il certificato CA del sito. Sono disponibili ulteriori istruzioni al riguardo qui

    PEM è un formato file comunemente utilizzato come "contenitore" per archiviare più certificati.

  2. Crea un nuovo file webpkgsever.toml copiando l'esempio.

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

  3. Apri webpkgserver.toml con l'editor che preferisci ed esegui la le seguenti modifiche:

    • Modifica la linea PEMFile = cert.pem per riflettere la posizione del PEM contenente la catena di certificati completa.
    • Modifica la linea KeyFile = 'priv.key' per riflettere la posizione del chiave privata corrispondente al tuo file PEM.
    • Modifica la riga Domain = 'example.org' in modo che rifletta il tuo sito.
    • (Facoltativo) Per fare in modo che webpkgserver rinnovi automaticamente il certificato SXG ogni 90 giorni (45 giorni per Google), configura le opzioni nella sezione [SXG.ACME] di webpkgserver.toml. Questa opzione si applica solo ai siti con un DigiCert o un account Google ACME.

  4. Configura il tuo server perimetrale per inoltrare il traffico a webpkgserver in esecuzione in un'istanza Compute Engine.

    Esistono due tipi principali di richieste gestiti da webpkgserver: per gli SXG (gestiti dall'endpoint /priv/doc/) e le richieste il certificato SXG (fornito dall'endpoint /webpkg/cert/). La Le regole di riscrittura degli URL per ciascuno di questi tipi di richieste variano leggermente. Per per ulteriori informazioni, consulta la sezione Correre dietro un front-end o server web.

    Nota:

    Per impostazione predefinita, webpkgserver pubblica il certificato SXG su /webpkg/cert/$CERT_HASH, ad esempio /webpkg/cert/-0QmE0gvoedn92gtwI3s7On9zPevJGm5pn2RYhpZxgY. Per generare $CERT_HASH, esegui questo comando: shell openssl base64 -in cert.pem -d | openssl dgst -sha256 -binary | base64 | tr /+ _- | tr -d =