웹 패키지 도구를 사용하여 서명된 교환을 설정하는 방법

웹 패키지 도구를 사용하여 서명된 교환 (SXG)을 제공하는 방법을 알아봅니다.

Katie Hempenius
Katie Hempenius
X

서명된 교환 (SXG)은 리소스의 출처를 인증할 수 있습니다. 다음 안내는 다음을 사용하여 서명된 교환을 설정하는 방법을 설명합니다. 웹 패키지 도구. 이 도움말은 자체 서명된 인증서와 CanSignHttpExchanges 인증서 모두

자체 서명 인증서를 사용하여 SXG 제공

자체 서명 인증서를 사용하여 SXG를 제공하는 것은 주로 다음에 사용됩니다. 설명합니다. 자체 서명 인증서로 서명된 SXG 테스트 외부에서 사용하면 브라우저에 오류 메시지가 생성됩니다. 크롤러에 제공해서는 안 됩니다.

기본 요건

이 지침을 따르려면 다음 요건을 충족해야 합니다. openssl 및 개발 환경에 설치된 Go

자체 서명 인증서 생성

이 섹션에서는 자체 서명 인증서를 생성하는 방법에 대해 설명합니다. 사용되는 기기입니다.

안내

  1. 비공개 키를 생성합니다.

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

    비공개 키는 priv.key이라는 파일로 저장됩니다.

  2. 인증서 서명 생성 요청 (CSR)을 사용합니다.

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

    인증서 서명 요청은 다음을 전달하는 인코딩된 텍스트 블록입니다. 인증 기관(CA)의 인증서를 요청하는 데 필요한 정보 비록 기관에서 인증서를 요청하지 않더라도 CA의 경우, 인증서 서명 요청을 만들어야 합니다.

    위의 명령어는 조직에 대한 인증서 서명 요청을 생성합니다. 이름이 Web Packager Demo이며 이름 example.com). 이 일반 이름은 SXG로 패키징하려는 콘텐츠를 만듭니다.

    프로덕션 SXG 설정에서는 이 사이트가 본인 소유가 됩니다. 그러나 테스트 환경이 있는 경우, 어느 컴퓨터에서나 가능하거나 사이트

  3. 확장자가 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")

    이 명령은 1단계와 2단계에서 만든 개인 키와 CSR을 사용하여 인증서 파일 cert.pem. -extfile 플래그는 인증서를 CanSignHttpExchanges 인증서 확장자 (1.3.6.1.4.1.11129.2.1.22는 객체 식별자 (CanSignHttpExchanges 확장 프로그램) 또한 -extfile 플래그도 example.com를 주체 대안으로 정의합니다. 이름.

    cert.pem의 콘텐츠가 궁금하다면 다음 명령어를 실행합니다.

    openssl x509 -in cert.pem -noout -text

    비공개 키와 인증서 생성이 완료되었습니다. 이를 위해서는 priv.key 및 cert.pem 파일을 참조하세요.

테스트를 위한 웹 패키지 도구 서버 설정

기본 요건

  1. 웹 패키지 도구를 설치합니다.

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

  2. webpkgserver를 빌드합니다.

    cd webpackager/cmd/webpkgserver
go build .

    webpkgserver는 웹 패키지 도구 프로젝트 내의 특정 바이너리입니다.

  3. webpkgserver가 올바르게 설치되었는지 확인합니다.

    ./webpkgserver --help

    이 명령어는 webpkgserver 사용에 관한 정보를 반환해야 합니다. 만약 그래도 문제가 해결되지 않으면 먼저 GOPATH가 구성되었습니다. 있습니다.

안내

  1. webpkgserver 디렉터리로 이동합니다 (이미 이 디렉터리에 있을 수 있음). 디렉터리 참조).

    cd /path/to/cmd/webpkgserver

  2. 예시를 복사하여 webpkgsever.toml 파일을 만듭니다.

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

    이 파일에는 webpkgserver 구성 옵션이 포함되어 있습니다.

  3. 원하는 편집기로 webpkgserver.toml를 열고 다음을 수행합니다. 변경사항:

    • #AllowTestCert = false 줄을 AllowTestCert = true로 변경합니다.
    • 다음 경로를 반영하도록 PEMFile = 'path/to/your.pem' 줄을 변경합니다. 생성된 PEM 인증서(cert.pem)를 복사합니다. 사용자가 TLS.PEMFile를 언급하는 줄 - 다른 구성 옵션입니다.
    • 다음 경로를 반영하도록 KeyFile = 'priv.key' 줄을 변경합니다. 내가 만든 비공개 키(priv.key)입니다. 줄을 변경하지 마세요. 이는 다른 구성 옵션입니다.TLS.KeyFile
    • #CertURLBase = '/webpkg/cert' 줄을 CertURLBase = 'data:'로 변경합니다. CertURLBase는 SXG의 제공 위치를 나타냅니다. 있습니다. 이 정보는 cert-url 매개변수를 Signature SXG 헤더입니다. 프로덕션 환경에서는 CertURLBase이 사용됩니다. 예를 들면 다음과 같습니다. CertURLBase = 'https://mysite.com/' 하지만 테스트, CertURLBase = 'data:'를 사용하여 webpkgserver를 지시할 수 있음 데이터를 사용하여 URL 인증서를 cert-url 필드에 인라인으로 추가합니다. 로컬 테스트의 경우 이것이 SXG 인증서를 제공하는 가장 편리한 방법입니다.
    • 지정한 도메인을 반영하도록 Domain = 'example.org' 행을 변경합니다. 인증서가 생성됩니다 이 문서의 안내를 따랐다면 기사 그대로이면 example.com로 변경해야 합니다. webpkgserver는 webpkgserver.toml 다른 도메인에서 페이지를 가져오려는 경우 webpkgserver.toml를 업데이트하지 않으면 webpkgserver 로그가 다음과 같이 표시됩니다. URL doesn't match the fetch targets 오류 메시지가 표시됩니다.

    선택사항

    하위 리소스 미리 로드, 다음 webpkgserver.toml 구성 옵션이 관련이 있습니다.

    • 스타일시트 미리 로드를 위한 삽입 지시문 webpkgserver개 사용 SXG로 스크립트 하위 리소스를 사용하려면 #PreloadCSS = false행을 변경합니다. PreloadCSS = true에게 전송합니다. 또한 #PreloadJS = false 줄을 PreloadJS = true로 변경합니다.

      이 구성 옵션을 사용하는 대신 Link: rel="preload" 헤더와 <link rel="preload"> 태그를 페이지의 HTML에 삽입됩니다.

    • 기본적으로 webpkgserver는 기존 <link rel="preload"> 태그를 대체합니다. 이 콘텐츠를<link> SXG입니다. 이렇게 하면 webpkgserver는 allowed-alt-sxg 및 header-integrity 지시어를 사용하여 HTML 작성자가 직접 추가할 필요가 없습니다. 받는사람 이 동작을 재정의하고 기존의 비 SXG 미리 로드를 유지하고, #KeepNonSXGPreloads (default = false)에서 KeepNonSXGPreloads = true(으)로 이 옵션을 사용 설정하면 SXG가 Google SXG 캐시를 요구사항을 충족합니다.

  4. webpkgserver를 시작합니다.

    ./webpkgserver

    서버가 성공적으로 시작되면 다음과 같은 로그 메시지가 표시됩니다. shell Listening at 127.0.0.1:8080 Successfully retrieved valid OCSP. Writing to cache in /private/tmp/webpkg

    로그 메시지가 약간 다르게 표시될 수 있습니다. 특히 디렉터리는 webpkgserver에서 인증서를 캐시하는 데 사용하는 운영체제는 운영체제에 따라 다릅니다.

    이러한 메시지가 표시되지 않는 경우 우선 문제를 해결하는 것이 좋습니다. 단계는 webpkgserver.toml를 다시 확인하는 것입니다.

    webpkgserver.toml를 업데이트하면 webpkgserver를 다시 시작해야 합니다.

  5. 다음 명령어를 사용하여 Chrome을 실행합니다. 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`

    이 명령어를 사용하면 Chrome에서 관련 인증서 오류를 무시하도록 지시할 수 있습니다. cert.pem를 사용합니다. 이렇게 하면 테스트를 사용하여 SXG를 테스트할 수 있습니다. 있습니다. 이 명령어 없이 Chrome이 실행되는 경우 SXG 검사 그러면 DevTools에 Certificate verification error: ERR_CERT_INVALID 오류가 표시됩니다.

    참고:

    이 명령을 조정하여 컴퓨터에 Chrome의 위치를 반영해야 할 수 있습니다. 머신 및 cert.pem의 위치도 포함됩니다. 이 작업을 수행했다면 주소 표시줄 아래에 경고가 표시됩니다. 이 경고는 다음과 같이 표시됩니다. You are using an unsupported command-line flag: --ignore-certificate-errors-spki-list=9uxADcgc6/ho0mJLRMBcOjfBaN21k0sOInoMchr9CMY=.

    경고에 해시 문자열이 포함되지 않은 경우 SXG 인증서의 위치를 나타냅니다.

  6. DevTools 네트워크 탭을 열고 다음 URL로 이동합니다. http://localhost:8080/priv/doc/https://example.com입니다.

    이렇게 하면 다음 위치에서 실행 중인 webpackager 인스턴스에 요청이 http://localhost:8080: https://example.com입니다. /priv/doc/는 webpackager

    SXG 및 인증서를 보여주는 DevTools Network 탭의 스크린샷

    네트워크 탭에 나열된 리소스는 다음과 같습니다.

    • signed-exchange 유형의 리소스. 이것이 바로 SXG입니다.
    • cert-chain+cbor 유형의 리소스. 이것은 SXG 인증서입니다. SXG 인증서는 application/cert-chain+cbor 형식을 사용해야 합니다.
    • document 유형의 리소스. SXG를 통해 전송된 콘텐츠입니다.

    이러한 리소스가 표시되지 않으면 브라우저 캐시를 지운 다음 http://localhost:8080/priv/doc/https://example.com을(를) 새로고침하는 중입니다.

    Preview 탭을 클릭하여 서명된 교환에 대한 자세한 내용을 확인합니다. 서명해야 합니다.

    SXG를 보여주는 미리보기 탭의 스크린샷

CanSignHttpExchanges 인증서를 사용하여 서명된 교환 제공

이 섹션의 안내에서는 CanSignHttpExchanges 인증서 SXG의 프로덕션 사용을 위해서는 CanSignHttpExchanges 인증서

간결함을 위해 이 지침은 서명된 교환 설정 자체 서명 사용 인증서 섹션으로 이동합니다.

기본 요건

  • CanSignHttpExchanges 인증서가 있습니다. 이 페이지 이 유형의 인증서를 제공하는 CA가 나열됩니다.

  • 인증서가 없는 경우 다음을 수행하도록 webpkgserver를 구성할 수 있습니다. 자동으로 CA에서 인증서를 가져옵니다. 이 webpkgserver.toml(으)로 가는 길 페이지에서 확인할 수 있습니다.

  • 필수 사항은 아니지만 Cloud Shell에서 webpkgserver는 에지 서버 뒤에서 이루어집니다. 에지 서버를 사용하지 않는 경우 TLS.PEMFile 및 TLS.KeyFile 옵션을 구성해야 합니다. webpkgserver.toml입니다. 기본적으로 webpkgserver는 HTTP에서 실행됩니다. 하지만 SXG는 인증서가 HTTPS를 통해 제공되어야 브라우저에서 유효한 것으로 간주할 수 있습니다. TLS.PEMFile 및 TLS.KeyFile를 구성하면 webpkgserver에서 사용할 수 있습니다. HTTPS를 사용하므로 SXG 인증서를 브라우저에 직접 제공합니다.

안내

  1. 사이트의 SXG 인증서를 연결한 다음 사이트의 CA 인증서 이에 대한 자세한 안내는 여기에서 확인할 수 있습니다.

    PEM은 '컨테이너'로 흔히 사용되는 파일 형식 여러 개의 파일을 있습니다

  2. 예시를 복사하여 새 webpkgsever.toml 파일을 만듭니다.

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

  3. 원하는 편집기로 webpkgserver.toml를 열고 다음을 수행합니다. 다음과 같은 변경사항을 적용할 수 있습니다.

    • PEM의 위치를 반영하도록 PEMFile = cert.pem 줄을 변경합니다. 전체 인증서 체인이 포함된 파일을 찾습니다.
    • KeyFile = 'priv.key' 줄을 변경하여 비공개 키를 찾습니다.
    • 사이트를 반영하도록 Domain = 'example.org' 줄을 변경합니다.
    • (선택사항) webpkgserver에서 SXG 인증서를 자동 갱신하도록 하려면 90일 (Google의 경우 45일)인 경우 [SXG.ACME] 섹션의 webpkgserver.toml입니다. 이 옵션은 DigiCert가 등록된 사이트에만 적용됩니다. 또는 Google ACME 계정 설정입니다.

  4. 트래픽을 webpkgserver에 전달하도록 에지 서버를 구성합니다. 인스턴스를 만들 수 있습니다

    webpkgserver에서 처리하는 요청에는 두 가지 기본 유형, 즉 요청이 있습니다. SXG (/priv/doc/ 엔드포인트에서 제공) 및 SXG 인증서 (/webpkg/cert/ 엔드포인트에서 제공) 이 이러한 각 요청 유형에 대한 URL 재작성 규칙은 약간씩 다릅니다. 대상 자세한 내용은 프런트 엔드 가장자리 뒤에서 실행 있습니다.

    참고:

    기본적으로 webpkgserver는 /webpkg/cert/$CERT_HASH: 예를 들면 다음과 같습니다. /webpkg/cert/-0QmE0gvoedn92gtwI3s7On9zPevJGm5pn2RYhpZxgY입니다. $CERT_HASH를 생성하려면 다음 명령어를 실행합니다. shell openssl base64 -in cert.pem -d | openssl dgst -sha256 -binary | base64 | tr /+ _- | tr -d =