Quay lại blog Webship

Kỹ thuật Webship

Chứng chỉ TLS trong Webship: ACME CA được nhúng

Xem cách Webship 1.4.0 phát hành và xoay vòng các chứng chỉ TLS riêng cho từng site với CA nhúng của nó, cách mà độ tin cậy của client hoạt động, và cách các danh tính nhúng cùng tồn tại với chứng chỉ ACME công khai và chứng chỉ thủ công.

# Chứng chỉ TLS trong Webship: ACME CA được nhúng

Chứng chỉ TLS thực hiện hai nhiệm vụ: nó giúp mã hóa kết nối và thông báo cho khách hàng biết nó đang nói chuyện với ai. Mã hóa có thể mạnh trong khi quyết định tin cậy lại sai đối với khán giả. Đó là lý do tại sao việc tự động hóa chứng chỉ phải bắt đầu với một câu hỏi: ai phải tin tưởng trang web này?

Webship 1.4.0 tự đưa ra lựa chọn đó cho từng trang web đã được cấu hình. Một trang web công cộng có thể sử dụng chứng chỉ ACME được trình duyệt tin cậy, một dịch vụ nội bộ có thể sử dụng cơ quan chứng chỉ tư nhân nhúng của Webship, và một trang web có PKI hiện có có thể giữ các tệp chứng chỉ do người vận hành quản lý. Tất cả đều có thể dùng chung một tiến trình Webship mà không cần chia sẻ cùng một khóa riêng hay một ranh giới tin cậy.

Bốn chế độ chứng chỉ tự động, được lựa chọn theo từng trang

Trường certificate_mode thuộc về mỗi mục [[sites]]. Nó không phải là một công tắc toàn cục.

| Chế độ | Nguồn đáng tin cậy | Phù hợp nhất | Đường dẫn xác thực | | --- | --- | --- | --- | | per_site | Kho lưu trữ tin cậy trình duyệt và hệ điều hành công cộng | Một trang công cộng với một tên máy chủ chính xác | ACME công cộng với TLS-ALPN-01 | | đội tàu | Kho lưu trữ tin cậy của trình duyệt công cộng và hệ điều hành | Các bộ lớn tên cấp ba và cấp bốn dưới các miền đã đăng ký rõ ràng | ACME công cộng với DNS-01 và các mảnh chứng chỉ ổn định | | nhúng | Một root Webship riêng tư được cài đặt bởi người vận hành | Dịch vụ nội bộ, thiết bị được quản lý, đội xe riêng và môi trường thử nghiệm | Phát hành trong quy trình; không có thử thách bên ngoài | | chia sẻ | Kho tin cậy trình duyệt công khai và hệ điều hành | Triển khai kế thừa sử dụng cố ý một nhóm đa SAN công khai | ACME công khai với TLS-ALPN-01 |

Mặc định là per_site. Nó đặt một chứng chỉ công khai cho đúng tên của trang web. Chế độ Fleet là tùy chọn công khai có thể mở rộng cho nhiều tên miền phụ sâu. Chế độ Embedded sử dụng CA riêng trong quá trình của Webship. Chế độ Shared vẫn khả dụng để tương thích, nhưng nó không phải là mặc định.

Một chứng chỉ và khóa hoàn chỉnh dưới [sites.tls] luôn được ưu tiên hơn việc cấp phát tự động cho trang đó.

“ACME CA nhúng” có nghĩa là gì

Phần cấu hình được đặt tên là [acme_ca], nhưng CA nhúng không phải là dịch vụ ACME công khai hoặc có thể truy cập qua mạng. Nó không cung cấp điểm cuối thư mục nào, không chấp nhận đăng ký từ xa, không gọi API của registrar và không thực hiện thử thách xác nhận quyền kiểm soát.

Thay vào đó, Webship giữ toàn bộ đường dẫn phát hành riêng trong một quy trình:

  1. Trang web chọn certificate_mode = "embedded".
  2. Webship tải hoặc tạo danh tính gốc riêng trong thư mục trạng thái được cấu hình.
  3. Webship tạo một khóa riêng mới cho trang web.
  4. Hạt nhân nhúng ký một chứng chỉ lá cho đúng tên đó.
  5. Webship xác thực danh tính đã hoàn tất trước khi cài đặt nó vào bộ giải quyết TLS trực tiếp.
  6. Chứng chỉ sau đó có sẵn cho mọi giao thức được kích hoạt trên trang web đó.

Một thử thách mạng kiểu ACME chỉ chứng minh cho Webship với chính nó, vì vậy đường dẫn nhúng cố ý không có giao thức mạng. Phần [acme_ca] là trạng thái PKI riêng tư: nó định nghĩa nơi root tồn tại và bao lâu các chứng chỉ leaf đã cấp vẫn còn hiệu lực.

Cấu hình chứng chỉ nhúng cho một trang web

Đây là hình dạng tối thiểu cho một trang web riêng tư:

~~~toml nghe = "0.0.0.0:443"

[tls] unknown_sni = "từ chối"

[tự_động_tls] bật = đúng cache_dir = "/var/lib/webship/acme"

[acme_ca] state_dir = "/var/lib/webship/acme-ca" số_ngày_hợp_lệ_của_lá = 90

[[các trang web]] domain = "service.internal.example" root = "/srv/service" certificate_mode = "nhúng"

[sites.protocols] h1 = đúng h2 = đúng h3 = đúng ~~~

Định danh gốc được tạo một cách lười biếng khi một trang web nhúng lần đầu tiên cần nó. Webship lưu trữ khóa gốc với quyền hạn chế trong state_dir. Chứng chỉ gốc có thời hạn mười năm; thời hạn của chứng chỉ lá được kiểm soát bởi leaf_validity_days.

Xem cả hai vị trí lưu trữ như trạng thái sản xuất:

  • Bộ nhớ đệm ACME lưu trữ các nhận dạng trang web được quản lý tự động.
  • Thư mục trạng thái embedded-CA chứa nhận dạng gốc riêng tư.
  • Tài khoản dịch vụ cần quyền truy cập, nhưng người dùng ứng dụng thì không.
  • Các bản sao lưu phải bảo vệ tính bảo mật và quyền truy cập tệp.
  • Sản xuất, phát triển và thử nghiệm nên sử dụng các thư mục gốc riêng và các thư mục riêng biệt.

Xóa thư mục gốc không “đặt lại TLS.” Nó tạo ra một điểm tin cậy mới. Các client tin tưởng vào root cũ sẽ từ chối các chứng chỉ được cấp bởi thay thế cho đến khi kho tin cậy của chúng được cập nhật.

Quỹ tín thác tư nhân là có chủ ý

Chứng chỉ từ CA nhúng không tự động được các trình duyệt công khai hoặc hệ điều hành tin cậy. Chúng chỉ trở nên tin cậy sau khi người vận hành cài đặt chứng chỉ gốc Webship đã xuất khẩu vào kho lưu trữ tin cậy của khách hàng.

Điều đó làm cho chế độ nhúng phù hợp với:

  • laptop và điện thoại do công ty quản lý được đăng ký qua quản lý thiết bị;
  • lưu lượng nội bộ giữa các dịch vụ với một gói chứng chỉ CA rõ ràng;
  • thiết bị gia dụng tư nhân và đội phương tiện biên được kiểm soát;
  • môi trường phát triển và kiểm thử phải thực thi hành vi TLS thực;
  • các mạng bị ngắt kết nối không thể phụ thuộc vào CA công cộng.

Đây không phải là chế độ phù hợp cho một trang web công khai thông thường mà người truy cập sử dụng trình duyệt không được quản lý. Sử dụng phát hành theo trang công cộng cho một tên công cộng chính xác, phát hành nhóm cho các tập hợp tên miền phụ công cộng lớn, chia sẻ chỉ cho một triển khai đa SAN kế thừa cố ý, hoặc sử dụng các tệp thủ công từ một PKI đã được tin cậy.

Chỉ phân phối chứng chỉ gốc cho các máy khách. Không bao giờ phân phối khóa riêng gốc. Việc sở hữu khóa đó cho phép người giữ nó có quyền cấp các danh tính được mọi máy khách đã đăng ký tin cậy.

Các chứng chỉ công khai và riêng tư có thể cùng tồn tại

Webship 1.4.0 có thể kết hợp các chiến lược chứng chỉ trên cùng một bộ lắng nghe:

~~~toml nghe = "0.0.0.0:443"

[tls] unknown_sni = "từ chối"

[tự_động_tls] bật = đúng directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" contacts = ["mailto:ops@example.com"] chấp_nhận_điều_khoản_dịch_vụ = đúng

[acme_ca] state_dir = "/var/lib/webship/acme-ca" số_ngày_hợp_lệ_của_lá = 90

[[các trang web]] domain = "www.example.com" root = "/srv/public" certificate_mode = "từng_trang"

[[các trang web]] domain = "control.internal.example" root = "/srv/control" certificate_mode = "embedded"

[[các trang web]] domain = "payments.example.com" root = "/srv/payments"

[sites.tls] cert = "/etc/webship/payments-fullchain.pem" key = "/etc/webship/payments-private-key.pem" ~~~

Ở đây, www.example.com nhận chứng chỉ ACME công cộng của riêng nó. control.internal.example nhận chứng chỉ riêng từ CA nhúng. payments.example.com vẫn thuộc PKI bên ngoài của nhà điều hành vì các tệp cụ thể của nó được ưu tiên.

Thư mục công khai ACME bị các trang nhúng bỏ qua. Root nhúng không bao giờ ký trang công khai. Trang thủ công không bao giờ được đăng ký âm thầm vào bất kỳ quy trình tự động nào.

Một trình giải quyết chứng chỉ cho H1, H2, H3 và WebTransport

Việc chọn chứng chỉ xảy ra trong quá trình bắt tay TLS, trước khi có yêu cầu HTTP. Webship sử dụng tên máy chủ ClientHello để chọn danh tính trang web và sau đó thương lượng giao thức ứng dụng.

  • HTTP/1.1 và HTTP/2 sử dụng TLS qua TCP.
  • HTTP/3 và WebTransport sử dụng TLS bên trong QUIC qua UDP.
  • Một nhận dạng trang hợp lệ có thể phục vụ cho mọi giao thức được bật.
  • HTTP/3 cũng yêu cầu khả năng tiếp cận UDP; H1 và H2 sử dụng đường dẫn TCP.
  • Alt-Svc có thể quảng bá H3 trong khi vẫn giữ được chế độ dự phòng TCP.

TCP, TLS và QUIC sử dụng cùng một mô hình nhận dạng theo trang. Tên chính xác được ưu tiên, ký hiệu đại diện hợp lệ dài nhất sẽ thắng khi cấu hình chứng chỉ đại diện, và SNI với tên không biết có thể bị từ chối thay vì nhận một chứng chỉ mặc định không liên quan.

Sử dụng unknown_sni = "reject" trên một listener đa site khi một hostname không được nhận dạng phải bị từ chối. Kiểm tra các tên được nhận dạng, các tên không được nhận dạng, và hành vi không SNI mong đợi của bạn trước khi triển khai vào môi trường sản xuất.

Xoay các nhận dạng nhúng mà không có khoảng trống phục vụ

Webship tiết lộ trạng thái chứng chỉ và các biến đổi có kiểm soát thông qua máy chủ MCP xác thực, ràng buộc vòng lặp của nó:

  • webship.tls.get_status báo cáo bộ giải mã chứng chỉ đang hoạt động và trạng thái gia hạn.
  • webship.tls.reissue_certificate ngay lập tức phát hành lại chứng chỉ cho một trang web được quản lý tự động chỉ khi trang đó sử dụng chế độ nhúng.
  • webship.tls.reload tải lại trạng thái chứng chỉ thông qua đường dẫn TLS bảo vệ bình thường.
  • webship.acme_ca.status báo cáo liệu CA riêng có được chọn, thư mục trạng thái của nó, thời hạn của chứng chỉ lá, số lượng phát hành, số lượng thu hồi và mẫu miền gần đây.
  • webship.sites.apply thêm hoặc loại bỏ các trang web dựa trên một phiên bản cấu hình đã ghim.

Đối với việc phát hành lại nhúng, Webship tạo và xác thực bản thay thế trước khi thay thế nó vào dịch vụ. Danh tính hợp lệ hiện tại tiếp tục phục vụ cho đến khi danh tính mới sẵn sàng. Danh tính đã nghỉ hưu chỉ được ghi lại sau khi bản thay thế được cài đặt.

Hoạt động phát hành lại ngay lập tức cố ý từ chối chứng chỉ per_site công khai. Việc gia hạn công khai phải vẫn nằm trong vòng đời ACME công khai thay vì bị nhầm lẫn với việc ký trong quá trình riêng tư. Thành viên chế độ chia sẻ cũng bị đóng băng khởi động lại vì thay đổi một nhóm multi-SAN sẽ xây dựng lại ranh giới nhận dạng.

MCP là một bề mặt điều khiển có đặc quyền. Giữ nó ở chế độ vòng lặp, yêu cầu TLS và một token bearer mạnh, sử dụng đường hầm xác thực để quản trị từ xa, và kiểm tra mọi sự thay đổi.

Ranh giới thất bại quan trọng

Một hệ thống chứng chỉ an toàn phải thất bại theo hướng đúng đắn.

  • Một trang web nhúng mới được cấu hình sẽ không nhận danh tính của trang web khác trong khi việc cấp phát đang chờ xử lý.
  • Một bản thay thế không hợp lệ không được cài đặt lên chứng chỉ đang hoạt động.
  • Các tệp hướng dẫn rõ ràng ngăn chặn việc tự động sở hữu trang web đó.
  • SNI có tên không xác định có thể bị từ chối trước khi định tuyến HTTP.
  • CA nhúng vẫn giữ riêng tư và không có điểm đăng ký từ xa.
  • Các định danh công khai và nhúng sử dụng các đường dẫn bộ nhớ đệm riêng bên trong trạng thái TLS tự động.

Một cảnh báo rằng CA nhúng chưa được khởi tạo có nghĩa là Webship không thể kích hoạt thư mục trạng thái đã cấu hình. Hãy sửa quyền sở hữu, quyền truy cập, tính bền vững hoặc khả năng lưu trữ trước khi gửi lưu lượng đến trang web bị ảnh hưởng. Không khắc phục lỗi bằng cách sao chép khóa gốc của môi trường khác.

Danh sách kiểm tra sản xuất

Trước khi bật chế độ nhúng:

  1. Xác định mọi nhóm khách hàng phải tin tưởng vào trang web.
  2. Tạo một quy trình kiểm soát để xuất khẩu và cài đặt chứng chỉ gốc.
  3. Sử dụng trạng thái gốc riêng cho sản xuất, phát triển và kiểm tra.
  4. Duy trì và bảo vệ thư mục trạng thái CA nhúng và bộ nhớ cache TLS tự động.
  5. Chạy Webship dưới một tài khoản dịch vụ riêng biệt chỉ có quyền truy cập vào các khóa cần thiết.
  6. Chọn certificate_mode trên mọi trang mà ranh giới tin cậy của nó phải rõ ràng.
  7. Đặt và kiểm tra chính sách SNI không xác định.
  8. Kích hoạt H1, H2 và H3 một cách có chủ ý và xác minh cả đường dẫn TCP và UDP.
  9. Thực hành phát hành lại, khởi động lại, sao lưu, khôi phục và xác thực tin cậy của khách hàng bên ngoài môi trường sản xuất.
  10. Chạy webship --check-config trước khi triển khai, sau đó xác minh nhà cấp phát, tên, thời hạn, chuỗi và các giao thức đã thương lượng từ một client thực.

Chọn tin tưởng trước, tự động hóa sau

CA nhúng loại bỏ sự phụ thuộc vào dịch vụ chứng chỉ bên ngoài cho hạ tầng riêng tư. Nó không làm cho gốc riêng tư được tin cậy toàn cầu, và nó cũng không loại bỏ trách nhiệm PKI của nhà vận hành.

Webship tự động hóa việc tạo khóa, ký, xác thực, cài đặt, luân chuyển và lựa chọn chứng chỉ trên toàn giao thức. Người vận hành vẫn sở hữu việc quản lý root, đăng ký khách hàng, tách biệt môi trường, sao lưu, phục hồi và quyết định sử dụng đường dẫn tin cậy công khai hay riêng tư.

Sự tách biệt đó chính là tính năng. Một máy chủ tự quản lý có thể tự động hóa TLS riêng tư mà không cần giả vờ là một CA công cộng—và các trang web công cộng vẫn có thể sử dụng việc cấp chứng chỉ theo từng trang hoặc theo nhóm được trình duyệt tin tưởng trong cùng một quy trình.

Đọc tài liệu Webship 1.4.0 đã được phiên bản hóa trước khi triển khai. RFC 5280 định nghĩa các hồ sơ và xác thực chứng chỉ, RFC 6066 định nghĩa báo hiệu tên máy chủ TLS, RFC 8446 định nghĩa TLS 1.3, RFC 8555 định nghĩa ACME công khai, và RFC 9525 định nghĩa xác minh danh tính dịch vụ.