گواهی‌های TLS در Webship: CA داخلی ACME

# گواهی‌های TLS در Webship: CA تعبیه‌شده ACME

یک گواهی TLS دو وظیفه دارد: به رمزگذاری یک اتصال کمک می‌کند و به مشتری می‌گوید با کدام هویت در حال صحبت است. رمزگذاری می‌تواند قوی باشد در حالی که تصمیم اعتماد برای مخاطب اشتباه است. به همین دلیل، خودکارسازی گواهی باید با یک سؤال شروع شود: چه کسی باید به این سایت اعتماد کند؟

Webship 1.4.0 این انتخاب را به طور مستقل برای هر سایت پیکربندی شده انجام می‌دهد. یک وب‌سایت عمومی می‌تواند از گواهینامه ACME مورد اعتماد مرورگر استفاده کند، یک سرویس داخلی می‌تواند از مرکز صدور گواهینامه خصوصی تعبیه‌شده Webship استفاده کند، و سایتی با PKI موجود می‌تواند فایل‌های گواهینامه مدیریت شده توسط اپراتور را نگه دارد. همه آنها می‌توانند یک فرآیند Webship را بدون به اشتراک گذاشتن یک کلید خصوصی یا یک مرز اعتماد مشترک، به اشتراک بگذارند.

چهار حالت گواهی‌نامه خودکار، انتخاب شده برای هر سایت

فیلد certificate_mode به هر ورودی [[sites]] تعلق دارد. این یک سوئیچ سراسری نیست.

| حالت | منبع قابل اعتماد | بهترین مطابقت | مسیر اعتبارسنجی | | --- | --- | --- | --- | | per_site | فروشگاه‌های اعتماد مرورگر و سیستم‌عامل عمومی | یک سایت عمومی با یک نام میزبان دقیق | ACME عمومی با TLS-ALPN-01 | | ناوگان | فروشگاه‌های اعتماد مرورگر عمومی و سیستم‌عامل | مجموعه‌های بزرگ نام‌های سطح سوم و چهارم تحت دامنه‌های ثبت‌شده مشخص | ACME عمومی با DNS-01 و بخش‌های گواهینامه پایدار | | جاسازی شده | یک روت خصوصی Webship که توسط اپراتور نصب شده است | خدمات داخلی، دستگاه‌های مدیریت‌شده، ناوگان خصوصی و محیط‌های آزمایشی | صدور درون‌فرآیندی؛ بدون چالش خارجی | | مشترک | فروشگاه‌های اعتماد مرورگر و سیستم‌عامل عمومی | استقرارهای قدیمی که عمداً از یک گروه چند نام‌دامنه عمومی استفاده می‌کنند | ACME عمومی با TLS-ALPN-01 |

پیش‌فرض per_site است. این یک گواهی عمومی برای نام دقیق سایت سفارش می‌دهد. حالت Fleet گزینه عمومی مقیاس‌پذیر برای بسیاری از زیردامنه‌های عمیق است. حالت Embedded از CA خصوصی درون‌فرآیندی Webship استفاده می‌کند. حالت Shared برای سازگاری همچنان در دسترس است، اما پیش‌فرض نیست.

یک گواهی‌نامه و کلید کامل تحت [sites.tls] همیشه بر صدور خودکار برای آن سایت تقدم دارد.

منظور از «ACME CA تعبیه‌شده» چیست

بخش پیکربندی با نام [acme_ca] مشخص شده است، اما مرکز صدور گواهی (CA) تعبیه‌شده یک سرویس ACME عمومی یا قابل دسترسی از طریق شبکه نیست. هیچ نقطه پایانی دایرکتوری ارائه نمی‌دهد، ثبت‌نام از راه دور را نمی‌پذیرد، هیچ API ثبت‌کننده‌ای را فراخوانی نمی‌کند و هیچ چالش اثبات کنترل انجام نمی‌دهد.

در عوض، Webship کل مسیر انتشار خصوصی را در یک فرآیند نگه می‌دارد:

1. سایت certificate_mode = "embedded" را انتخاب می‌کند.
2. Webship هویت ریشه خصوصی را در دایرکتوری وضعیت پیکربندی‌شده بارگذاری یا ایجاد می‌کند.
3. Webship یک کلید خصوصی جدید برای سایت تولید می‌کند.
4. ریشه تعبیه‌شده یک گواهی برگ برای همان نام دقیق صادر می‌کند.
5. Webship هویت تکمیل‌شده را قبل از نصب آن در حل‌کننده TLS زنده اعتبارسنجی می‌کند.
6. سپس گواهی برای هر پروتکل فعال شده در آن سایت در دسترس است.

یک چالش شبکه به سبک ACME تنها Webship را به خودش اثبات می‌کند، بنابراین مسیر جاسازی شده عمداً هیچ پروتکل شبکه‌ای ندارد. بخش [acme_ca] وضعیت PKI خصوصی است: جایی که ریشه قرار دارد و مدت زمان اعتبار گواهی‌های صادر شده برگ را تعریف می‌کند.

پیکربندی یک گواهی تعبیه شده برای یک سایت

این حداقل شکل برای یک سایت خصوصی است:

~~~تامل listen = "0.0.0.0:443"

[تی‌ال‌اس] unknown_sni = "رد کردن"

[خودکار_tls] فعال = درست cache_dir = "/var/lib/webship/acme"

[acme_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = ۹۰

[[وب‌سایت‌ها]] دامنه = "service.internal.example" root = "/srv/service" certificate_mode = "embedded"

[سایت‌ها.پروتکل‌ها] h1 = درست h2 = درست h3 = درست ~~~

هویت ریشه به صورت تنبل ایجاد می‌شود زمانی که یک سایت جاسازی شده برای اولین بار آن را نیاز دارد. Webship کلید ریشه را با مجوزهای محدود در state_dir نگهداری می‌کند. گواهی‌نامه ریشه دارای عمر ده ساله است؛ عمر برگ توسط leaf_validity_days کنترل می‌شود.

هر دو محل ذخیره‌سازی را به عنوان حالت تولید در نظر بگیرید:

• کش ACME هویت‌های سایت به‌طور خودکار مدیریت‌شده را نگه می‌دارد.
• دایرکتوری وضعیت CA تعبیه شده، هویت ریشه خصوصی را نگه می‌دارد.
• حساب سرویس نیاز به دسترسی دارد، اما کاربران برنامه ندارند.
• نسخه‌های پشتیبان باید محرمانگی و مجوزهای فایل را حفظ کنند.
• تولید، توسعه و آزمایش باید از ریشه‌ها و دایرکتوری‌های جداگانه استفاده کنند.

حذف دایرکتوری ریشه باعث «بازنشانی TLS» نمی‌شود. این کار یک نقطه اعتماد جدید ایجاد می‌کند. کلاینت‌هایی که به ریشه قدیمی اعتماد دارند، گواهی‌های صادر شده توسط جایگزین را تا زمانی که مخازن اعتماد آن‌ها به‌روزرسانی شود، رد خواهند کرد.

اعتماد خصوصی عمدی است

گواهی‌نامه‌های صادر شده از CA داخلی به‌طور خودکار توسط مرورگرهای عمومی یا سیستم‌عامل‌ها مورد اعتماد قرار نمی‌گیرند. آنها تنها پس از اینکه اپراتور گواهی ریشه صادر شده Webship را در فروشگاه اعتماد کلاینت نصب کند، مورد اعتماد قرار می‌گیرند.

این باعث می‌شود حالت تعبیه‌شده برای موارد زیر مناسب باشد:

• لپ‌تاپ‌ها و تلفن‌های همراه مدیریت‌شده توسط شرکت که از طریق مدیریت دستگاه ثبت شده‌اند؛
• ترافیک داخلی سرویس به سرویس با یک بسته CA صریح؛
• دستگاه‌های خصوصی و ناوگان‌های لبه کنترل‌شده؛
• محیط‌های توسعه و آزمایش که باید رفتار واقعی TLS را اجرا کنند؛
• شبکه‌های جدا شده که نمی‌توانند به یک مرجع صدور گواهی عمومی تکیه کنند.

این حالت برای یک وب‌سایت عادی عمومی که بازدیدکنندگان آن از مرورگرهای مدیریت‌نشده استفاده می‌کنند، مناسب نیست. برای یک نام عمومی دقیق از صدور per_site عمومی استفاده کنید، برای مجموعه‌های زیردامنه عمومی بزرگ از صدور fleet استفاده کنید، فقط برای یک استقرار چند SAN قدیمی و عمدی از shared استفاده کنید، یا از فایل‌های دستی از PKI که قبلاً اعتماد شده است استفاده کنید.

فقط گواهی ریشه را به مشتریان توزیع کنید. هرگز کلید خصوصی ریشه را توزیع نکنید. داشتن آن کلید به دارنده‌اش اجازه می‌دهد هویت‌هایی صادر کند که توسط هر مشتری ثبت‌شده اعتماد شوند.

گواهی‌های عمومی و خصوصی می‌توانند همزیستی داشته باشند

Webship 1.4.0 می‌تواند استراتژی‌های گواهی را در همان شنونده ترکیب کند:

~~~تامل listen = "0.0.0.0:443"

[تی‌ال‌اس] unknown_sni = "رد کردن"

[خودکار_tls] فعال = درست directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" contacts = ["mailto:ops@example.com"] پذیرفتن_شرایط_خدمات = درست

[acme_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = ۹۰

[[وب‌سایت‌ها]] دامنه = "www.example.com" root = "/srv/public" certificate_mode = "per_site"

[[وب‌سایت‌ها]] دامنه = "control.internal.example" root = "/srv/control" certificate_mode = "embedded"

[[وب‌سایت‌ها]] دامنه = "payments.example.com" root = "/srv/payments"

[سایت‌ها.tls] cert = "/etc/webship/payments-fullchain.pem" کلید = "/etc/webship/payments-private-key.pem" ~~~

در اینجا، www.example.com گواهی ACME عمومی خود را دریافت می‌کند. control.internal.example یک گواهی خصوصی از CA داخلی دریافت می‌کند. payments.example.com تحت PKI خارجی اپراتور باقی می‌ماند زیرا فایل‌های صریح آن اولویت دارند.

دایرکتوری عمومی ACME توسط سایت‌های تعبیه شده نادیده گرفته می‌شود. ریشه‌ی تعبیه شده هرگز سایت عمومی را امضا نمی‌کند. سایت دستی هرگز به طور پنهانی در هیچ یک از جریان‌های کاری خودکار ثبت نمی‌شود.

یک حل‌کننده گواهینامه برای H1، H2، H3، و WebTransport

انتخاب گواهی در طول دست دادن TLS اتفاق می‌افتد، قبل از اینکه درخواست HTTP وجود داشته باشد. Webship از نام سرور ClientHello برای انتخاب هویت سایت استفاده می‌کند و سپس پروتکل برنامه را مذاکره می‌کند.

• HTTP/1.1 و HTTP/2 از TLS روی TCP استفاده می‌کنند.
• HTTP/3 و WebTransport از TLS در داخل QUIC بر بستر UDP استفاده می‌کنند.
• یک هویت سایت معتبر می‌تواند به هر پروتکل فعال خدمات دهد.
• HTTP/3 همچنین نیاز به دسترسی UDP دارد؛ H1 و H2 از مسیر TCP استفاده می‌کنند.
• Alt-Svc می‌تواند H3 را تبلیغ کند در حالی که پشتیبان TCP را حفظ می‌کند.

TCP، TLS و QUIC از همان مدل هویت آگاه به سایت استفاده می‌کنند. نام‌های دقیق ارجحیت دارند، طولانی‌ترین کاراکتر جایگزین معتبر در جایی که گواهینامه‌های wildcard پیکربندی شده‌اند برنده است، و SNI نامعلوم می‌تواند به جای دریافت یک گواهینامه پیش‌فرض غیر مرتبط رد شود.

از unknown_sni = "reject" در یک شنونده چندسایته استفاده کنید زمانی که یک نام میزبانی ناشناخته باید به‌صورت بسته 실패 شود. قبل از راه‌اندازی در محیط تولید، نام‌های شناخته‌شده، نام‌های ناشناخته و رفتار پیش‌بینی‌شده بدون SNI خود را آزمایش کنید.

چرخاندن هویت‌های تعبیه‌شده بدون فاصله سرویس‌دهی

Webship وضعیت گواهی و تغییرات کنترل‌شده را از طریق سرور MCP تأییدشده و محدود به لوپ‌بک خود افشا می‌کند:

• webship.tls.get_status وضعیت حل‌کننده گواهی فعال و وضعیت تمدید را گزارش می‌دهد.
• webship.tls.reissue_certificate بلافاصله تنها زمانی که سایت از حالت تعبیه شده استفاده می‌کند، یک سایت به‌طور خودکار مدیریت‌شده را مجدداً صدور می‌کند.
• webship.tls.reload وضعیت گواهی را از طریق مسیر TLS محافظت‌شده معمولی بارگذاری مجدد می‌کند.
• webship.acme_ca.status گزارش می‌دهد که آیا CA خصوصی انتخاب شده است، دایرکتوری وضعیت آن، طول عمر برگ، تعداد صدور، تعداد لغو و نمونه‌های اخیر دامنه.
• webship.sites.apply سایت‌ها را بر اساس یک نسخه پیکربندی سنجاق شده اضافه یا حذف می‌کند.

برای یک بازانتشار توکار، Webship جایگزین را ایجاد و اعتبارسنجی می‌کند قبل از اینکه آن را وارد خدمت کند. هویت معتبر فعلی تا آماده شدن هویت جدید به خدمت ادامه می‌دهد. هویت بازنشسته تنها پس از نصب جایگزین ثبت می‌شود.

عملیات بازتوزیع فوری عمداً گواهینامه‌های عمومی per_site را رد می‌کند. تمدید عمومی باید در داخل چرخه عمر عمومی ACME باقی بماند و نباید با امضا خصوصی در حال پردازش اشتباه شود. عضویت در حالت مشترک نیز به دلیل بازسازی مرز هویت در صورت تغییر یک گروه multi-SAN، مجدداً مسدود شده است.

MCP یک سطح کنترل اختصاصی است. آن را در حالت لوپ‌بک نگه دارید، به TLS و یک توکن باربر قوی نیاز داشته باشید، از تونل احراز هویت شده برای مدیریت از راه دور استفاده کنید و هر تغییر را بررسی و ممیزی کنید.

مرزهای شکست که اهمیت دارند

یک سیستم گواهینامه امن باید در جهت صحیح شکست بخورد.

• یک سایت تعبیه‌شده تازه پیکربندی شده، در حالی که صدور در انتظار است، هویت سایت دیگری را دریافت نمی‌کند.
• یک جایگزین نامعتبر روی گواهی‌نامه‌ای که در حال کار است نصب نمی‌شود.
• فایل‌های دستی صریح از به‌طور خودکار مالک شدن آن سایت جلوگیری می‌کنند.
• SNI با نام ناشناس می‌تواند قبل از مسیریابی HTTP رد شود.
• CA تعبیه‌شده خصوصی باقی می‌ماند و هیچ نقطه ثبت‌نام از راه دوری ندارد.
• شناسه‌های عمومی و جاسازی‌شده از مسیرهای کش جداگانه در داخل وضعیت TLS خودکار استفاده می‌کنند.

هشداری مبنی بر اینکه CA جاسازی شده مقداردهی اولیه نشده است، به این معنی است که Webship نتوانسته دایرکتوری حالت پیکربندی شده را فعال کند. قبل از ارسال ترافیک به سایت مورد نظر، مالکیت، مجوزها، پایداری یا دسترسی به ذخیره‌سازی را اصلاح کنید. خطا را با کپی کردن کلید ریشه از محیط دیگر دور نزنید.

چک‌لیست تولید

قبل از فعال‌سازی حالت جاسازی شده:

1. هر جمعیت مشتری‌ای را که باید به سایت اعتماد کنند شناسایی کنید.
2. یک فرآیند کنترل‌شده برای صادرات و نصب گواهی ریشه ایجاد کنید.
3. برای تولید، توسعه و تست از حالت ریشه جداگانه استفاده کنید.
4. دائمی و محافظت از دایرکتوری وضعیت CA جاسازی شده و کش TLS خودکار.
5. اجرای Webship تحت یک حساب سرویس اختصاصی با دسترسی تنها به مواد کلیدی مورد نیاز.
6. در هر سایتی که مرز اعتماد آن باید صریح باشد، certificate_mode را انتخاب کنید.
7. سیاست SNI ناشناخته را تنظیم و تست کنید.
8. فعال‌سازی H1، H2 و H3 به‌طور عمدی و بررسی هر دو مسیر TCP و UDP.
9. تمرین صدور مجدد، راه‌اندازی مجدد، پشتیبان‌گیری، بازیابی و اعتبارسنجی اعتماد مشتری خارج از محیط تولید.
10. قبل از اجرای rollout، دستور webship --check-config را اجرا کنید، سپس صادرکننده، نام‌ها، اعتبار، زنجیره و پروتکل‌های مذاکره‌شده را از یک کلاینت واقعی بررسی کنید.

ابتدا اعتماد را انتخاب کنید، دوم اتوماسیون

CA تعبیه‌شده وابستگی به سرویس گواهی‌نامه خارجی برای زیرساخت خصوصی را حذف می‌کند. این امر باعث نمی‌شود یک ریشه خصوصی به طور جهانی معتبر شود، و مسئولیت‌های PKI اپراتور را حذف نمی‌کند.

Webship تولید کلید، امضا، اعتبارسنجی، نصب، چرخش و انتخاب گواهی در سطح پروتکل را خودکار می‌کند. اپراتور همچنان مالک نگهداری ریشه، ثبت‌نام مشتری، جداسازی محیط، پشتیبان‌گیری، بازیابی و تصمیم‌گیری برای استفاده از مسیر اعتماد عمومی یا خصوصی است.

آن جدایی ویژگی است. یک سرور مستقل می‌تواند TLS خصوصی را بدون تظاهر به یک CA عمومی خودکار کند و سایت‌های عمومی هنوز هم می‌توانند از صدور مخصوص سایت یا ناوگان مورد اعتماد مرورگر در همان فرآیند استفاده کنند.

نسخه مستندات Webship 1.4.0 را قبل از پیاده‌سازی بخوانید. RFC 5280 پروفایل‌ها و اعتبارسنجی گواهینامه را تعریف می‌کند، RFC 6066 سیگنال‌دهی نام سرور TLS را تعریف می‌کند، RFC 8446 TLS 1.3 را تعریف می‌کند، RFC 8555 ACME عمومی را تعریف می‌کند و RFC 9525 تایید هویت سرویس را تعریف می‌کند.