Applies to: Chứng nhận SSL

Chứng nhận SSL Trợ giúp

Chúng tôi đã cố hết sức để dịch trang này cho bạn. Trang Tiếng Anh cũng có khả dụng.

Tại sao GoDaddy lại gỡ bỏ ClientAuth EKU và chuyển sang cấu trúc phân cấp gốc R1 để phát hành DV TLS?

Lưu ý: Nếu bạn hoặc khách hàng của bạn thấy lỗi "gốc không tin cậy" hoặc chuỗi chứng nhận, hãy xem các bước của chúng tôi để khắc phục sự cố .

Bắt đầu từ ngày 15 tháng 6 năm 2026, các chứng nhận SSL / TLS tin cậy công khai được cấp để sử dụng cho máy chủ sẽ không còn được phép sử dụng khóa mở rộng “Xác thực máy khách” (EKU: clientAuth). Dưới đây là những điểm chính cần hiểu:

  • Thay đổi này là một phần của cập nhật chính sách Chương trình gốc của Chrome: các chứng nhận mới chỉ được bao gồm EKU “Xác thực máy chủ”.
  • Các chứng nhận công khai mới được cấp sau ngày đó bao gồm cả clientAuth sẽ không được Chrome tin cậy.
  • Các chứng nhận được cấp bằng clientAuth trước ngày 15 tháng 6 năm 2026 sẽ không bị ảnh hưởng bởi thay đổi này và sẽ vẫn có hiệu lực cho đến khi chúng hết hạn hoặc bị thu hồi.
  • Chứng nhận Private-CA (để sử dụng nội bộ) không bị ảnh hưởng bởi thay đổi này & mdash; nó chỉ áp dụng cho các chứng nhận được tin cậy công khai.

Tóm lại: nếu tổ chức của bạn sử dụng chứng nhận TLS công khai để xác thực ứng dụng khách (thông qua clientAuth EKU), bạn sẽ cần hành động trước ngày 15 tháng 6 năm 2026 . Đối với việc sử dụng TLS thông thường của website (chỉ xác thực máy chủ), thay đổi này không yêu cầu hành động. Tuy nhiên, đây là một lời nhắc nhở kịp thời để xem lại chứng nhận sử dụng của bạn, phân tách các chức năng một cách thích hợp và đảm bảo bạn phù hợp với mô hình ủy thác đang phát triển.

Cách GoDaddy sẽ triển khai thay đổi này

Các trung gian ký kết / phát hành G2 hiện tại của chúng tôi không có bất kỳ EKU nào được liệt kê, điều này khiến hệ thống phân cấp đó không tuân thủ yêu cầu của Chương trình gốc của Chrome. Do đó, việc phát hành từ các sản phẩm trung gian G2 bị ảnh hưởng phải dừng lại trước ngày đó.

Thay vì tạo các trung gian phát hành mới trên chuỗi G2 & mdash; theo kế hoạch sẽ hết hạn / kết thúc với Google vào tháng 4 năm 2027 & mdash; chúng tôi sẽ chuyển việc phát hành DV sang hệ thống phân cấp R1 mới để đáp ứng các ràng buộc về chính sách trong tương lai.

Chúng tôi đang thay đổi chuỗi phát hành DV công khai để các chứng nhận lá DV mới được cấp từ phân cấp GoDaddy TLS gốc CA - R1, sử dụng GoDaddy TLS trung gian CA DV - R1v1 cấp chứng nhận CA.godaddy.com. Điều này có nghĩa là chuỗi nhà phát hành được trình bày bởi các máy chủ (lá + trung gian) có thể khác với những gì một số hệ thống đã thấy trong quá khứ và bất kỳ công cụ nội bộ nào giả định một tên trung gian kế thừa hoặc thứ tự chuỗi phải được cập nhật để chấp nhận chuỗi R1 mới.

Ngoài ra, các chứng nhận lá được cấp từ hệ thống phân cấp này sẽ không chứa EKU ClientAuth. Bất kỳ quy trình làm việc nào dựa trên các chứng nhận lá DV có thể sử dụng được để xác thực máy khách TLS phải di chuyển đến một hồ sơ chứng nhận / đường dẫn PKI thích hợp. Trong quá trình triển khai, các chứng nhận vẫn hoạt động trong các trình duyệt vì các máy khách xác thực bằng cách sử dụng đường dẫn tin cậy được ký chéo R1 → G2 được công bố trong kho của chúng tôi (certs.godaddy.com).

Cách thức các chứng nhận vẫn hoạt động trên trình duyệt trong quá trình chuyển đổi R1 (dấu chéo R1 → G2)

Khi chúng tôi di chuyển việc phát hành DV TLS công khai sang hệ thống phân cấp R1, gốc R1 vẫn đang trong quá trình được tin cậy / phân phối rộng rãi trong các cửa hàng tin cậy của trình duyệt và HĐH. Để đảm bảo các chứng nhận R1 mới được cấp sẽ hoạt động ngay lập tức trong các trình duyệt, chúng tôi dựa vào một đường dẫn tin cậy được ký chéo quay lại gốc G2 đã được tin cậy.

Về mặt thực tế, chứng nhận lá được cấp theo CA cấp R1 DV, nhưng các khách hàng xác thực nó bằng cách xây dựng một chuỗi đến GoDaddy Gốc 2 - G2 bằng cách sử dụng chứng nhận chéo R1 → G2 đã xuất bản. Các thành phần tạo tác liên quan trong kho lưu trữ là neo tin cậy G2 (gdroot-g2), chứng nhận chéo (gd_tls_root-r1-cross-g2), trung gian phát hành R1 DV (gd_tls_isscharge_dv-r1v1) và gốc phân cấp riêng (gd_tls_root-r1 ) certs.godaddy.com. Phương pháp tiếp cận dấu hiệu chéo này cho phép các trình duyệt xác thực chuỗi ngày hôm nay (neo tại G2), trong khi độ tin cậy R1 lan truyền theo thời gian.
r1 - g2 đường dẫn dấu chéo

Tại sao thay đổi này được thực hiện?

Có một số lý do để chuyển khỏi các chứng nhận hỗ trợ cả serverAuth và clientAuth (còn được gọi là các chứng nhận có mục đích hỗn hợp):

  • Tách xác thực máy chủ khỏi xác thực máy khách giúp đơn giản hóa mô hình tin cậy chứng nhận.
  • Cải thiện vệ sinh bảo mật: Chứng nhận có quá nhiều mục đích sẽ làm tăng rủi ro (nghĩa là lạm dụng clientAuth theo những cách ngoài ý muốn).
  • Sử dụng cấu trúc phân cấp PKI chuyên dụng cho các chức năng riêng biệt giúp duy trì ranh giới tin cậy rõ ràng hơn, phù hợp với các phương pháp hay nhất về PKI (Cơ sở hạ tầng khóa công khai) rộng hơn.

Lợi ích của thay đổi này là gì?

  • Giảm rủi ro từ các chứng nhận đa năng: Bằng cách hạn chế các chứng nhận công khai chỉ cho serverAuth, bề mặt tấn công được giảm thiểu và ranh giới tin cậy rõ ràng hơn.
  • Tuân thủ tốt hơn & Quản trị: Các tổ chức sẽ có sự tách biệt rõ ràng hơn giữa xác thực máy chủ và xác thực máy khách, điều này có thể hỗ trợ việc kiểm tra và quản lý vòng đời chứng nhận tốt hơn.
  • Tính rõ ràng trong hoạt động được cải thiện: Khi chức năng clientAuth được tách biệt thành các chứng nhận hoặc cơ sở hạ tầng thích hợp, sẽ dễ dàng hơn trong việc quản lý vai trò, thu hồi, gia hạn và đảm bảo sử dụng đúng chứng nhận cho đúng mục đích.
  • Sự sẵn sàng trong tương lai: Thay đổi này phù hợp với các mô hình PKI / tin cậy trình duyệt đang phát triển và giúp định vị các tổ chức cho các mô hình bảo mật và tự động hóa mới hơn.

Ai không bị ảnh hưởng?

Hầu hết các trang web chỉ sử dụng chứng nhận để xác thực máy chủ (nghĩa là, TLS / HTTPS thông thường) sẽ không bị ảnh hưởng. Nếu bạn chỉ sử dụng chứng nhận để bảo mật website cho người dùng, thay đổi này không yêu cầu hành động.

Ai bị ảnh hưởng?

Thay đổi này ảnh hưởng đến các tổ chức sử dụng chứng nhận máy chủ tin cậy công khai để xác thực máy khách (còn được gọi là TLS / mTLS lẫn nhau) hoặc xác thực máy chủ đến máy chủ dựa trên EKU máy khách. Ví dụ: một số dịch vụ tài chính, dịch vụ SaaS hoặc API nhiều người thuê có thể bị ảnh hưởng bởi thay đổi này.

Những gì bạn cần làm

  • Nếu bạn được lưu trữ bên ngoài GoDaddy : Đảm bảo rằng gói đầy đủ được cung cấp bởi các điểm cuối tải xuống hoặc giao diện khách hàng đang được cài đặt khi cập nhật chứng nhận tiếp theo của bạn.
  • Nếu bạn đang sử dụng chứng nhận trong bất kỳ trường hợp sử dụng nào dựa vào ClientAuth (mTLS) : Đảm bảo rằng bạn di chuyển các quy trình công việc đó sang sử dụng chứng nhận tự ký hoặc giải pháp CA riêng.

Các đội cũng nên xác nhận rằng không có tính năng hoặc tài liệu nội bộ nào giả định rằng các chứng nhận lá DV bao gồm ClientAuth EKU, vì các chứng nhận lá do R1 cấp sẽ không bao gồm nó.

Điều này có nghĩa là tất cả các chứng nhận được cấp sau ngày 15 tháng 6 năm 2026, đều không hợp lệ?

Không. Các chứng nhận được cấp trước ngày 15 tháng 6 năm 2026, bao gồm clientAuth vẫn có hiệu lực (cho đến khi hết hạn) theo mô hình tin cậy hiện có. Thay đổi chỉ ảnh hưởng đến các chứng nhận công khai mới được cấp vào hoặc sau ngày đó.

Nếu tôi chỉ sử dụng chứng nhận của mình cho trang web thông thường HTTPS (xác thực máy chủ), tôi có cần làm gì không?

Nếu dịch vụ lưu trữ của bạn nằm ngoài GoDaddy, bạn vẫn cần đảm bảo rằng gói được sử dụng đúng cách.

Chính xác thì "xác thực khách hàng" là gì trong ngữ cảnh này?

Xác thực máy khách đề cập đến việc khách hàng (người dùng, thiết bị hoặc máy chủ khác) sử dụng chứng nhận để xác thực với máy chủ. Nó thường được sử dụng trong xác thực mTLS (TLS tương hỗ) hoặc xác thực API giữa máy chủ với máy chủ trong đó máy chủ cần xác minh chứng nhận được trình bày bởi máy khách kết nối.

Tôi vẫn có thể sử dụng chứng nhận clientAuth chứ?

Có & mdash; nhưng đối với sự tin cậy của công chúng, bạn sẽ cần sử dụng chứng nhận được cấp đặc biệt để xác thực ứng dụng khách (nghĩa là EKU clientAuth chuyên dụng) hoặc sử dụng CA riêng cho các hệ thống nội bộ của bạn. Chứng nhận máy chủ công khai với clientAuth EKU sẽ không còn đáng tin cậy trong Chrome nếu được cấp sau ngày 15 tháng 6 năm 2026.

Các trình duyệt khác sẽ thực thi thay đổi này hay chỉ Chrome?

Chính sách bắt nguồn từ Chương trình gốc của Chrome, nhưng những thay đổi trong hệ sinh thái PKI công khai thường ảnh hưởng đến các trình duyệt và cửa hàng tin cậy khác. Thật khôn ngoan khi giả định khả năng áp dụng rộng rãi hơn hoặc ít nhất là việc tuân thủ trong tương lai sẽ có ý nghĩa trên các nền tảng.

Điều này có áp dụng cho các chứng nhận CA nội bộ / riêng tư không?

Không & mdash; thay đổi chỉ ảnh hưởng đến các chứng nhận SSL / TLS được công khai tin cậy (những chứng nhận được các cửa hàng gốc công khai tin cậy). Cơ sở hạ tầng CA riêng được sử dụng để xác thực máy khách nội bộ không bị ảnh hưởng trực tiếp.

Khi nào chúng ta cần sẵn sàng cho sự thay đổi này?

Mốc thời gian mục tiêu là ngày 27 tháng 5 năm 2026. Đến ngày đó, các nhóm chịu trách nhiệm phải hoàn thành việc xác thực sẵn sàng (cấu hình phát hành, độ chính xác của gói / tải xuống, hướng dẫn cài đặt chuỗi triển khai, giám sát và kiểm tra sự phụ thuộc EKU) để việc triển khai có thể tiếp tục mà không bị gián đoạn dịch vụ.

Xem thêm thông tin