Web Paketleyici kullanarak İmzalı Değişimler nasıl kurulur?

İmzalı değişim (SXG), nasıl teslim edildiğinden bağımsız olarak bir kaynağın kaynağının kimliğini doğrulamayı mümkün kılan bir teslim mekanizmasıdır. Aşağıdaki talimatlar, kullanarak Signed Exchange’lerin nasıl kurulacağını açıklamaktadır. Web Paketleyici. Talimatlar hem kendinden imzalı hem de CanSignHttpExchanges sertifikalar.

Kendinden imzalı bir sertifika kullanarak SXG’ler sunun #

SXG’lere hizmet vermek için kendinden imzalı bir sertifika kullanmak, öncelikle gösterim ve test amacıyla kullanılır. Kendinden imzalı bir sertifikayla imzalanan SXG’ler, test ortamlarının dışında kullanıldığında tarayıcıda hata mesajları oluşturur ve tarayıcılara sunulmamalıdır.

Önkoşullar #

Bu talimatları takip etmek için sahip olmanız gerekir. açılır Ve Gitmek geliştirme ortamınızda yüklü.

Kendinden imzalı bir sertifika oluşturun #

Bu bölümde, imzalı değiş tokuşlarla kullanılabilecek kendinden imzalı bir sertifikanın nasıl oluşturulacağı açıklanmaktadır.

Talimatlar #

1. Özel bir anahtar oluşturun.

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

   Özel anahtar adlı bir dosya olarak kaydedilecek priv.key.

2. Oluşturmak sertifika imzalama isteği (KSS).

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

   Sertifika imzalama talebi, bir sertifika talebinde bulunmak için gerekli bilgileri ileten kodlanmış bir metin bloğudur. sertifika yetkilisi(CA). Bir CA’dan sertifika talep etmeyecek olsanız da, yine de bir sertifika imzalama talebi oluşturmanız gerekir.

   Yukarıdaki komut, adlı bir kuruluş için bir sertifika imzalama isteği oluşturur. Web Packager Demo sahip olan yaygın isim example.com. Ortak ad, SXG olarak paketlemek istediğiniz içeriğin bulunduğu sitenin tam etki alanı adı olmalıdır.

   Bir üretim SXG kurulumunda bu, sahibi olduğunuz bir site olacaktır. Ancak, bu talimatlarda açıklanan gibi bir test ortamında herhangi bir site olabilir.

3. Şu özelliklere sahip bir sertifika oluşturun: CanSignHttpExchanges eklenti.

   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")

   Bu komut, sertifika dosyasını oluşturmak için 1. ve 2. adımlarda oluşturulan özel anahtarı ve CSR’yi kullanır. cert.pem. bu -extfile flag, sertifikayı aşağıdakilerle ilişkilendirir: CanSignHttpExchanges sertifika uzantısı (1.3.6.1.4.1.11129.2.1.22 bu nesne tanımlayıcı için CanSignHttpExchanges eklenti). ek olarak -extfile bayrak da tanımlar example.com olarak Konu Alternatif Adı.

   içeriğini merak ediyorsanız cert.pemaşağıdaki komutu kullanarak bunları görüntüleyebilirsiniz:

   openssl x509 -in cert.pem -noout -text

   Özel anahtarlar ve sertifikalar oluşturmayı bitirdiniz. ihtiyacınız olacak priv.key Ve cert.pem sonraki bölümde dosyalar.

Test için Web Paketleyici sunucusunu kurun #

Önkoşullar #

1. Düzenlemek Web Paketleyici.

   git clone 

2. İnşa etmek webpkgserver.

   cd webpackager/cmd/webpkgserver
   go build .

   webpkgserver Web Paketleyici projesi içindeki belirli bir ikili dosyadır.

3. Bunu doğrulayın webpkgserver doğru şekilde kuruldu.

   ./webpkgserver --help

   Bu komut, kullanımı hakkında bilgi vermelidir. webpkgserver. Bu işe yaramazsa, iyi bir ilk sorun giderme adımı, GOPATH doğru yapılandırılmıştır.

Talimatlar #

1. Şuraya git: webpkgserver dizini (zaten bu dizinde olabilirsiniz).

   cd /path/to/cmd/webpkgserver

2. Oluşturmak webpkgsever.toml örneği kopyalayarak dosya.

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

   Bu dosya, aşağıdakiler için yapılandırma seçeneklerini içerir: webpkgserver.

3. Açık webpkgserver.toml Seçtiğiniz bir editörle ve aşağıdaki değişiklikleri yapın:

   • çizgiyi değiştir #AllowTestCert = false ile AllowTestCert = true.
   • çizgiyi değiştir PEMFile="path/to/your.pem" PEM sertifikasına giden yolu yansıtmak için, cert.pem, oluşturduğunuz Bahsedilen satırı değiştirmeyin TLS.PEMFile—bu, farklı bir yapılandırma seçeneğidir.
   • çizgiyi değiştir KeyFile="priv.key" özel anahtarın yolunu yansıtmak için, priv.key, oluşturduğunuz Bahsedilen satırı değiştirmeyin TLS.KeyFile—bu, farklı bir yapılandırma seçeneğidir.
   • çizgiyi değiştir #CertURLBase="/webpkg/cert" ile CertURLBase="data:". CertURLBase SXG sertifikasının sunulduğu yeri belirtir. Bu bilgi, ayarlamak için kullanılır. cert-url içindeki parametre Signature SXG’nin başlığı. Üretim ortamlarında, CertURLBase şu şekilde kullanılır: CertURLBase="https://mysite.com/". Ancak, yerel testler için, CertURLBase="data:" talimat vermek için kullanılabilir webpkgserver kullanmak için veri URL’si sertifikayı satır içine almak için cert-url alan. Yerel testler için bu, SXG sertifikasını sunmanın en uygun yoludur.
   • çizgiyi değiştir Domain = 'example.org' Sertifika oluşturduğunuz etki alanını yansıtmak için. Bu makaledeki talimatları harfi harfine takip ettiyseniz, bu şu şekilde değiştirilmelidir: example.com. webpkgserver yalnızca ile belirtilen etki alanından içerik getirecek webpkgserver.toml. Güncelleme yapmadan farklı bir alandan sayfalar getirmeye çalışırsanız webpkgserver.toml, webpkgserver günlükler hata mesajını gösterecek URL doesn't match the fetch targets.

   İsteğe bağlı

   Etkinleştirmek veya devre dışı bırakmak istiyorsanız alt kaynak önyüklemesiaşağıdaki webpkgserver.toml yapılandırma seçenekleri önemlidir:

   • Sahip olmak webpkgserver stil sayfasını ve komut dosyası alt kaynaklarını SXG’ler olarak önceden yüklemek için yönergeler ekleyin, satırı değiştirin #PreloadCSS = false ile PreloadCSS = true. Ayrıca satırı değiştir #PreloadJS = false ile PreloadJS = true.

     Bu yapılandırma seçeneğini kullanmaya alternatif olarak, manuel olarak ekleyebilirsiniz. Link: rel="preload" başlıklar ve &LTlink rel="preload"> bir sayfanın HTML’sine etiketler.

   • Varsayılan olarak, webpkgserver mevcut yerini alır &LTlink rel="preload"> eşdeğeri olan etiketler &LTlink> bu içeriği SXG olarak getirmek için gerekli etiketler. Bunu yaparken, webpkgserver ayarlayacak allowed-alt-sxg Ve header-integrity direktifler gerektiği gibi—HTML yazarlarının bunları elle eklemesine gerek yoktur. Bu davranışı geçersiz kılmak ve mevcut SXG olmayan ön yüklemeleri korumak için değiştirin #KeepNonSXGPreloads (default = false) ile KeepNonSXGPreloads = true. Bu seçeneğin etkinleştirilmesinin, SXG’yi Google SXG önbelleği için uygun hale getiremeyeceğini unutmayın. Gereksinimler.

4. Başlangıç webpkgserver.

   ./webpkgserver

   Sunucu başarıyla başlatıldıysa, aşağıdaki günlük mesajlarını görmelisiniz:

   Listening at 127.0.0.1:8080
   Successfully retrieved valid OCSP.
   Writing to cache in /private/tmp/webpkg

   Günlük mesajlarınız biraz farklı görünebilir. Özellikle, dizini webpkgserver sertifikaları önbelleğe almak için kullanımları işletim sistemine göre değişir.

   Bu mesajları görmüyorsanız, iyi bir ilk sorun giderme adımı tekrar kontrol etmektir. webpkgserver.toml.

   güncelleme yaparsanız webpkgserver.toml yeniden başlatmalısın webpkgserver.

5. Aşağıdaki komutu kullanarak Chrome’u başlatın:

   /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`

   Bu komut, Chrome’a ​​aşağıdakilerle ilişkili sertifika hatalarını yok sayması talimatını verir: cert.pem. Bu, bir test sertifikası kullanarak SXG’leri test etmeyi mümkün kılar. Chrome bu komut olmadan başlatılırsa DevTools’ta SXG’yi incelemek hatayı görüntüler Certificate verification error: ERR_CERT_INVALID.

   Not:

   Bu komutu, Chrome’un makinenizdeki konumunun yanı sıra Chrome’un konumunu da yansıtacak şekilde ayarlamanız gerekebilir. cert.pem. Bunu doğru yaptıysanız, adres çubuğunun altında görüntülenen bir uyarı görmelisiniz. Uyarı şuna benzer olmalıdır: You are using an unsupported command-line flag: --ignore-certificate-errors-spki-list=9uxADcgc6/ho0mJLRMBcOjfBaN21k0sOInoMchr9CMY=.

   Uyarı bir karma dize içermiyorsa, SXG sertifikasının konumunu doğru şekilde belirtmemişsinizdir.

6. DevTools’u açın Ağ sekmesini tıklayın, ardından aşağıdaki URL’yi ziyaret edin: /priv/doc/https://example.com.

   Bu, bir talepte bulunur webpackager çalışan örnek içeriğini içeren bir SXG için https://example.com. /priv/doc/ tarafından kullanılan varsayılan API bitiş noktasıdır. webpackager.

Aşağıdaki kaynaklar, Ağ sekme:

• Türe sahip bir kaynak signed-exchange. Bu SXG’dir.
• Türe sahip bir kaynak cert-chain+cbor. Bu SXG sertifikası. SXG sertifikaları şunları kullanmalıdır: application/cert-chain+cbor biçim.
• Türe sahip bir kaynak document. Bu, SXG aracılığıyla iletilen içeriktir.

Bu kaynakları görmüyorsanız, tarayıcı önbelleğini temizlemeyi ve ardından yeniden yüklemeyi deneyin. /priv/doc/https://example.com.

Tıkla Ön izleme Signed Exchange ve imzası hakkında daha fazla bilgi görmek için sekmesini tıklayın.

Bir kullanarak imzalı değişimleri sunun CanSignHttpExchanges sertifika #

Bu bölümdeki talimatlar, SXG’lerin bir ağ kullanılarak nasıl sunulacağını açıklar. CanSignHttpExchanges sertifika. SXG’lerin üretim kullanımı için bir CanSignHttpExchanges sertifika.

Kısa olması adına, bu yönergeler, Kendinden imzalı bir sertifika kullanarak İmzalı Değişim Kurulumu bölümünde açıklanan kavramları anladığınız varsayılarak yazılmıştır.

Önkoşullar #

• sende var CanSignHttpExchanges sertifika. Bu sayfa bu tür sertifika sunan CA’ları listeler.

• Sertifikanız yoksa, webpkgserver’ınızı sertifikaları CA’nızdan otomatik olarak alacak şekilde yapılandırabilirsiniz. İçeri girenler için yönergeleri takip edebilirsiniz. webpkgserver.toml bunda sayfa.

• Bir gereklilik olmasa da çalıştırmanız şiddetle tavsiye edilir. webpkgserver bir uç sunucunun arkasında. Edge sunucusu kullanmıyorsanız, yapılandırmanız gerekir. TLS.PEMFile Ve TLS.KeyFile seçenekleri webpkgserver.toml. Varsayılan olarak, webpkgserver HTTP üzerinden çalışır. Ancak SXG sertifikalarının tarayıcı tarafından geçerli kabul edilmesi için HTTPS üzerinden sunulması gerekir. yapılandırma TLS.PEMFile Ve TLS.KeyFile izin verir webpkgserver HTTPS kullanmak ve dolayısıyla SXG sertifikasını doğrudan tarayıcıya sunmak.

Talimatlar #

1. Sitenizin SXG sertifikasını ve ardından sitenizin CA sertifikasını birleştirerek bir PEM dosyası oluşturun. Bununla ilgili daha fazla talimat bulunabilir Burada.

   PEM birden çok sertifikayı depolamak için genellikle bir “kapsayıcı” olarak kullanılan bir dosya biçimidir.

2. taze oluştur webpkgsever.toml örneği kopyalayarak dosya.

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

3. Açık webpkgserver.toml Seçtiğiniz editörle ve aşağıdaki değişiklikleri yapın:

   • çizgiyi değiştir PEMFile = cert.pem tüm sertifika zincirinizi içeren PEM dosyasının konumunu yansıtmak için.
   • çizgiyi değiştir KeyFile="priv.key" PEM Dosyanıza karşılık gelen özel anahtarın konumunu yansıtmak için.
   • çizgiyi değiştir Domain = 'example.org' sitenizi yansıtmak için.
   • (İsteğe bağlı) sahip olmak webpkgserver SXG sertifikasını her 90 günde bir (Google için 45 gün) otomatik olarak yenileyin, [SXG.ACME] bölümü webpkgserver.toml. Bu seçenek yalnızca DigiCert veya Google ACME hesabı kurulumuna sahip siteler için geçerlidir.

4. Uç sunucunuzu trafiği şuraya iletecek şekilde yapılandırın: webpkgserver misal.

   tarafından işlenen iki temel istek türü vardır. webpkgserver: SXG istekleri (bunlar /priv/doc/ uç nokta) ve SXG sertifikası talepleri (bunlar /webpkg/cert/ bitiş noktası). Bu istek türlerinin her biri için URL yeniden yazma kuralları biraz farklılık gösterir. Daha fazla bilgi için bakınız Ön uç sunucunun arkasında çalışıyor.

   Not:

   Varsayılan olarak, webpkgserver SXG sertifikasını şu adreste sunar: /webpkg/cert/$CERT_HASH-Örneğin, /webpkg/cert/-0QmE0gvoedn92gtwI3s7On9zPevJGm5pn2RYhpZxgY. Üretmek $CERT_HASHaşağıdaki komutu çalıştırın:

   openssl base64 -in cert.pem -d | openssl dgst -sha256 -binary | base64 | tr /+ _- | tr -d =