Como configurar trocas assinadas usando o Web Packager

Saiba como veicular trocas assinadas (SXGs) usando o Web Packager.

Katie Hempenius
Katie Hempenius
X

Uma troca assinada (SXG) é um mecanismo de entrega que facilita possível autenticar a origem de um recurso independentemente de como ele foi entregue. As instruções a seguir explicam como configurar as trocas assinadas usando Web Packager. As instruções estão incluídas para os certificados autoassinados e os certificados CanSignHttpExchanges.

Disponibilizar SXGs usando um certificado autoassinado

O uso de um certificado autoassinado para exibir SXGs é usado principalmente para para fins de demonstração e teste. SXGs assinadas com um certificado autoassinado gera mensagens de erro no navegador quando usado fora do teste ambientes e não deve ser exibido para rastreadores.

Pré-requisitos

Para seguir estas instruções, você precisará ter openssl e Go instalado no ambiente de desenvolvimento.

Gerar um certificado autoassinado

Esta seção explica como gerar um certificado autoassinado que pode ser usados com trocas assinadas.

Instruções

  1. Gere uma chave privada.

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

    A chave privada será salva como um arquivo chamado priv.key.

  2. Crie uma assinatura de certificado request (CSR).

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

    Uma solicitação de assinatura de certificado é um bloco de texto codificado que transmite a informações necessárias para solicitar um certificado de uma autoridade de certificação(CA). Embora você não solicite um certificado de um CA, ainda é necessário criar uma solicitação de assinatura de certificado.

    O comando acima cria uma solicitação de assinatura de certificado para uma organização chamada Web Packager Demo, que tem a chave nome example.com. A nome real deve ser o nome de domínio totalmente qualificado do site que contém o conteúdo que você quer empacotar como SXG.

    Em uma configuração de SXG de produção, isso seria um site de sua propriedade. No entanto, em uma ambiente de teste como o descrito nestas instruções, pode ser qualquer site.

  3. Crie um certificado que tenha a extensão 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")

    Esse comando usa a chave privada e a CSR criada nas etapas 1 e 2 para criar a arquivo de certificado cert.pem. A sinalização -extfile associa o certificado a a extensão do certificado CanSignHttpExchanges (1.3.6.1.4.1.11129.2.1.22 é o objeto identificador para a extensão CanSignHttpExchanges). Além disso, a sinalização -extfile também define example.com como uma alternativa de assunto Nome.

    Se você quiser conferir o conteúdo de cert.pem, use o seguinte comando:

    openssl x509 -in cert.pem -noout -text

    Você concluiu a criação das chaves privadas e dos certificados. Você vai precisar do Arquivos priv.key e cert.pem na próxima seção.

Configurar o servidor Web Packager para testes

Pré-requisitos

  1. Instale o Web Packager.

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

  2. Crie o webpkgserver.

    cd webpackager/cmd/webpkgserver
go build .

    webpkgserver é um binário específico no projeto Web Packager.

  3. Verifique se o webpkgserver foi instalado corretamente.

    ./webpkgserver --help

    Esse comando retornará informações sobre o uso de webpkgserver. Se isso não funcionar, uma boa primeira etapa da solução de problemas é verificar se o GOPATH está configurado corretamente.

Instruções

  1. Navegue até o diretório webpkgserver (talvez você já esteja nesse ).

    cd /path/to/cmd/webpkgserver

  2. Crie um arquivo webpkgsever.toml copiando o exemplo.

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

    Este arquivo contém as opções de configuração para webpkgserver.

  3. Abra webpkgserver.toml com um editor de sua escolha e faça o seguinte muda:

    • Mude a linha #AllowTestCert = false para AllowTestCert = true.
    • Mude a linha PEMFile = 'path/to/your.pem' para refletir o caminho o certificado PEM, cert.pem, que você criou. Não altere o mencionando TLS.PEMFile. Essa é uma opção de configuração diferente.
    • Mude a linha KeyFile = 'priv.key' para refletir o caminho do chave privada, priv.key, que você criou. Não altere a linha mencionando TLS.KeyFile. Essa é uma opção de configuração diferente.
    • Mude a linha #CertURLBase = '/webpkg/cert' para CertURLBase = 'data:'. CertURLBase indica o local de veiculação das SXG. certificado. Essa informação é usada para definir o parâmetro cert-url na as Signature cabeçalho das SXG. Em ambientes de produção, CertURLBase é usado assim: CertURLBase = 'https://mysite.com/'. No entanto, para aplicativos teste, CertURLBase = 'data:' pode ser usado para instruir webpkgserver para usar uma configuração URL para colocar o certificado inline no campo cert-url. Para testes locais, essa é a maneira mais conveniente de disponibilizar o certificado SXG.
    • Altere a linha Domain = 'example.org' para refletir o domínio que você criou um certificado. Se você tiver seguido as instruções artigo literal, ele precisa ser alterado para example.com. webpkgserver buscará somente conteúdo do domínio indicado por webpkgserver.toml. Se você tentar buscar páginas de um domínio diferente sem atualizar o webpkgserver.toml, os registros de webpkgserver vão mostrar a mensagem de erro URL doesn't match the fetch targets.

    Opcional

    Se você quiser ativar ou desativar o sub-recurso pré-carregamento, as seguintes opções de configuração de webpkgserver.toml são relevantes:

    • Para que webpkgserver insira diretivas para o pré-carregamento da folha de estilo e sub-recursos de script como SXGs, altere a linha #PreloadCSS = false para PreloadCSS = true. Além disso, altere a linha #PreloadJS = false para PreloadJS = true.

      Como alternativa ao uso dessa opção de configuração, é possível adicione cabeçalhos Link: rel="preload" e tags <link rel="preload"> a um HTML da página.

    • Por padrão, webpkgserver substitui as tags <link rel="preload"> atuais. com as tags <link> equivalentes, necessárias para buscar esse conteúdo como SXG. Ao fazer isso, webpkgserver definirá o allowed-alt-sxg e header-integrity conforme necessário. Os autores de HTML não precisam adicioná-las manualmente. Para substituir esse comportamento e manter pré-carregamentos não SXG existentes, alterar #KeepNonSXGPreloads (default = false) para KeepNonSXGPreloads = true. Lembre-se de que ativar essa opção pode tornar as SXGs não qualificadas para cache das SXG do Google de acordo com requisitos.

  4. Inicie webpkgserver.

    ./webpkgserver

    Se o servidor tiver sido iniciado com êxito, você verá as seguintes mensagens de registro: shell Listening at 127.0.0.1:8080 Successfully retrieved valid OCSP. Writing to cache in /private/tmp/webpkg

    Suas mensagens de registro podem ser um pouco diferentes. Especificamente, o diretório que o webpkgserver usa para armazenar em cache os certificados varia de acordo com o sistema operacional.

    Caso não veja essas mensagens, uma boa primeira solução etapa é verificar webpkgserver.toml.

    Se você atualizar o webpkgserver.toml, reinicie o webpkgserver.

  5. Inicie o Chrome com o seguinte 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`

    Esse comando instrui o Chrome a ignorar os erros de certificado associados com cert.pem. Isso possibilita testar as SXGs usando um certificado. Se o Chrome for iniciado sem esse comando, a inspeção das SXG no DevTools, vai mostrar o erro Certificate verification error: ERR_CERT_INVALID.

    Observação:

    Talvez seja necessário ajustar esse comando para refletir a localização do Chrome na da máquina e a localização do cert.pem. Se você já fez isso corretamente, você verá um aviso abaixo da barra de endereço. A aviso será semelhante a este: You are using an unsupported command-line flag: --ignore-certificate-errors-spki-list=9uxADcgc6/ho0mJLRMBcOjfBaN21k0sOInoMchr9CMY=.

    Se o aviso não incluir uma string de hash, isso significa que você não fez indicou a localização do certificado SXG.

  6. Abra a guia Rede do DevTools e acesse o seguinte URL: http://localhost:8080/priv/doc/https://example.com

    Isso faz uma solicitação à instância webpackager em execução em http://localhost:8080 para uma SXG com o conteúdo de https://example.com /priv/doc/ é o endpoint de API padrão usado pelo webpackager.

    Captura de tela da guia &quot;Network&quot; do DevTools mostrando uma SXG e o certificado dela.

    Os recursos a seguir estão listados na guia Rede:

    • Um recurso com o tipo signed-exchange Esta é a SXG.
    • Um recurso com o tipo cert-chain+cbor Este é o certificado das SXG. Os certificados SXG precisam usar o formato application/cert-chain+cbor.
    • Um recurso com o tipo document Este é o conteúdo enviado pelas SXG.

    Se você não encontrar esses recursos, tente limpar o cache do navegador e recarregando http://localhost:8080/priv/doc/https://example.com.

    Clique na guia Visualização para exibir mais informações sobre a troca assinada e sua assinatura.

    Captura de tela da guia &quot;Preview&quot; mostrando as SXGs

Exibir trocas assinadas usando um certificado CanSignHttpExchanges

As instruções nesta seção explicam como exibir SXGs usando um CanSignHttpExchanges certificado. O uso na produção de SXGs requer uma CanSignHttpExchanges certificado.

Por uma questão de brevidade, estas instruções foram escritas com o pressuposto que você entenda os conceitos discutidos no curso Configurar trocas assinadas usando um modelo autoassinado certificação nesta seção.

Pré-requisitos

  • Você tem um certificado CanSignHttpExchanges. Isso página lista as ACs que oferecem esse tipo de certificado.

  • Se você não tiver um certificado, poderá configurar seu webpkgserver para recuperem automaticamente certificados da CA. Você pode seguir rotas para o que acontece em webpkgserver.toml neste .

  • Embora não seja um requisito, é altamente recomendável executar webpkgserver atrás de um servidor de borda. Se você não usa um servidor de borda, você precisa configurar as opções TLS.PEMFile e TLS.KeyFile webpkgserver.toml Por padrão, o webpkgserver é executado em HTTP. No entanto, as SXG os certificados precisam ser veiculados por HTTPS para serem considerados válidos pelo navegador. Configurar TLS.PEMFile e TLS.KeyFile permite que webpkgserver use e, portanto, disponibilizar o certificado SXG diretamente para o navegador.

Instruções

  1. Crie um arquivo PEM concatenando o certificado SXG do site seguido por certificado de CA do seu site. Mais instruções sobre isso podem ser encontradas aqui.

    PEM é formato de arquivo comumente usado como um "contêiner" para armazenar vários certificados.

  2. Crie um novo arquivo webpkgsever.toml copiando o exemplo.

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

  3. Abra webpkgserver.toml com o editor de sua preferência e faça a as seguintes mudanças:

    • Mude a linha PEMFile = cert.pem para refletir a localização do PEM. que contém a cadeia completa de certificados.
    • Mude a linha KeyFile = 'priv.key' para refletir a localização do chave privada correspondente ao seu arquivo PEM.
    • Altere a linha Domain = 'example.org' para refletir seu site.
    • (Opcional) Para que webpkgserver renove automaticamente o certificado das SXG a cada 90 dias (45 dias para o Google), configure as opções na seção [SXG.ACME] do webpkgserver.toml Esta opção só é aplicável a sites com um certificado DigiCert ou do Google ACME.

  4. Configure seu servidor de borda para encaminhar tráfego para o webpkgserver instância.

    Há dois tipos principais de solicitações processadas pelo webpkgserver: solicitações para SXGs (que são atendidas pelo endpoint /priv/doc/) e solicitações de o certificado SXG (exibidos pelo endpoint /webpkg/cert/). A As regras de regravação de URL para cada um desses tipos de solicitação variam um pouco. Para mais informações, consulte Executar atrás do front-end servidor.

    Observação:

    Por padrão, webpkgserver exibe o certificado das SXG em /webpkg/cert/$CERT_HASH. Por exemplo, /webpkg/cert/-0QmE0gvoedn92gtwI3s7On9zPevJGm5pn2RYhpZxgY Para gerar $CERT_HASH, execute o seguinte comando: shell openssl base64 -in cert.pem -d | openssl dgst -sha256 -binary | base64 | tr /+ _- | tr -d =