نحوه راه اندازی Signed Exchanges با استفاده از Web Packager

نحوه ارائه خدمات مبادلات امضا شده (SXG) با استفاده از بسته‌بندی وب را بیاموزید.

کیتی همپنیوس
Katie Hempenius
X

صرافی امضا شده (SXG) مکانیزم تحویل است که احراز هویت مبدأ یک منبع را مستقل از نحوه تحویل آن ممکن می‌سازد. دستورالعمل های زیر نحوه راه اندازی Signed Exchanges با استفاده از Web Packager را توضیح می دهد. دستورالعمل ها برای گواهینامه های خودامضا و 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")

    این دستور از کلید خصوصی و CSR ایجاد شده در مراحل 1 و 2 برای ایجاد فایل گواهی 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 نیاز خواهید داشت.

سرور Web Packager را برای آزمایش راه اندازی کنید

پیش نیازها

  1. Web Packager را نصب کنید.

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

  2. webpkgserver را بسازید.

    cd webpackager/cmd/webpkgserver
go build .

    webpkgserver یک باینری خاص در پروژه Web Packager است.

  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 .

    توجه داشته باشید:

    ممکن است لازم باشد این دستور را طوری تنظیم کنید که مکان کروم روی دستگاه شما و همچنین مکان cert.pem را نشان دهد. اگر این کار را به درستی انجام داده باشید، باید یک هشدار در زیر نوار آدرس نمایش داده شود. هشدار باید مشابه این باشد You are using an unsupported command-line flag: --ignore-certificate-errors-spki-list=9uxADcgc6/ho0mJLRMBcOjfBaN21k0sOInoMchr9CMY=.

    اگر اخطار شامل رشته هش نباشد، مکان گواهی SXG را به درستی نشان نداده‌اید.

  6. برگه DevTools Network را باز کنید، سپس از URL زیر دیدن کنید: http://localhost:8080/priv/doc/https://example.com .

    این یک درخواست به نمونه webpackager در حال اجرا در http://localhost:8080 برای یک SXG حاوی محتویات https://example.com می دهد. /priv/doc/ نقطه پایانی پیش‌فرض API است که توسط webpackager استفاده می‌شود.

    تصویری از برگه DevTools Network که یک SXG و گواهی آن را نشان می دهد.

    منابع زیر در تب Network فهرست شده اند:

    • منبعی با نوع signed-exchange . این SXG است.
    • منبعی با نوع cert-chain+cbor . این گواهی SXG است. گواهینامه های SXG باید از فرمت application/cert-chain+cbor استفاده کنند.
    • منبعی با نوع document این محتوایی است که از طریق SXG ارائه شده است.

    اگر این منابع را نمی‌بینید، حافظه پنهان مرورگر را پاک کنید، سپس http://localhost:8080/priv/doc/https://example.com دوباره بارگیری کنید.

    برای مشاهده اطلاعات بیشتر در مورد Signed Exchange و امضای آن، روی تب Preview کلیک کنید.

    اسکرین شات از برگه پیش نمایش که یک SXG را نشان می دهد

صرافی های امضا شده را با استفاده از گواهی CanSignHttpExchanges ارائه دهید

دستورالعمل های این بخش نحوه سرویس دهی به SXG ها با استفاده از گواهی CanSignHttpExchanges را توضیح می دهد. استفاده تولیدی از SXG به گواهی CanSignHttpExchanges نیاز دارد.

برای اختصار، این دستورالعمل‌ها با این فرض نوشته شده‌اند که مفاهیم بحث‌شده در Setup Signed Exchanges را با استفاده از بخش گواهی خودامضا می‌فهمید.

پیش نیازها

  • شما یک گواهی CanSignHttpExchanges دارید. این صفحه CA هایی را که این نوع گواهی را ارائه می دهند فهرست می کند.

  • اگر گواهی ندارید، می توانید سرور webpkg خود را طوری پیکربندی کنید که به طور خودکار گواهی ها را از CA شما بازیابی کند. می توانید دستورالعمل های مربوط به آنچه در webpkgserver.toml در این صفحه وجود دارد را دنبال کنید.

  • اگرچه الزامی نیست، اما اکیداً توصیه می شود که webpkgserver در پشت سرور لبه اجرا کنید. اگر از سرور لبه استفاده نمی کنید، باید گزینه های TLS.PEMFile و TLS.KeyFile را در webpkgserver.toml پیکربندی کنید. به طور پیش فرض، webpkgserver از طریق HTTP اجرا می شود. با این حال، گواهی‌های SXG باید از طریق HTTPS ارائه شوند تا توسط مرورگر معتبر تلقی شوند. پیکربندی TLS.PEMFile و TLS.KeyFile به webpkgserver اجازه می دهد تا از HTTPS استفاده کند و بنابراین گواهی SXG را مستقیماً به مرورگر ارائه دهد.

دستورالعمل ها

  1. با الحاق گواهی SXG سایت خود و سپس گواهی CA سایت خود، یک فایل PEM ایجاد کنید. دستورالعمل های بیشتر در این مورد را می توان در اینجا یافت.

    PEM یک فرمت فایل است که معمولاً به عنوان یک "کانتینر" برای ذخیره چندین گواهی استفاده می شود.

  2. با کپی کردن مثال، یک فایل webpkgsever.toml تازه ایجاد کنید.

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

  3. webpkgserver.toml با ویرایشگر انتخابی خود باز کنید و تغییرات زیر را اعمال کنید:

    • خط PEMFile = cert.pem تغییر دهید تا مکان فایل PEM حاوی زنجیره کامل گواهی شما را منعکس کند.
    • خط KeyFile = 'priv.key' تغییر دهید تا مکان کلید خصوصی مربوط به فایل PEM شما منعکس شود.
    • خط Domain = 'example.org' را تغییر دهید تا سایت شما را منعکس کند.
    • (اختیاری) برای تمدید خودکار گواهینامه SXG webpkgserver هر 90 روز (45 روز برای Google)، گزینه‌ها را در بخش [SXG.ACME] webpkgserver.toml پیکربندی کنید. این گزینه فقط برای سایت هایی اعمال می شود که دارای تنظیمات حساب DigiCert یا Google ACME هستند.

  4. سرور لبه خود را برای ارسال ترافیک به نمونه webpkgserver پیکربندی کنید.

    دو نوع اصلی درخواست وجود دارد که توسط webpkgserver رسیدگی می‌شود: درخواست‌های SXG (که توسط نقطه پایانی /priv/doc/ ارائه می‌شوند) و درخواست‌های گواهی SXG (که توسط نقطه پایانی /webpkg/cert/ ارائه می‌شوند). قوانین بازنویسی URL برای هر یک از این انواع درخواست کمی متفاوت است. برای اطلاعات بیشتر، به اجرای پشت سرور لبه جلویی مراجعه کنید.

    توجه داشته باشید:

    به‌طور پیش‌فرض، webpkgserver گواهینامه SXG را در /webpkg/cert/$CERT_HASH ارائه می‌کند — به عنوان مثال، /webpkg/cert/-0QmE0gvoedn92gtwI3s7On9zPevJGm5pn2RYhpZxgY . برای تولید $CERT_HASH ، دستور زیر را اجرا کنید: shell openssl base64 -in cert.pem -d | openssl dgst -sha256 -binary | base64 | tr /+ _- | tr -d =