Cómo configurar intercambios firmados con Web Packager

Aprende a entregar intercambios firmados (SXG) con Web Packager.

Katie Hempenius
Katie Hempenius
X

Un intercambio firmado (SXG) es un mecanismo de entrega que y es posible autenticar el origen de un recurso independientemente de cómo se entregó. Las siguientes instrucciones explican cómo configurar intercambios firmados con Web Packager Se incluyen instrucciones para certificados autofirmados y CanSignHttpExchanges.

Entrega SXG con un certificado autofirmado

El uso de un certificado autofirmado para entregar SXG se usa principalmente para demostraciones y pruebas. SXG firmados con un certificado autofirmado Generará mensajes de error en el navegador cuando se use fuera de las pruebas. y no se debe entregar a los rastreadores.

Requisitos previos

Para seguir estas instrucciones, deberás tener openssl y Instala Go en tu entorno de desarrollo.

Genera un certificado autofirmado

En esta sección, se explica cómo generar un certificado autofirmado que se puede usarse con intercambios firmados.

Instrucciones

  1. Genera una clave privada.

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

    La clave privada se guardará como un archivo llamado priv.key.

  2. Crear una firma de certificados solicitud (CSR).

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

    Una solicitud de firma de certificado es un bloque de texto codificado que transmite el la información necesaria para solicitar un certificado a una autoridad certificadora(AC) Si bien no le solicitarás un certificado a un AC, todavía es necesario crear una solicitud de firma de certificado.

    El comando anterior crea una solicitud de firma de certificado para una organización llamado Web Packager Demo que tiene la posición común nombre example.com. El el nombre de pila debe ser el nombre de dominio completamente calificado del sitio que contiene el contenido que deseas empaquetar como SXG.

    En un entorno de producción de SXG, este sería un sitio de tu propiedad. Sin embargo, entorno de pruebas como el que se describe en estas instrucciones, puede ser cualquier .

  3. Crea un certificado con la extensión 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")

    Este comando usa la clave privada y la CSR creada en los pasos 1 y 2 para crear la archivo de certificado cert.pem. La marca -extfile asocia el certificado con la extensión de certificado CanSignHttpExchanges (1.3.6.1.4.1.11129.2.1.22 es el objeto identificador para la extensión CanSignHttpExchanges). Además, la marca -extfile también define example.com como una Subject Alternative Nombre.

    Si te interesa el contenido de cert.pem, puedes verlo con el siguiente comando:

    openssl x509 -in cert.pem -noout -text

    Terminaste de crear claves privadas y certificados. Necesitarás las priv.key y cert.pem en la siguiente sección.

Configura el servidor de Web Packager para realizar pruebas

Requisitos previos

  1. Instala Web Packager.

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

  2. Compila webpkgserver.

    cd webpackager/cmd/webpkgserver
go build .

    webpkgserver es un objeto binario específico del proyecto Web Packager.

  3. Verifica que webpkgserver se haya instalado de forma correcta.

    ./webpkgserver --help

    Este comando debería mostrar información sobre el uso de webpkgserver. Si Esto no funciona, un buen primer paso para solucionar problemas es verificar que tu Se configuró GOPATH. correctamente.

Instrucciones

  1. Navega al directorio webpkgserver (es posible que ya estés en este directorio).

    cd /path/to/cmd/webpkgserver

  2. Copia el ejemplo para crear un archivo webpkgsever.toml.

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

    Este archivo contiene las opciones de configuración de webpkgserver.

  3. Abre webpkgserver.toml con el editor que prefieras y realiza las siguientes acciones: cambios:

    • Cambia la línea #AllowTestCert = false a AllowTestCert = true.
    • Cambia la línea PEMFile = 'path/to/your.pem' de modo que refleje la ruta a el certificado PEM, cert.pem, que creaste. No cambies la línea que menciona TLS.PEMFile: esta es una opción de configuración diferente.
    • Cambia la línea KeyFile = 'priv.key' para reflejar la ruta del clave privada, priv.key, que creaste. No cambiar la línea Mencionar TLS.KeyFile: Esta es una opción de configuración diferente.
    • Cambia la línea #CertURLBase = '/webpkg/cert' a CertURLBase = 'data:'. CertURLBase indica la ubicación de entrega del SXG. certificado. Esta información se usa para establecer el parámetro cert-url en el Signature del SXG. En entornos de producción, se usa CertURLBase. de la siguiente manera: CertURLBase = 'https://mysite.com/'. Sin embargo, para las campañas locales prueba, se puede usar CertURLBase = 'data:' para instruir a webpkgserver para usar una cuenta de datos URL para intercalar el certificado en el campo cert-url. Para las pruebas locales, es la forma más conveniente de entregar el certificado SXG.
    • Cambia la línea Domain = 'example.org' para reflejar el dominio que deseas. creó un certificado. Si seguiste las instrucciones de esta literal, se debe cambiar a example.com. webpkgserver solo recuperará contenido del dominio indicado por webpkgserver.toml Si intentas recuperar páginas de otro dominio sin actualizar webpkgserver.toml, se mostrarán los registros de webpkgserver el mensaje de error URL doesn't match the fetch targets.

    Opcional

    Si deseas habilitar o inhabilitar un subrecurso precarga, Las siguientes opciones de configuración de webpkgserver.toml son relevantes:

    • Tener directivas de inserción webpkgserver para precargar la hoja de estilo y secuencia de comandos de subrecursos como SXG, cambia la línea #PreloadCSS = false a PreloadCSS = true. Además, cambia la línea #PreloadJS = false a PreloadJS = true.

      Como alternativa al uso de esta opción de configuración, puedes hacer lo siguiente: agrega encabezados Link: rel="preload" y etiquetas <link rel="preload"> a un el código HTML de la página.

    • De forma predeterminada, webpkgserver reemplaza las etiquetas <link rel="preload"> existentes. con las etiquetas <link> equivalentes necesarias para recuperar este contenido como en SXG. De esta manera, webpkgserver establecerá el allowed-alt-sxg y header-integrity directivas según sea necesario: los autores de HTML no necesitan agregarlas manualmente. Para anular este comportamiento y mantener las precargas existentes que no son de SXG, cambiar De #KeepNonSXGPreloads (default = false) a KeepNonSXGPreloads = true. Ten en cuenta que, si habilitas esta opción, es posible que el SXG no sea apto para la caché de SXG de Google según estos requisitos.

  4. Inicia webpkgserver.

    ./webpkgserver

    Si el servidor se inició correctamente, deberías ver los siguientes mensajes de registro: shell Listening at 127.0.0.1:8080 Successfully retrieved valid OCSP. Writing to cache in /private/tmp/webpkg

    Tus mensajes de registro pueden tener un aspecto algo diferente. En particular, el directorio que usa webpkgserver para almacenar certificados en caché varía según el sistema operativo.

    Si no ves estos mensajes, te recomendamos que primero soluciones el problema. el paso es verificar webpkgserver.toml.

    Si actualizas webpkgserver.toml, debes reiniciar webpkgserver.

  5. Inicia Chrome con el siguiente 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`

    Este comando le indica a Chrome que ignore los errores de certificado asociados con cert.pem. Esto permite probar los SXG con una prueba certificado. Si Chrome se inicia sin este comando, inspección del SXG En Herramientas para desarrolladores, se mostrará el error Certificate verification error: ERR_CERT_INVALID.

    Nota:

    Es posible que debas ajustar este comando para que refleje la ubicación de Chrome en tu máquina y la ubicación de cert.pem. Si ya lo hiciste correctamente, deberías ver una advertencia debajo de la barra de direcciones. El la advertencia debería ser similar a la siguiente: You are using an unsupported command-line flag: --ignore-certificate-errors-spki-list=9uxADcgc6/ho0mJLRMBcOjfBaN21k0sOInoMchr9CMY=.

    Si la advertencia no incluye una cadena de hash, significa que no has cargado indicó la ubicación del certificado de SXG.

  6. Abre la pestaña Red de Herramientas para desarrolladores y visita la siguiente URL: http://localhost:8080/priv/doc/https://example.com

    Esto genera una solicitud a la instancia webpackager que se ejecuta en http://localhost:8080 para un SXG que incluya el contenido de https://example.com /priv/doc/ es el extremo de API predeterminado que usa webpackager

    Captura de pantalla de la pestaña Network de Herramientas para desarrolladores que muestra un SXG y su certificado.

    Los siguientes recursos se enumeran en la pestaña Red:

    • Un recurso con el tipo signed-exchange Este es el SXG.
    • Un recurso con el tipo cert-chain+cbor Este es el certificado de SXG. Los certificados SXG deben usar el formato application/cert-chain+cbor.
    • Un recurso con el tipo document Este es el contenido que se publicó a través de SXG.

    Si no ves estos recursos, intenta borrar la caché del navegador y, luego, vuelve a cargar http://localhost:8080/priv/doc/https://example.com.

    Haz clic en la pestaña Vista previa para ver más información sobre el intercambio firmado. y su firma.

    Captura de pantalla de la pestaña Vista previa que muestra un SXG

Entrega intercambios firmados con un certificado CanSignHttpExchanges

Las instrucciones de esta sección explican cómo entregar SXG con un CanSignHttpExchanges. El uso de producción de SXG requiere un CanSignHttpExchanges.

Para ser más breves, estas instrucciones están escritas con el supuesto de que comprende los conceptos analizados en la guía Configura intercambios firmados usando un modelo de certificado sección.

Requisitos previos

  • Tienes un certificado de CanSignHttpExchanges. Esta página enumera las AC que ofrecen este tipo de certificado.

  • Si no tienes un certificado, puedes configurar tu webpkgserver para recuperar automáticamente los certificados de tu AC. Puedes seguir el instrucciones sobre cómo llegar a lo que se incluye en webpkgserver.toml en esta página.

  • Aunque no es un requisito, se recomienda ejecutar webpkgserver detrás de un servidor perimetral. Si no usas un servidor perimetral, deberás configurar las opciones TLS.PEMFile y TLS.KeyFile en webpkgserver.toml De forma predeterminada, webpkgserver se ejecuta en HTTP. Sin embargo, en SXG los certificados deben entregarse a través de HTTPS para que el navegador los considere válidos. Configurar TLS.PEMFile y TLS.KeyFile permite que webpkgserver use HTTPS y, por lo tanto, entregar el certificado SXG directamente al navegador.

Instrucciones

  1. Crea un archivo PEM. Para ello, concatena el certificado SXG de tu sitio, seguido del el certificado de la AC de tu sitio. Puedes encontrar más instrucciones al respecto. aquí.

    PEM es un formato de archivo que se usa comúnmente como "contenedor" para almacenar varias certificados.

  2. Copia el ejemplo para crear un archivo webpkgsever.toml nuevo.

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

  3. Abre webpkgserver.toml con el editor que prefieras y realiza la acción siguientes cambios:

    • Cambia la línea PEMFile = cert.pem para reflejar la ubicación del PEM. que contiene la cadena de certificados completa.
    • Cambia la línea KeyFile = 'priv.key' de modo que refleje la ubicación del privada correspondiente a tu archivo PEM.
    • Cambia la línea Domain = 'example.org' para que refleje tu sitio.
    • (Opcional) Para que webpkgserver renueve automáticamente el certificado de SXG cada 90 días (45 días para Google), configura las opciones en la sección [SXG.ACME] de webpkgserver.toml Esta opción solo se aplica a sitios con un DigiCert o configurar una cuenta de ACME de Google.

  4. Configura tu servidor perimetral para reenviar tráfico a webpkgserver instancia.

    Hay dos tipos principales de solicitudes que maneja webpkgserver: solicitudes para SXG (que entrega el extremo /priv/doc/) y solicitudes para el certificado SXG (que entrega el extremo /webpkg/cert/) El Las reglas de reescritura de URL para cada uno de estos tipos de solicitud varían ligeramente. Para Para obtener más información, consulta Ejecución detrás del frontend servidor.

    Nota:

    De forma predeterminada, webpkgserver entrega el certificado de SXG en /webpkg/cert/$CERT_HASH, por ejemplo, /webpkg/cert/-0QmE0gvoedn92gtwI3s7On9zPevJGm5pn2RYhpZxgY Para generar $CERT_HASH, ejecuta el siguiente comando: shell openssl base64 -in cert.pem -d | openssl dgst -sha256 -binary | base64 | tr /+ _- | tr -d =