Trang này được dịch bởi Cloud Translation API.

Câu hỏi thường gặp về việc di chuyển CA gốc trên Nền tảng Google Maps

Tài liệu này bao gồm các phần sau:

Thuật ngữ
Thông tin chung
Khắc phục sự cố
Quản lý các chứng chỉ đáng tin cậy
Phụ lục

Để biết thông tin tổng quan chi tiết hơn về quá trình di chuyển CA gốc của Google đang diễn ra, hãy xem phần Điều gì đang xảy ra?.

Thuật ngữ

Dưới đây là danh sách các thuật ngữ quan trọng nhất mà bạn cần nắm được trong tài liệu này. Để biết thông tin tổng quan toàn diện hơn về các thuật ngữ liên quan, vui lòng tham khảo Câu hỏi thường gặp về Dịch vụ tin cậy của Google.

Chứng chỉ SSL/TLS: Chứng chỉ liên kết một khoá mã hoá với một danh tính.; Chứng chỉ SSL/TLS được dùng để xác thực và thiết lập các kết nối an toàn với trang web. Chứng chỉ được cấp và ký bằng phương thức mã hoá bởi các thực thể được gọi là Tổ chức phát hành chứng chỉ.; Trình duyệt dựa vào chứng chỉ do Tổ chức phát hành chứng chỉ đáng tin cậy cấp để biết rằng thông tin được truyền sẽ được gửi đến đúng máy chủ và thông tin đó được mã hoá trong khi truyền.
Lớp cổng bảo mật (SSL): Lớp cổng bảo mật là giao thức được triển khai rộng rãi nhất, dùng để mã hoá hoạt động giao tiếp trên Internet. Giao thức SSL không còn được coi là an toàn và không nên được sử dụng nữa.
Bảo mật tầng truyền tải (TLS): Bảo mật tầng truyền tải là phiên bản kế thừa của SSL.
Tổ chức phát hành chứng chỉ (CA): Tổ chức phát hành chứng chỉ giống như một phòng hộ chiếu kỹ thuật số dành cho các thiết bị và người dùng. Tổ chức này cấp các tài liệu (chứng chỉ) được bảo vệ bằng mật mã để chứng thực rằng một thực thể (ví dụ: trang web) là thực thể mà nó tuyên bố.; Trước khi cấp Chứng chỉ, các CA có trách nhiệm xác minh rằng các tên trong Chứng chỉ được liên kết với người hoặc pháp nhân yêu cầu chứng chỉ.; Thuật ngữ Tổ chức phát hành chứng chỉ có thể dùng để chỉ cả hai tổ chức như Google Trust Services và các hệ thống cấp chứng chỉ.
Kho chứng chỉ gốc: Kho chứng chỉ gốc chứa một tập hợp các Tổ chức phát hành chứng chỉ mà Nhà cung cấp phần mềm ứng dụng tin cậy. Hầu hết các trình duyệt web và hệ điều hành đều có kho chứng chỉ gốc riêng.; Để được đưa vào kho chứng chỉ gốc, Tổ chức phát hành chứng chỉ phải đáp ứng các yêu cầu nghiêm ngặt do Nhà cung cấp phần mềm ứng dụng đưa ra.; Thường thì các yêu cầu này bao gồm việc tuân thủ các tiêu chuẩn trong ngành, chẳng hạn như yêu cầu của CA/Browser Forum.
Tổ chức phát hành chứng chỉ gốc: Tổ chức phát hành chứng chỉ gốc (hoặc chính xác hơn là chứng chỉ của tổ chức đó) là chứng chỉ cấp cao nhất trong chuỗi chứng chỉ.; Chứng chỉ CA gốc thường tự ký. Khoá riêng tư liên kết với các khoá đó được lưu trữ trong các cơ sở có mức độ bảo mật cao và được duy trì ở trạng thái ngoại tuyến để bảo vệ khoá khỏi bị truy cập trái phép.
Tổ chức phát hành chứng chỉ trung gian: Tổ chức phát hành chứng chỉ trung gian (hay đúng hơn là chứng chỉ của tổ chức này) là một chứng chỉ dùng để ký các chứng chỉ khác trong một chuỗi chứng chỉ.; Các CA trung gian chủ yếu tồn tại để cho phép phát hành chứng chỉ trực tuyến trong khi vẫn cho phép chứng chỉ CA gốc duy trì trạng thái ngoại tuyến.; Các CA trung gian còn được gọi là CA cấp dưới.
Tổ chức phát hành chứng chỉ: Một tổ chức phát hành chứng chỉ phát hành, hay đúng hơn là chứng chỉ của tổ chức đó, là chứng chỉ dùng để ký chứng chỉ ở dưới cùng trong một chuỗi chứng chỉ.; Chứng chỉ ở dưới cùng này thường được gọi là chứng chỉ người đăng ký, chứng chỉ thực thể cuối hoặc chứng chỉ lá. Trong tài liệu này, chúng tôi cũng sẽ sử dụng thuật ngữ chứng chỉ máy chủ.
Chuỗi chứng chỉ: Các chứng chỉ được liên kết với (được ký bằng phương thức mã hoá) bên phát hành. Chuỗi chứng chỉ bao gồm một chứng chỉ lá, tất cả chứng chỉ của tổ chức phát hành và một chứng chỉ gốc.
Ký chéo: Ứng dụng của Nhà cung cấp phần mềm phải cập nhật kho lưu trữ chứng chỉ gốc để thêm chứng chỉ CA mới để các sản phẩm của họ tin tưởng. Sẽ mất một khoảng thời gian để các sản phẩm chứa chứng chỉ CA mới được sử dụng rộng rãi.; Để tăng khả năng tương thích với các ứng dụng cũ, chứng chỉ CA có thể được "ký chéo" bởi một CA cũ khác đã được thiết lập. Thao tác này sẽ tạo một chứng chỉ CA thứ hai cho cùng một danh tính (tên và cặp khoá).; Tuỳ thuộc vào các CA có trong kho chứng chỉ gốc, ứng dụng sẽ tạo một chuỗi chứng chỉ khác cho đến một gốc mà họ tin cậy.

Thông tin chung

Điều gì đang xảy ra?

Tổng quan

Năm 2017, Google bắt đầu một dự án kéo dài nhiều năm để phát hành và sử dụng chứng chỉ gốc của riêng mình. Chữ ký mã hoá là cơ sở của bảo mật Internet TLS mà HTTPS sử dụng.

Sau giai đoạn đầu tiên, tính bảo mật TLS của các dịch vụ Google Maps Platform đã được GS Root R2 đảm bảo. Đây là một tổ chức phát hành chứng chỉ gốc (CA) rất nổi tiếng và được nhiều người tin tưởng. Google đã mua lại GS Root R2 từ GMO GlobalSign để dễ dàng chuyển đổi sang các CA gốc Google Trust Services (GTS) do chính chúng tôi phát hành.

Trên thực tế, tất cả các ứng dụng TLS (chẳng hạn như trình duyệt web, điện thoại thông minh và máy chủ ứng dụng) đều tin tưởng chứng chỉ gốc này, do đó có thể thiết lập kết nối bảo mật đến các máy chủ của Nền tảng Google Maps trong giai đoạn đầu của quá trình di chuyển.

Tuy nhiên, theo thiết kế, CA có thể không phát hành chứng chỉ có hiệu lực sau thời gian hết hạn của chứng chỉ đó. Khi GS Root R2 hết hạn vào ngày 15 tháng 12 năm 2021, Google sẽ di chuyển các dịch vụ của mình sang một CA mới là GTS Root R1 Cross bằng cách sử dụng chứng chỉ do CA gốc GTS Root R1 của Google phát hành.

Mặc dù phần lớn các hệ điều hành hiện đại và thư viện ứng dụng TLS đã tin tưởng CA gốc GTS, nhưng để đảm bảo quá trình chuyển đổi suôn sẻ cho hầu hết các hệ thống cũ, Google đã mua một chữ ký chéo từ GMO GlobalSign bằng cách sử dụng CA gốc GlobalSign – R1, một trong những CA gốc lâu đời và đáng tin cậy nhất hiện có.

Do đó, hầu hết khách hàng sử dụng Nền tảng Google Maps sẽ nhận ra một (hoặc cả hai) CA gốc đáng tin cậy này và sẽ hoàn toàn không bị ảnh hưởng bởi giai đoạn thứ hai của quá trình di chuyển này.

Điều này cũng áp dụng cho những khách hàng đã thực hiện hành động trong giai đoạn đầu của quá trình di chuyển vào năm 2018, giả sử rằng tại thời điểm đó, họ đã làm theo hướng dẫn của chúng tôi, cài đặt tất cả chứng chỉ từ gói CA gốc đáng tin cậy của Google.

Bạn nên xác minh các hệ thống của mình nếu đáp ứng các điều kiện sau:

dịch vụ của bạn chạy trên các nền tảng không chuẩn hoặc cũ và/hoặc bạn duy trì kho chứng chỉ gốc của riêng mình
bạn không làm gì trong giai đoạn 2017-2018, trong giai đoạn đầu tiên trong quá trình di chuyển CA gốc của Google hoặc bạn không cài đặt bộ chứng chỉ đầy đủ từ gói CA gốc của Google

Nếu trường hợp trên áp dụng, khách hàng của bạn có thể cần được cập nhật các chứng chỉ gốc được đề xuất để có thể đảm bảo việc sử dụng Nền tảng Google Maps không bị gián đoạn trong giai đoạn di chuyển này.

Hãy xem mục bên dưới để biết thêm thông tin kỹ thuật. Để biết hướng dẫn chung, vui lòng tham khảo phần Cách xác minh xem kho lưu trữ chứng chỉ gốc của tôi có cần cập nhật hay không.

Bạn cũng nên tiếp tục đồng bộ hoá kho lưu trữ chứng chỉ gốc với gói CA gốc được tuyển chọn ở trên để bảo vệ các dịch vụ của mình khỏi các thay đổi về CA gốc trong tương lai. Tuy nhiên, chúng tôi sẽ thông báo trước. Hãy xem các mục Làm cách nào để nhận thông tin cập nhật về giai đoạn di chuyển này? và Làm cách nào để nhận thông báo trước về các quá trình di chuyển trong tương lai? để được hướng dẫn thêm về cách nắm bắt thông tin.

Tóm tắt kỹ thuật

Như đã thông báo vào ngày 15 tháng 3 năm 2021 trên Blog bảo mật của Google, GS Root R2, Nền tảng CA gốc mà Google Maps đã sử dụng kể từ đầu năm 2018 sẽ hết hạn vào ngày 15 tháng 12 năm 2021. Do đó, trong năm nay, Google sẽ di chuyển sang một CA GTS Root R1 Cross mới được phát hành. Điều này có nghĩa là các dịch vụ của chúng tôi sẽ dần chuyển sang sử dụng chứng chỉ lá TLS do CA mới này phát hành.

Hầu hết các ứng dụng và hệ thống TLS hiện đại đều được định cấu hình trước bằng chứng chỉ GTS Root R1 hoặc sẽ nhận được chứng chỉ này thông qua các bản cập nhật phần mềm thông thường, và thậm chí GlobalSign Root CA – R1 cũng có trên các hệ thống cũ.

Tuy nhiên, bạn ít nhất nên xác minh hệ thống của mình nếu cả hai điểm sau đây đều áp dụng:

dịch vụ của bạn chạy trên các nền tảng không chuẩn hoặc cũ và/hoặc bạn duy trì kho chứng chỉ gốc của riêng mình
bạn không hành động trong giai đoạn đầu của quá trình di chuyển CA gốc của Google từ năm 2017 đến năm 2018, hoặc bạn không cài đặt toàn bộ bộ chứng chỉ từ gói CA gốc đáng tin cậy của Google

Mục Cách xác minh xem kho lưu trữ chứng chỉ gốc của tôi có cần cập nhật hay không cung cấp hướng dẫn chung để kiểm thử xem hệ thống của bạn có bị ảnh hưởng hay không.

Hãy xem câu hỏi Tại sao tôi nên đồng bộ hoá kho chứng chỉ gốc của mình với gói CA gốc đáng tin cậy của Google? để biết toàn bộ thông tin chi tiết.

Làm cách nào để nhận thông tin cập nhật về giai đoạn di chuyển này?

Gắn dấu sao vấn đề công khai 186840968 để cập nhật. Chúng tôi cũng cập nhật phần Câu hỏi thường gặp này trong suốt quá trình di chuyển, bất cứ khi nào gặp phải các chủ đề có thể được nhiều người quan tâm.

Làm cách nào để nhận thông báo trước về các quá trình di chuyển trong tương lai?

Bạn nên theo dõi Blog về bảo mật của Google. Chúng tôi cũng sẽ cố gắng cập nhật tài liệu dành riêng cho sản phẩm sớm nhất có thể, sau khi thông báo công khai trên blog.

Vui lòng đăng ký cả Thông báo của Nền tảng Google Maps, vì chúng tôi thường xuyên đăng thông tin cập nhật trên diễn đàn về những thay đổi có khả năng ảnh hưởng đến nhiều khách hàng hơn.

Chúng tôi sử dụng nhiều dịch vụ của Google. Việc di chuyển CA gốc có ảnh hưởng đến tất cả các CA đó không?

Có, quá trình di chuyển CA gốc sẽ diễn ra trên tất cả các dịch vụ và API của Google, nhưng tiến trình có thể khác nhau tuỳ theo dịch vụ. Tuy nhiên, sau khi bạn xác minh rằng các kho chứng chỉ gốc mà các ứng dụng khách của Google Maps Platform sử dụng chứa tất cả các CA được liệt kê trong gói CA gốc đáng tin cậy của Google, thì quá trình di chuyển đang diễn ra sẽ không ảnh hưởng đến các dịch vụ của bạn. Việc đồng bộ hoá các kho này cũng sẽ bảo vệ bạn khỏi các thay đổi về CA gốc trong tương lai.

Hãy xem các câu hỏi Tại sao tôi phải luôn đồng bộ hoá kho chứng chỉ gốc của mình với gói CA gốc đáng tin cậy của Google? và Những loại ứng dụng nào có nguy cơ bị lỗi? để biết thêm thông tin chi tiết.

Phần Cách xác minh xem kho chứng chỉ gốc của tôi có cần cập nhật hay không bên dưới cũng cung cấp hướng dẫn chung để kiểm thử hệ thống của bạn.

Cách xác minh xem kho lưu trữ chứng chỉ gốc của tôi có cần cập nhật hay không

Kiểm thử môi trường ứng dụng của bạn dựa trên các điểm cuối kiểm thử được liệt kê dưới đây:

Nếu có thể thiết lập kết nối TLS với điểm cuối kiểm thử chéo GTS Root R1, thì thời hạn của GS Root R2 sẽ không ảnh hưởng đến bạn.
Nếu bạn có thể thiết lập kết nối TLS với điểm cuối kiểm thử GTS Root R1, thì ứng dụng của bạn thậm chí có thể sẽ được bảo vệ khỏi thời điểm hết hạn của GTS Root R1 Cross và GlobalSign Root CA - R1 vào năm 2028.

Nhìn chung, hệ thống của bạn sẽ tương thích với thay đổi về CA gốc này nếu:

dịch vụ của bạn chạy trên một hệ điều hành chính được duy trì, đồng thời bạn giữ lại cả hệ điều hành và thư viện mà dịch vụ của bạn sử dụng được vá, đồng thời bạn không duy trì kho lưu trữ chứng chỉ gốc của riêng mình, hoặc:
bạn đã làm theo các đề xuất trước đây của chúng tôi và cài đặt tất cả CA gốc từ gói CA gốc đáng tin cậy của Google

Những khách hàng có thể bị ảnh hưởng nên cài đặt ngay các chứng chỉ từ gói CA gốc đáng tin cậy của Google để tránh bị gián đoạn dịch vụ trong tương lai.

Hãy xem câu hỏi Tại sao tôi nên đồng bộ hoá kho lưu trữ chứng chỉ gốc với gói CA gốc đáng tin cậy của Google? để biết toàn bộ thông tin chi tiết.

Có công cụ đơn giản nào mà tôi có thể sử dụng để xác minh kho chứng chỉ gốc của chúng tôi không?

Bạn có thể thấy hai công cụ dòng lệnh curl và openssl hữu ích trong quá trình điều tra. Cả hai đều có trên hầu hết các nền tảng và cung cấp nhiều tuỳ chọn để kiểm thử chế độ thiết lập.

Để biết hướng dẫn tải curl, hãy xem phần Tải curl bên dưới.

Các lệnh openssl hiển thị bên dưới dành cho phiên bản 1.1.1 trở lên. Các phiên bản trước 1.1.1 không được hỗ trợ. Nếu bạn đang sử dụng phiên bản cũ hơn, hãy nâng cấp hoặc sửa đổi các lệnh này nếu cần cho phiên bản của bạn. Để biết hướng dẫn về cách tải openssl, hãy xem phần Cách tải OpenSSL bên dưới.

Bạn cũng sẽ tìm thấy các công cụ hữu ích khác trong phần Tôi có thể tải các công cụ mình cần ở đâu? bên dưới.

Để biết hướng dẫn kiểm thử cụ thể, vui lòng xem phần Cách xác minh xem kho chứng chỉ gốc của tôi có cần cập nhật hay không.

Kiểm thử kho chứng chỉ gốc mặc định

curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Xác minh gói CA gốc đáng tin cậy của Google

Tải gói CA gốc đáng tin cậy của Google xuống, sau đó làm theo các bước sau:

curl -vvI --cacert roots.pem https://maps.googleapis.com; \
openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Quá trình di chuyển CA gốc của Google sẽ tiếp tục như thế nào và khi nào?

Giai đoạn đầu tiên (di chuyển sang GS Root R2), được thông báo vào tháng 1 năm 2017, bắt đầu vào cuối năm 2017 và kết thúc vào nửa đầu năm 2018.
Giai đoạn hai (di chuyển sang GTS Root R1 Cross) đã được thông báo vào tháng 3 năm 2021 và sẽ ra mắt trong những tháng tới, trước khi GS Root R2 hết hạn vào ngày 15 tháng 12 năm 2021.

Lịch trình của các giai đoạn di chuyển sau này sẽ được thông báo sớm trước khi chứng chỉ hết hạn trong tương lai.

Tuy nhiên, bạn có thể kiểm chứng các ứng dụng của mình trong tương lai, nếu bạn luôn đồng bộ hoá kho chứng chỉ gốc với danh sách các CA gốc chọn lọc trong gói CA gốc của Google đáng tin cậy.

Ngoài ra, hãy xem câu hỏi Tại sao tôi nên đồng bộ hoá kho lưu trữ chứng chỉ gốc với gói CA gốc đáng tin cậy của Google? để biết thêm thông tin cơ bản.

Kế hoạch phát hành chung cho từng dịch vụ của Google

Quá trình phát hành theo giai đoạn bắt đầu trong một trung tâm dữ liệu duy nhất.
Việc triển khai sẽ dần mở rộng sang nhiều trung tâm dữ liệu hơn cho đến khi có phạm vi toàn cầu.
Nếu phát hiện thấy vấn đề nghiêm trọng ở bất kỳ giai đoạn nào, kiểm thử có thể tạm thời được hoàn nguyên trong khi giải quyết vấn đề.
Dựa trên dữ liệu đầu vào từ các lần lặp lại trước, các dịch vụ khác của Google sẽ được đưa vào bản phát hành cho đến khi dần dần tất cả dịch vụ của Google đều di chuyển sang chứng chỉ mới.

Ai sẽ bị ảnh hưởng, khi nào và ở đâu?

Ngày càng có nhiều nhà phát triển Nền tảng Google Maps bắt đầu nhận được các chứng chỉ mới khi các trung tâm dữ liệu mới được di chuyển sang. Các thay đổi này sẽ được bản địa hoá đôi chút, vì các yêu cầu của ứng dụng có xu hướng được chuyển tiếp đến các máy chủ trong các trung tâm dữ liệu lân cận về mặt địa lý.

Vì chúng tôi không thể chắc chắn về việc ai sẽ bị ảnh hưởng, khi nào và ở đâu, nên tất cả khách hàng của chúng tôi đều nên xác minh và đảm bảo an toàn cho các dịch vụ của họ trước các giai đoạn di chuyển CA gốc của Google có thể xảy ra.

Hãy xem phần Cách xác minh xem kho lưu trữ chứng chỉ gốc của tôi có cần cập nhật hay không để biết thêm hướng dẫn.

Những điều cần chú ý

Những ứng dụng không được định cấu hình bằng chứng chỉ gốc cần thiết sẽ không thể xác minh kết nối TLS với Nền tảng Google Maps. Trong trường hợp này, ứng dụng thường sẽ đưa ra cảnh báo về việc xác thực chứng chỉ không thành công.

Tuỳ thuộc vào cấu hình TLS, ứng dụng có thể tiếp tục đưa ra yêu cầu Nền tảng Google Maps hoặc từ chối tiếp tục yêu cầu.

Ứng dụng TLS cần đáp ứng những yêu cầu tối thiểu nào để giao tiếp với Google Maps Platform?

Chứng chỉ của Nền tảng Google Maps sử dụng Tên thay thế cho chủ đề (SAN) DNS, vì vậy, quá trình xử lý chứng chỉ của ứng dụng phải có thể hỗ trợ các SAN có thể chứa một ký tự đại diện duy nhất làm nhãn ở ngoài cùng bên trái trong tên, chẳng hạn như *.googleapis.com.

Để biết các yêu cầu khác, vui lòng tham khảo phần Các yêu cầu mà ứng dụng TLS đề xuất để giao tiếp với Google là gì? trong Câu hỏi thường gặp về GTS.

Những loại ứng dụng nào có nguy cơ bị lỗi?

Ứng dụng sử dụng kho lưu trữ chứng chỉ gốc của hệ thống mà không có bất kỳ hạn chế nào do nhà phát triển đặt ra

Ứng dụng dịch vụ web trên Nền tảng Google Maps

Nếu bạn đang sử dụng một hệ điều hành phổ biến, ví dụ: Ubuntu, Red Hat, Windows 10 hoặc Server 2019, OS X) vẫn được duy trì và nhận bản cập nhật thường xuyên, thì kho chứng chỉ gốc mặc định của bạn phải có chứng chỉ GTS Root R1.

Nếu đang sử dụng một phiên bản hệ điều hành cũ không còn nhận được bản cập nhật, thì có thể bạn sẽ có hoặc không có chứng chỉ GTS Root R1. Tuy nhiên, kho chứng chỉ gốc của bạn rất có thể sẽ chứa GlobalSign Root CA – R1, một trong những CA gốc lâu đời nhất và đáng tin cậy nhất.

Đối với các ứng dụng di động gọi dịch vụ web của Nền tảng Google Maps trực tiếp từ thiết bị của người dùng cuối, các nguyên tắc trong câu hỏi Ứng dụng di động có nguy cơ bị lỗi không? sẽ được áp dụng.

Ứng dụng Nền tảng Google Maps phía máy khách

Các ứng dụng API JavaScript của Maps thường dựa vào chứng chỉ gốc của trình duyệt web chạy ứng dụng. Hãy xem phần Các ứng dụng JavaScript có nguy cơ bị lỗi không? để biết thêm thông tin chi tiết.

Đối với các ứng dụng gốc dành cho thiết bị di động sử dụng bất kỳ SDK Maps nào cho Android, SDK Maps dành cho iOS, SDK địa điểm dành cho Android hoặc SDK địa điểm dành cho iOS, các quy tắc tương tự cũng được áp dụng như đối với các ứng dụng gọi các dịch vụ web của Nền tảng Google Maps.

Hãy xem câu hỏi Ứng dụng di động có nguy cơ gặp sự cố không? để biết thêm chi tiết.

Ứng dụng dùng gói chứng chỉ riêng hoặc dùng các tính năng bảo mật nâng cao, chẳng hạn như ghim chứng chỉ

Bạn cần đảm bảo tự cập nhật gói chứng chỉ của mình. Như đã thảo luận trong câu hỏi Tại sao tôi nên giữ kho chứng chỉ gốc của mình đồng bộ với gói CA gốc đáng tin cậy của Google?, bạn nên nhập tất cả chứng chỉ từ gói CA gốc của Google đáng tin cậy vào kho lưu trữ chứng chỉ gốc của riêng bạn.

Nếu đang ghim chứng chỉ hoặc khoá công khai cho các miền Google mà ứng dụng của bạn kết nối, bạn nên thêm chứng chỉ và khoá công khai vào danh sách thực thể đáng tin cậy trong ứng dụng.

Để biết thêm thông tin về chứng chỉ hoặc cách ghim khoá công khai, hãy tham khảo các tài nguyên bên ngoài được liệt kê trong câu hỏi Bạn cần thêm thông tin?.

Tại sao tôi nên đồng bộ hoá kho chứng chỉ gốc với gói CA gốc đáng tin cậy của Google?

Danh sách CA gốc được tuyển chọn trong gói CA gốc đáng tin cậy của Google bao gồm tất cả CA mà các dịch vụ của Google có thể sử dụng trong tương lai gần.

Do đó, nếu muốn hệ thống của mình luôn an toàn trong tương lai, bạn nên xác minh rằng kho lưu trữ chứng chỉ gốc của mình chứa tất cả chứng chỉ trong gói và tạo thói quen đồng bộ hoá hai kho lưu trữ này.

Điều này đặc biệt quan trọng nếu các dịch vụ của bạn chạy trên một phiên bản hệ điều hành không được bảo trì, bạn không thể cập nhật hệ điều hành và thư viện vì lý do khác, hoặc bạn duy trì kho chứng chỉ gốc của riêng mình.

Hãy xem câu hỏi Làm cách nào để nhận thông báo trước về các quá trình di chuyển trong tương lai? để tìm hiểu cách nhận thông tin cập nhật về các quá trình di chuyển Tổ chức phát hành chứng chỉ gốc trong tương lai. Việc thường xuyên đồng bộ hoá kho lưu trữ chứng chỉ gốc với danh sách được tuyển chọn sẽ bảo vệ các dịch vụ của bạn khỏi bị gián đoạn trong tương lai do các thay đổi về CA, đồng thời giúp các dịch vụ của bạn tiếp tục hoạt động sau khi cả GTS Root R1 Cross và GlobalSign Root CA – R1 hết hạn.

Ngoài ra, vui lòng tham khảo câu hỏi Tôi đang xây dựng một sản phẩm kết nối với các dịch vụ của Google. Tôi cần tin tưởng chứng chỉ CA nào? trong Câu hỏi thường gặp về GTS để biết thêm đề xuất.

Tại sao tôi không nên cài đặt bất kỳ chứng chỉ CA cấp trung gian hoặc cấp lá nào?

Việc này sẽ có nguy cơ làm hỏng ứng dụng của bạn bất cứ lúc nào chúng tôi đăng ký chứng chỉ mới hoặc chuyển đổi các CA trung gian. Một trong hai điều này có thể xảy ra bất cứ lúc nào mà không cần thông báo trước, đồng thời áp dụng như nhau cho các chứng chỉ máy chủ riêng lẻ, chẳng hạn như chứng chỉ do maps.googleapis.com phân phát, cũng như mọi CA trung gian của chúng tôi, chẳng hạn như GTS Root R1 Cross.

Để bảo vệ các dịch vụ của mình khỏi trường hợp này, bạn chỉ nên cài đặt chứng chỉ gốc từ gói CA gốc đáng tin cậy của Google và chỉ dựa vào chứng chỉ gốc để xác minh độ tin cậy của toàn bộ chuỗi chứng chỉ liên kết với chứng chỉ đó.

Mọi quy trình triển khai thư viện TLS hiện đại đều có thể tự động xác minh các chuỗi tin cậy như vậy, miễn là tổ chức phát hành chứng chỉ gốc là đáng tin cậy.

Các ứng dụng JavaScript có nguy cơ bị lỗi không?

Các chứng chỉ gốc GTS đã được nhúng và tin cậy tốt bởi hầu hết các trình duyệt hiện đại, đồng thời chữ ký chéo của GMO GlobalSign sẽ đảm bảo quá trình di chuyển diễn ra suôn sẻ ngay cả đối với hầu hết người dùng cuối trên các trình duyệt cũ. API này bao gồm tất cả trình duyệt chính thức được hỗ trợ cho API JavaScript của Maps.

Mọi trình duyệt hiện đại đều phải cho phép người dùng cuối xác minh và thường chỉnh sửa những chứng chỉ mà trình duyệt tin cậy. Mặc dù vị trí chính xác còn tuỳ thuộc vào từng trình duyệt, nhưng thường thì bạn có thể tìm thấy danh sách chứng chỉ ở đâu đó trong phần Cài đặt.

Ứng dụng dành cho thiết bị di động có có nguy cơ bị lỗi không?

Các thiết bị Android và Apple iOS vẫn nhận được bản cập nhật thường xuyên từ nhà sản xuất thiết bị cũng được dự kiến sẽ có thể sử dụng trong tương lai. Hầu hết các mẫu điện thoại Android cũ đều có ít nhất chứng chỉ GlobalSign Root CA – R1, mặc dù danh sách chứng chỉ đáng tin cậy có thể khác nhau tuỳ theo nhà sản xuất điện thoại di động, mẫu thiết bị và phiên bản Android.

Tuy nhiên, khả năng hỗ trợ các CA gốc GTS, bao gồm cả GTS Root R1 có thể vẫn bị giới hạn trong các phiên bản Android trước 10.

Đối với các thiết bị iOS, Apple duy trì một danh sách các CA gốc đáng tin cậy cho từng phiên bản iOS gần đây trên các trang hỗ trợ của họ. Tuy nhiên, tất cả phiên bản iOS 5 trở lên đều hỗ trợ GlobalSign Root CA – R1.

Các CA gốc GTS, bao gồm cả GTS Root R1 đã được hỗ trợ kể từ phiên bản iOS 12.1.3.

Hãy xem câu hỏi Làm cách nào để kiểm tra chứng chỉ gốc đáng tin cậy trên điện thoại di động của tôi? để biết thêm chi tiết.

Khi nào trình duyệt hoặc hệ điều hành của tôi sẽ bao gồm chứng chỉ gốc của Google Trust Services?

Trong những năm qua, Google đã hợp tác rộng rãi với tất cả các bên thứ ba chính, duy trì các gói chứng chỉ gốc đáng tin cậy và được sử dụng rộng rãi. Ví dụ: nhà sản xuất hệ điều hành, chẳng hạn như Apple và Microsoft, nhưng cũng có các nhóm Android và Chrome OS của Google; nhà phát triển trình duyệt, chẳng hạn như Mozilla, Apple, Microsoft, nhưng cũng có nhóm Chrome của Google; nhà sản xuất phần cứng, chẳng hạn như điện thoại, hộp giải mã, TV, máy chơi trò chơi, máy in, v.v.

Do đó, rất có thể bất kỳ hệ thống nào đang được duy trì đều đã hỗ trợ GTS Root CA mới của Google, bao gồm cả GTS Root R1, và thậm chí cả các hệ thống cũ cũng rất có thể hỗ trợ GlobalSign Root CA – R1. Các chứng chỉ này sẽ được dùng để ký chéo cho Google trong những năm tới.

Tuy nhiên, vì tiến trình đưa vào chứng chỉ của bên thứ ba phần lớn nằm ngoài tầm kiểm soát của Google, nên lời khuyên chung tốt nhất chúng tôi có thể đưa ra là đảm bảo bạn thường xuyên áp dụng các bản cập nhật hệ thống hiện có.

Một số bên thứ ba, chẳng hạn như Chương trình chứng chỉ CA của Mozilla, có thể đã ghi lại tiến trình đưa chứng chỉ vào.

Khắc phục sự cố

Tôi có thể tìm các công cụ cần thiết ở đâu?

Xoay người

Nếu bản phân phối hệ điều hành của bạn không cung cấp curl, bạn có thể tải xuống từ https://curl.haxx.se/. Bạn có thể tải nguồn xuống và tự biên dịch công cụ hoặc tải tệp nhị phân được biên dịch sẵn (nếu có) cho nền tảng của bạn.

Tải OpenSSL

Nếu bản phân phối hệ điều hành của bạn không cung cấp openssl, bạn có thể tải nguồn xuống từ https://www.openssl.org/ và biên dịch công cụ này. Bạn có thể xem danh sách tệp nhị phân do bên thứ ba tạo qua trang web https://www.openssl.org/community/binaries.html. Tuy nhiên, không có bản dựng nào trong số này được nhóm OpenSSL hỗ trợ hoặc chứng thực theo bất kỳ cách cụ thể nào.

Tải Wireshark, Tshark hoặc Tcpdump

Mặc dù hầu hết các bản phân phối Linux đều cung cấp wireshark, công cụ dòng lệnh tshark và tcpdump, nhưng bạn có thể tìm thấy các phiên bản được biên dịch trước của hai công cụ đầu tiên này cho các hệ điều hành khác tại https://www.wireshark.org.

Bạn có thể tìm thấy mã nguồn của Tcpdump và LibPCAP tại https://www.tcpdump.org.

Bạn có thể tìm thấy tài liệu về các công cụ hữu ích này trong Hướng dẫn sử dụng Wireshark, trên trang man của Tshark và trên trang man của Tcpdump.

Tải keytool Java

Công cụ dòng lệnh keytool phải được vận chuyển cùng với mọi phiên bản Bộ phát triển Java (JDK) hoặc Môi trường thời gian chạy Java (JRE). Cài đặt các trình xử lý này để nhận keytool.. Tuy nhiên, việc sử dụng keytool là không cần thiết để xác minh chứng chỉ gốc, trừ phi ứng dụng được tạo bằng Java.

Những việc cần làm khi xảy ra sự cố ngừng hoạt động

Bạn cần cài đặt chứng chỉ gốc bắt buộc từ gói CA gốc đáng tin cậy của Google vào kho lưu trữ chứng chỉ gốc mà ứng dụng của bạn sử dụng.

Làm việc với quản trị viên hệ thống để nâng cấp kho chứng chỉ gốc trên máy.
Xem phần Câu hỏi thường gặp này để biết con trỏ có thể áp dụng cho hệ thống của bạn.
Nếu bạn cần được hỗ trợ thêm về nền tảng hoặc hệ thống cụ thể, hãy liên hệ với các kênh hỗ trợ kỹ thuật do nhà cung cấp hệ thống của bạn cung cấp.
Để được hỗ trợ chung, hãy liên hệ với nhóm hỗ trợ của chúng tôi như mô tả trong phần Liên hệ với nhóm hỗ trợ Google Maps Platform. Lưu ý: Đối với các vấn đề dành riêng cho nền tảng, chúng tôi chỉ có thể cố gắng hết sức để đưa ra hướng dẫn.
Đánh dấu vấn đề công khai 186840968 để nhận thêm thông tin cập nhật liên quan đến việc di chuyển.

Liên hệ với nhóm hỗ trợ Nền tảng Google Maps

Khắc phục sự cố ban đầu

Hãy xem phần Cách xác minh xem kho chứng chỉ gốc của tôi có cần cập nhật hay không để biết các hướng dẫn chung về cách khắc phục sự cố.

Mục Quản lý chứng chỉ đáng tin cậy của bạn cũng có thể cung cấp thông tin có giá trị, nếu bạn cần nhập hoặc xuất chứng chỉ gốc.

Nếu vấn đề chưa được giải quyết và bạn quyết định liên hệ với nhóm hỗ trợ của Google Maps Platform, hãy chuẩn bị để cung cấp thêm những thông tin sau:

Các máy chủ bị ảnh hưởng của bạn nằm ở đâu?
Dịch vụ của bạn đang gọi đến những địa chỉ IP nào của Google?
(Các) API nào chịu ảnh hưởng của vấn đề này?
Chính xác thì vấn đề bắt đầu từ khi nào?

Kết quả của các lệnh sau:

curl -vvI https://maps.googleapis.com; \
openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demosite.pki.goog/; \
openssl s_client -connect good.gtsr1x.demosite.pki.goog:443 -showcerts </dev/null;

Để biết hướng dẫn tải các công cụ cần thiết, hãy xem câu hỏi Tôi có thể tải các công cụ cần thiết ở đâu?.

Gửi yêu cầu hỗ trợ

Vui lòng làm theo hướng dẫn về cách Tạo yêu cầu hỗ trợ trong phần Tài nguyên và hỗ trợ của Nền tảng Google Maps.

Khi gửi yêu cầu hỗ trợ, ngoài dữ liệu được liệt kê trong phần Khắc phục sự cố ban đầu, vui lòng cung cấp thêm những thông tin sau:

Địa chỉ IP công khai của bạn là gì?
Địa chỉ IP công khai của máy chủ DNS là gì?
Nếu có thể, hãy chụp gói tcpdump hoặc Wireshark của quá trình đàm phán TLS không thành công với https://maps.googleapis.com/ ở định dạng PCAP, sử dụng độ dài ảnh chụp nhanh đủ lớn để chụp toàn bộ gói mà không bị cắt bớt (ví dụ: sử dụng -s0 trên các phiên bản tcpdump cũ).
Nếu có thể, các trích dẫn nhật ký từ dịch vụ của bạn sẽ cho biết chính xác lý do không kết nối TLS, tốt nhất là có đầy đủ thông tin về chuỗi chứng chỉ máy chủ.

Để được hướng dẫn cách tải các công cụ cần thiết, hãy xem câu hỏi Tôi có thể mua các công cụ cần thiết ở đâu?.

Đăng về vấn đề công khai 186840968

Khi đăng bình luận về vấn đề công khai 186840968, vui lòng cung cấp thông tin được liệt kê trong phần Khắc phục sự cố ban đầu.

Làm cách nào để xác định địa chỉ công khai của DNS?

Trên Linux, bạn có thể chạy lệnh sau:

dig -t txt o-o.myaddr.l.google.com

Trên Windows, bạn có thể sử dụng nslookup ở chế độ tương tác:

C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com

Cách diễn giải kết quả của lệnh curl

Việc chạy curl với cờ -vvI sẽ cung cấp nhiều thông tin hữu ích. Sau đây là một số hướng dẫn để diễn giải kết quả:

Các dòng bắt đầu bằng "*" hiển thị đầu ra từ quá trình đàm phán TLS, cũng như thông tin về việc chấm dứt kết nối.
Các dòng bắt đầu bằng ">" sẽ hiển thị yêu cầu HTTP đi mà curl gửi.
Các dòng bắt đầu bằng "<" sẽ cho thấy phản hồi HTTP nhận được từ máy chủ.
Nếu giao thức là HTTPS, thì sự hiện diện của các dòng ">" hoặc "<" cho thấy có một cơ chế bắt tay TLS thành công.

Đã sử dụng thư viện TLS và gói chứng chỉ gốc

Việc chạy curl với cờ -vvI cũng in ra kho chứng chỉ gốc đã sử dụng, nhưng kết quả chính xác có thể khác nhau tuỳ theo hệ thống như minh hoạ ở đây.

Đầu ra từ máy Red Hat Linux có curl được liên kết với NSS có thể chứa các dòng sau:

* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none

Đầu ra từ máy Ubuntu hoặc Debian Linux có thể chứa các dòng sau:

* successfully set certificate verify locations:
* CAfile: none
  CApath: /etc/ssl/certs

Dữ liệu đầu ra từ máy Ubuntu hoặc Debian Linux sử dụng tệp PEM chứng chỉ gốc của Google được cung cấp bằng cờ --cacert có thể chứa các dòng sau:

* successfully set certificate verify locations:
* CAfile: /home/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs

Tác nhân người dùng

Các yêu cầu đi chứa tiêu đề User-Agent, có thể cung cấp thông tin hữu ích về curl và hệ thống của bạn.

Ví dụ từ máy Red Hat Linux:

> HEAD / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh1/1.4.2
> Host: maps.googleapis.com
> Accept: */*
>

Bắt tay TLS không thành công

Các dòng, chẳng hạn như các dòng trong mã mẫu này, cho biết kết nối đã bị chấm dứt giữa quá trình bắt tay TLS do chứng chỉ máy chủ không đáng tin cậy. Việc không có đầu ra gỡ lỗi bắt đầu bằng > hoặc < cũng là những dấu hiệu rõ ràng cho thấy nỗ lực kết nối không thành công:

*** SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0**

Bắt tay TLS thành công

Một cái bắt tay TLS thành công được biểu thị bằng sự hiện diện của các dòng trông tương tự như các dòng trong mã mẫu này. Bộ thuật toán mật mã dùng cho kết nối đã mã hoá phải được liệt kê, cũng như thông tin chi tiết về chứng chỉ máy chủ được chấp nhận. Hơn nữa, sự xuất hiện của các dòng bắt đầu bằng > hoặc < cho biết lưu lượng truy cập HTTP tải trọng đang được truyền thành công qua kết nối được mã hoá TLS:

*   Trying 108.177.15.95:443...
* Connected to maps.googleapis.com (108.177.15.95) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=upload.video.google.com
*  start date: Mar 23 08:24:47 2021 GMT
*  expire date: Jun 15 08:24:46 2021 GMT
*  subjectAltName: host "maps.googleapis.com" matched cert's "*.googleapis.com"
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c4acf0c560)
> HEAD / HTTP/2
> Host: maps.googleapis.com
> user-agent: curl/7.74.0
> accept: */*
>
> HTTP/2 302
…

Cách in chứng chỉ máy chủ đã nhận ở dạng dễ đọc

Nếu kết quả đầu ra có định dạng PEM, chẳng hạn như kết quả từ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null, bạn có thể in chứng chỉ được cung cấp theo các bước sau:

Sao chép toàn bộ chứng chỉ được mã hoá Base 64, bao gồm cả tiêu đề và chân trang:
```
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
```

Sau đó, hãy làm như sau:

openssl x509 -inform pem -noout -text
````

Sau đó, dán nội dung của vùng đệm sao chép vào thiết bị đầu cuối.
Nhấn phím Enter.

Ví dụ về hoạt động đầu vào và đầu ra, hãy xem phần Cách in chứng chỉ PEM ở dạng dễ đọc.

Chứng chỉ được ký chéo của Google trông như thế nào trong OpenSSL?

…
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog
   i:C = US, O = Google Trust Services LLC, CN = GTS Y1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services LLC, CN = GTS Y1
   i:C = US, O = Google Trust Services LLC, CN = GTS Root R1
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
2 s:C = US, O = Google Trust Services LLC, CN = GTS Root R1
   i:C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = good.gtsr1x.demosite.pki.goog

issuer=C = US, O = Google Trust Services LLC, CN = GTS Y1

---
…

Quản lý chứng chỉ đáng tin cậy

Làm cách nào để kiểm tra chứng chỉ gốc đáng tin cậy trên điện thoại di động?

Chứng chỉ đáng tin cậy của Android

Như đã đề cập trong câu hỏi Ứng dụng di động có nguy cơ bị lỗi không?, Kể từ phiên bản 4.0, Android đã cho phép người dùng điện thoại di động xác minh danh sách chứng chỉ đáng tin cậy trong phần Cài đặt. Bảng này cho thấy đường dẫn chính xác của trình đơn Settings (Cài đặt):

Phiên bản Android	Đường dẫn trình đơn
1.x, 2.x, 3.x	Không áp dụng
4.x, 5.x, 6.x, 7.x	Cài đặt > Bảo mật > Thông tin xác thực đáng tin cậy
8.x, 9	Cài đặt > Bảo mật và vị trí > Mã hoá và thông tin xác thực > Thông tin xác thực đáng tin cậy
10+	Cài đặt > Bảo mật > Nâng cao > Mã hoá và thông tin xác thực > Thông tin xác thực đáng tin cậy

Bảng này minh hoạ có thể có sẵn các chứng chỉ gốc quan trọng nhất cho mỗi phiên bản Android, dựa trên phương thức xác minh thủ công bằng hình ảnh hệ thống Thiết bị Android ảo (AVD) hiện có, quay lại ca-certificates Kho lưu trữ hình ảnh Git của AOSP: nơi không còn có nhật ký phiên bản kho lưu trữ Git

Phiên bản Android	GTS Root R1	GlobalSign Root CA – R1	GlobalSign Root R2 (có hiệu lực đến ngày 15 tháng 12 năm 2021)
2.3, 3.2, 4.x, 5.x, 6.x, 7.x, 8.x, 9
10+

Thường thì bạn không thể cập nhật kho lưu trữ chứng chỉ gốc của hệ thống Android nếu không có bản cập nhật chương trình cơ sở hoặc không can thiệp vào hệ thống của thiết bị. Tuy nhiên, trên hầu hết phiên bản Android vẫn còn được sử dụng rộng rãi, bộ chứng chỉ gốc đáng tin cậy hiện tại có thể cung cấp dịch vụ không gián đoạn trong nhiều năm sau đó, vượt quá thời gian hoạt động hiệu quả của hầu hết thiết bị hiện có.

Kể từ phiên bản 7.0, Android cung cấp cho nhà phát triển ứng dụng một phương thức bảo mật để thêm các chứng chỉ đáng tin cậy mà chỉ ứng dụng của họ mới tin cậy. Bạn có thể thực hiện việc này bằng cách đóng gói các chứng chỉ với ứng dụng và tạo một cấu hình bảo mật mạng tuỳ chỉnh, như mô tả trong tài liệu đào tạo Cấu hình bảo mật mạng Các phương pháp hay nhất của Android về bảo mật và quyền riêng tư.

Tuy nhiên, vì các nhà phát triển ứng dụng bên thứ ba sẽ không thể tác động đến cấu hình bảo mật mạng của lưu lượng truy cập bắt nguồn từ APK Dịch vụ Google Play, nên những nỗ lực đó có thể chỉ là giải pháp một phần.

Trên các thiết bị cũ, bạn chỉ có thể dựa vào CA do người dùng thêm, được cài đặt theo chính sách nhóm của công ty áp dụng cho thiết bị của người dùng cuối hoặc do chính người dùng cuối cài đặt.

Cửa hàng tin cậy iOS

Mặc dù Apple không trực tiếp hiển thị bộ chứng chỉ gốc đáng tin cậy mặc định của mình cho người dùng điện thoại di động, nhưng công ty có các đường liên kết đến các nhóm CA gốc đáng tin cậy cho iOS phiên bản 5 trở lên trong các bài viết hỗ trợ của Apple:

Tuy nhiên, mọi chứng chỉ bổ sung được cài đặt trên thiết bị iOS đều sẽ xuất hiện trong phần Cài đặt > Chung > Hồ sơ. Nếu bạn không cài đặt thêm chứng chỉ, mục trình đơn Hồ sơ có thể không xuất hiện.

Bảng này minh hoạ tình trạng có sẵn của các chứng chỉ gốc quan trọng nhất theo phiên bản iOS, dựa trên các nguồn nêu trên:

Phiên bản iOS	GTS gốc R1	GlobalSign Root CA – R1	GlobalSign Root R2 (có hiệu lực đến ngày 15 tháng 12 năm 2021)
5, 6, 7, 8, 9, 10, 11, 12
12.1.3+

Chứng chỉ gốc của hệ thống được lưu trữ ở đâu và làm cách nào để cập nhật chứng chỉ đó?

Vị trí của kho chứng chỉ gốc mặc định thay đổi tuỳ theo hệ điều hành và thư viện SSL/TLS được sử dụng. Tuy nhiên, trên hầu hết các bản phân phối Linux, bạn có thể tìm thấy chứng chỉ gốc mặc định trong một trong các đường dẫn sau:

/usr/local/share/ca-certificates: Debian, Ubuntu, các phiên bản RHEL và CentOS cũ hơn
/etc/pki/ca-trust/source/anchors và /usr/share/pki/ca-trust-source: hệ điều hành phớt và các phiên bản RHEL và CentOS mới hơn
/var/lib/ca-certificates: OpenSUSE

Các đường dẫn chứng chỉ khác có thể bao gồm:

/etc/ssl/certs: Debian, Ubuntu
/etc/pki/tls/certs: RHEL, CentOS

Một số chứng chỉ trong các thư mục này có thể là đường liên kết tượng trưng đến các tệp trong các thư mục khác.

Kho lưu trữ chứng chỉ gốc của OpenSSL

Đối với các ứng dụng sử dụng OpenSSL, bạn có thể kiểm tra vị trí đã định cấu hình của các thành phần đã cài đặt, bao gồm cả kho lưu trữ chứng chỉ gốc mặc định bằng lệnh sau:

openssl version -d

Lệnh này sẽ in OPENSSLDIR, tương ứng với thư mục cấp cao nhất mà bạn có thể tìm thấy thư viện và cấu hình của thư viện đó trong:

OPENSSLDIR: "/usr/lib/ssl"

Kho lưu trữ chứng chỉ gốc nằm trong thư mục con certs.

ls -l /usr/lib/ssl/certs

lrwxrwxrwx 1 root root 14 Apr 21  2020 /usr/lib/ssl/certs -> /etc/ssl/certs

ls -l /etc/ssl/certs

…
-rw-r--r-- 1 root root 214904 Apr 15 17:01  ca-certificates.crt
…
lrwxrwxrwx 1 root root     50 Apr 15 16:57  GTS_Root_R1.pem -> /usr/share/ca-certificates/mozilla/GTS_Root_R1.crt
…

Nếu OpenSSL dựa vào kho lưu trữ chứng chỉ gốc của hệ thống mặc định như trong ví dụ ở trên, hãy xem phần cấp cao nhất Kho chứng chỉ gốc hệ thống của tôi nằm ở đâu và làm cách nào để cập nhật kho lưu trữ này? để đảm bảo gói chứng chỉ gốc của hệ thống luôn được cập nhật.

Để biết hướng dẫn tải openssl, hãy xem phần Tải OpenSSL.

Kho chứng chỉ gốc Java

Các ứng dụng Java có thể sử dụng kho lưu trữ chứng chỉ gốc riêng, mà trên các hệ thống Linux thường nằm tại /etc/pki/java/cacerts hoặc /usr/share/ca-certificates-java và có thể quản lý bằng công cụ dòng lệnh keytool trong Java.

Để nhập một chứng chỉ riêng lẻ vào kho chứng chỉ Java, hãy đưa ra lệnh sau:

keytool -import -trustcacerts -file cert.pem -alias alias -keystore certs.jks

Bạn chỉ cần thay thế cert.pem bằng tệp chứng chỉ tương ứng với từng chứng chỉ gốc được đề xuất, alias bằng một bí danh chứng chỉ duy nhất nhưng có ý nghĩa và certs.jks bằng tệp cơ sở dữ liệu chứng chỉ được dùng trong môi trường của bạn.

Để biết thêm thông tin, vui lòng tham khảo các bài viết sau trên Oracle và Stack Overflow:

Kho lưu trữ chứng chỉ gốc NSS của Mozilla

Theo mặc định, các ứng dụng sử dụng Mozilla NSS cũng có thể sử dụng cơ sở dữ liệu chứng chỉ trên toàn hệ thống thường nằm trong /etc/pki/nssdb hoặc trong một kho lưu trữ mặc định dành riêng cho người dùng trong ${HOME}/.pki/nssdb.

Để cập nhật cơ sở dữ liệu NSS, hãy sử dụng công cụ certutil.

Để nhập một tệp chứng chỉ riêng lẻ vào cơ sở dữ liệu NSS, hãy phát lệnh sau:

certutil -A -t "C,," -i cert.pem -n cert-name -d certdir

Bạn chỉ cần thay thế cert.pem bằng tệp chứng chỉ tương ứng với từng chứng chỉ gốc được đề xuất, cert-name bằng một biệt hiệu chứng chỉ có ý nghĩa và certdir bằng đường dẫn cơ sở dữ liệu chứng chỉ được sử dụng trong môi trường của bạn.

Để biết thêm thông tin, vui lòng tham khảo hướng dẫn sử dụng chính thức của Công cụ NSS certutil cũng như tài liệu về hệ điều hành của bạn.

Kho chứng chỉ gốc Microsoft .NET

Nhà phát triển Windows .NET có thể thấy ít nhất các bài viết sau đây của Microsoft hữu ích để cập nhật kho lưu trữ chứng chỉ gốc của mình:

Định dạng tệp chứng chỉ

Tệp PEM là gì?

Thư được tăng cường tính bảo mật (PEM) là một định dạng tệp văn bản chuẩn thực tế để lưu trữ và gửi chứng chỉ, khoá mã hoá, v.v., được chính thức hoá dưới dạng một tiêu chuẩn pháp lý trong RFC 7468.

Mặc dù định dạng tệp có thể đọc được, nhưng thông tin dữ liệu chứng chỉ nhị phân được mã hoá Base64 thì không. Tuy nhiên, thông số kỹ thuật PEM cho phép hiển thị văn bản giải thích trước hoặc sau nội dung chứng chỉ được mã hoá bằng văn bản. Nhiều công cụ sử dụng tính năng này để cung cấp bản tóm tắt dạng văn bản rõ ràng về các phần tử dữ liệu phù hợp nhất trong một chứng chỉ.

Bạn cũng có thể sử dụng các công cụ như openssl để giải mã toàn bộ chứng chỉ thành dạng mà con người có thể đọc được. Hãy xem phần Cách in chứng chỉ PEM ở dạng dễ đọc để biết thêm thông tin.

Tệp ".crt" là gì?

Các công cụ cho phép xuất chứng chỉ ở định dạng PEM thường sử dụng đuôi tệp là ".crt" để cho biết tệp đó sử dụng phương thức mã hoá văn bản.

Tệp DER là gì?

Quy tắc mã hoá đặc biệt (DER) là một định dạng nhị phân được chuẩn hoá để mã hoá chứng chỉ. Các chứng chỉ trong tệp PEM thường là chứng chỉ DER được mã hoá Base64.

Tệp ".cer" là gì?

Tệp đã xuất có hậu tố ".cer" có thể chứa chứng chỉ được mã hoá PEM, nhưng thường là chứng chỉ nhị phân, thường được mã hoá theo DER. Theo quy ước, tệp ".cer" thường chỉ chứa một chứng chỉ duy nhất.

Hệ thống của tôi từ chối nhập tất cả chứng chỉ từ roots.pem

Một số hệ thống như Java keytool, chỉ có thể nhập một chứng chỉ từ một tệp PEM, ngay cả khi tệp đó chứa nhiều chứng chỉ. Hãy xem câu hỏi Làm cách nào để trích xuất từng chứng chỉ từ roots.pem? để biết cách chia tệp trước tiên.

Làm cách nào để trích xuất từng chứng chỉ từ roots.pem?

Bạn có thể chia roots.pem thành các chứng chỉ thành phần bằng cách sử dụng tập lệnh bash đơn giản sau:

csplit -z -f roots.pem. roots.pem '/-----END CERTIFICATE-----/+1' '{*}' &>/dev/null && \
for f in roots.pem.*; \
  do mv "${f}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done

Thao tác này sẽ tạo một số tệp PEM riêng lẻ tương tự như những tệp được liệt kê ở đây:

ls -l *.pem

-rw-r----- 1 <user> <group>  2217 Apr 28 11:04 02265526.pem
-rw-r----- 1 <user> <group>  1722 Apr 28 11:04 062cdee6.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 0a775a30.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 1001acf7.pem
-rw-r----- 1 <user> <group>  1796 Apr 28 11:04 106f3e4d.pem
-rw-r----- 1 <user> <group>  1315 Apr 28 11:04 1d3472b9.pem
-rw-r----- 1 <user> <group>  1919 Apr 28 11:04 244b5494.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 2b349938.pem
-rw-r----- 1 <user> <group>  1651 Apr 28 11:04 2c543cd1.pem
-rw-r----- 1 <user> <group>  1858 Apr 28 11:04 3513523f.pem
-rw-r----- 1 <user> <group>  2000 Apr 28 11:04 40547a79.pem
-rw-r----- 1 <user> <group>  1862 Apr 28 11:04 4a6481c9.pem
-rw-r----- 1 <user> <group>  1927 Apr 28 11:04 4bfab552.pem
-rw-r----- 1 <user> <group>  1745 Apr 28 11:04 5ad8a5d6.pem
-rw-r----- 1 <user> <group>  1813 Apr 28 11:04 607986c7.pem
-rw-r----- 1 <user> <group>  2425 Apr 28 11:04 626dceaf.pem
-rw-r----- 1 <user> <group>  1738 Apr 28 11:04 653b494a.pem
-rw-r----- 1 <user> <group>  2294 Apr 28 11:04 6b99d060.pem
-rw-r----- 1 <user> <group>  2510 Apr 28 11:04 75d1b2ed.pem
-rw-r----- 1 <user> <group>  1788 Apr 28 11:04 76cb8f92.pem
-rw-r----- 1 <user> <group>  1383 Apr 28 11:04 7f3d5d1d.pem
-rw-r----- 1 <user> <group>  1668 Apr 28 11:04 93bc0acc.pem
-rw-r----- 1 <user> <group>  1220 Apr 28 11:04 9c8dfbd4.pem
-rw-r----- 1 <user> <group>  1838 Apr 28 11:04 9d04f354.pem
-rw-r----- 1 <user> <group>  1279 Apr 28 11:04 a3418fda.pem
-rw-r----- 1 <user> <group>  2194 Apr 28 11:04 aee5f10d.pem
-rw-r----- 1 <user> <group>  1249 Apr 28 11:04 b0e59380.pem
-rw-r----- 1 <user> <group>  1882 Apr 28 11:04 b1159c4c.pem
-rw-r----- 1 <user> <group>  2346 Apr 28 11:04 b727005e.pem
-rw-r----- 1 <user> <group>  1940 Apr 28 11:04 cbf06781.pem
-rw-r----- 1 <user> <group>  2609 Apr 28 11:04 d6325660.pem
-rw-r----- 1 <user> <group>  2474 Apr 28 11:04 dc4d6a89.pem
-rw-r----- 1 <user> <group>  1358 Apr 28 11:04 dd8e9d41.pem
-rw-r----- 1 <user> <group>  1972 Apr 28 11:04 ee64a828.pem
-rw-r----- 1 <user> <group>  1462 Apr 28 11:04 eed8c118.pem
-rw-r----- 1 <user> <group>  1944 Apr 28 11:04 f081611a.pem
-rw-r----- 1 <user> <group>  1488 Apr 28 11:04 f30dd6ad.pem
-rw-r----- 1 <user> <group>  1975 Apr 28 11:04 f387163d.pem
-rw-r----- 1 <user> <group>  2632 Apr 28 11:04 fc5a8f99.pem
-rw-r----- 1 <user> <group> 72865 Apr 20 12:44 roots.pem

Sau đó, bạn có thể nhập riêng các tệp PEM riêng lẻ, chẳng hạn như 02265526.pem, hoặc chuyển đổi thêm thành một định dạng tệp mà kho chứng chỉ của bạn chấp nhận.

Cách chuyển đổi giữa tệp PEM và định dạng được hệ thống của tôi hỗ trợ

Bạn có thể sử dụng công cụ dòng lệnh của bộ công cụ OpenSSL openssl để chuyển đổi tệp giữa tất cả các định dạng tệp chứng chỉ thường dùng. Dưới đây là hướng dẫn chuyển đổi từ tệp PEM sang các định dạng tệp chứng chỉ thường dùng nhất.

Để biết danh sách đầy đủ các tuỳ chọn hiện có, hãy xem tài liệu chính thức về Tiện ích dòng lệnh OpenSSL.

Để biết hướng dẫn tải openssl, hãy xem phần Tải OpenSSL.

Làm cách nào để chuyển đổi tệp PEM sang định dạng DER?

Khi sử dụng openssl, bạn có thể đưa ra lệnh sau để chuyển đổi tệp từ PEM sang DER:

openssl x509 -in roots.pem -outform der -out roots.der

Làm cách nào để chuyển đổi tệp PEM sang PKCS #7?

Khi sử dụng openssl, bạn có thể phát lệnh sau đây để chuyển đổi tệp từ PEM sang PKCS #7:

openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b

Làm cách nào để chuyển đổi tệp PEM sang PKCS #12 (PFX)?

Khi sử dụng openssl, bạn có thể đưa ra lệnh sau để chuyển đổi tệp từ PEM sang PKCS #12:

openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys

Bạn cần cung cấp mật khẩu tệp khi tạo tệp lưu trữ PKCS #12. Hãy nhớ lưu trữ mật khẩu ở nơi an toàn, nếu bạn không nhập ngay tệp PKCS #12 vào hệ thống của mình.

Liệt kê, in và xuất chứng chỉ từ kho chứng chỉ gốc

Làm cách nào để xuất chứng chỉ từ Kho khoá Java dưới dạng tệp PEM?

Khi sử dụng keytool, bạn có thể đưa ra lệnh sau để liệt kê tất cả chứng chỉ trong kho chứng chỉ của mình, cùng với bí danh mà bạn có thể sử dụng để xuất từng chứng chỉ:

keytool -v -list -keystore certs.jks

Bạn chỉ cần thay thế certs.jks bằng tệp cơ sở dữ liệu chứng chỉ được sử dụng trong môi trường của mình. Lệnh này cũng hiển thị bí danh của từng chứng chỉ mà bạn sẽ cần đến nếu muốn xuất chứng chỉ đó.

Để xuất từng chứng chỉ ở định dạng PEM, hãy dùng lệnh sau:

keytool -exportcert -rfc -keystore certs.jks -alias alias > alias.pem

Bạn chỉ cần thay thế certs.jks bằng tệp cơ sở dữ liệu chứng chỉ được sử dụng trong môi trường của mình và cung cấp alias và alias.pem tương ứng với chứng chỉ mà bạn muốn xuất.

Để biết thêm thông tin, vui lòng tham khảo hướng dẫn Tài liệu tham khảo về công cụ Java Platform, Standard Edition: keytool.

Làm cách nào để xuất chứng chỉ từ kho lưu trữ chứng chỉ gốc NSS dưới dạng tệp PEM?

Khi sử dụng certutil, bạn có thể đưa ra lệnh sau để liệt kê tất cả các chứng chỉ trong kho chứng chỉ, cùng với biệt hiệu mà bạn có thể sử dụng để xuất từng chứng chỉ:

certutil -L -d certdir

Bạn chỉ cần thay thế certdir bằng đường dẫn cơ sở dữ liệu chứng chỉ được sử dụng trong môi trường của mình. Lệnh này cũng sẽ hiển thị biệt hiệu của từng chứng chỉ mà bạn sẽ cần đến nếu muốn xuất chứng chỉ đó.

Để xuất một chứng chỉ riêng lẻ ở định dạng PEM, hãy đưa ra lệnh sau:

certutil -L -n cert-name -a -d certdir > cert.pem

Bạn chỉ cần thay thế certdir bằng đường dẫn cơ sở dữ liệu chứng chỉ được sử dụng trong môi trường của mình và cung cấp cert-name và cert.pem tương ứng với chứng chỉ mà bạn muốn xuất.

Để biết thêm thông tin, vui lòng tham khảo hướng dẫn chính thức về Chứng chỉ chính thức của Công cụ NSS cũng như tài liệu về hệ điều hành của bạn.

Cách in chứng chỉ PEM ở dạng người dùng có thể đọc được

Trong các ví dụ sau, chúng tôi giả định bạn có tệp GTS_Root_R1.pem với nội dung sau:

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
MIIFWjCCA0KgAwIBAgIQbkepxUtHDA3sM9CJuRz04TANBgkqhkiG9w0BAQwFADBH
MQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNlcnZpY2VzIExM
QzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwHhcNMTYwNjIyMDAwMDAwWhcNMzYwNjIy
MDAwMDAwWjBHMQswCQYDVQQGEwJVUzEiMCAGA1UEChMZR29vZ2xlIFRydXN0IFNl
cnZpY2VzIExMQzEUMBIGA1UEAxMLR1RTIFJvb3QgUjEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQC2EQKLHuOhd5s73L+UPreVp0A8of2C+X0yBoJx9vaM
f/vo27xqLpeXo4xL+Sv2sfnOhB2x+cWX3u+58qPpvBKJXqeqUqv4IyfLpLGcY9vX
mX7wCl7raKb0xlpHDU0QM+NOsROjyBhsS+z8CZDfnWQpJSMHobTSPS5g4M/SCYe7
zUjwTcLCeoiKu7rPWRnWr4+wB7CeMfGCwcDfLqZtbBkOtdh+JhpFAz2weaSUKK0P
fyblqAj+lug8aJRT7oM6iCsVlgmy4HqMLnXWnOunVmSPlk9orj2XwoSPwLxAwAtc
vfaHszVsrBhQf4TgTM2S0yDpM7xSma8ytSmzJSq0SPly4cpk9+aCEI3oncKKiPo4
Zor8Y/kB+Xj9e1x3+naH+uzfsQ55lVe0vSbv1gHR6xYKu44LtcXFilWr06zqkUsp
zBmkMiVOKvFlRNACzqrOSbTqn3yDsEB750Orp2yjj32JgfpMpf/VjsPOS+C12LOO
Rc92wO1AK/1TD7Cn1TsNsYqiA94xrcx36m97PtbfkSIS5r762DL8EGMUUXLeXdYW
k70paDPvOmbsB4om3xPXV2V4J95eSRQAogB/mqghtqmxlbCluQ0WEdrHbEg8QOB+
DVrNVjzRlwW5y0vtOUucxD/SVRNuJLDWcfr0wbrM7Rv1/oFB2ACYPTrIrnqYNxgF
lQIDAQABo0IwQDAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV
HQ4EFgQU5K8rJnEaK0gnhS9SZizv8IkTcT4wDQYJKoZIhvcNAQEMBQADggIBADiW
Cu49tJYeX++dnAsznyvgyv3SjgofQXSlfKqE1OXyHuY3UjKcC9FhHb8owbZEKTV1
d5iyfNm9dKyKaOOpMQkpAWBz40d8U6iQSifvS9efk+eCNs6aaAyC58/UEBZvXw6Z
XPYfcX3v73svfuo21pdwCxXu11xWajOl40k4DLh9+42FpLFZXvRq4d2h9mREruZR
gyFmxhE+885H7pwoHyXa/6xmld01D1zvICxi/ZG6qcz8WpyTgYMpl0p8WnK0OdC3
d8t5/Wk6kjftbjhlRn7pYL15iJdfOBL07q9bgsiG1eGZbYwE8na6SfZu6W0eX6Dv
J4J2QPim01hcDyxC2kLGe4g0x8HYRZvBPsVhHdljUEn2NIVq4BjFbkerQUIpm/Zg
DdIx02OYI5NaAIFItO/Nis3Jz5nu2Z6qNuFoS3FJFDYoOj0dzpqPJeaAcWErtXvM
+SUWgeExX6GjfhaknBZqlxi9dnKlC54dNuYvoS++cJEPqOba+MSSQGwlfnuzCdyy
F62ARPBopY+Udf90WuioAnwMCeKpSwughQtiue+hMZL77/ZRBIls6Kl0obsXs7X9
SQ98POyDGCBDTtWTurQ0sR8WNh8M5mQ5Fkzc4P4dyKliPUDqysU0ArSuiYgzNdws
E3PYJ/HQcu51OyLemGhmW/HGY0dVHLqlCFF1pkgl
-----END CERTIFICATE-----

In tệp chứng chỉ bằng OpenSSL

Phát lệnh

openssl x509 -in GTS_Root_R1.pem -text

sẽ xuất ra nội dung tương tự như:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Validity
            Not Before: Jun 22 00:00:00 2016 GMT
            Not After : Jun 22 00:00:00 2036 GMT
        Subject: C = US, O = Google Trust Services LLC, CN = GTS Root R1
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    …
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                E4:AF:2B:26:71:1A:2B:48:27:85:2F:52:66:2C:EF:F0:89:13:71:3E
    Signature Algorithm: sha384WithRSAEncryption
        …

Để biết hướng dẫn về cách tải openssl, hãy xem phần Cách tải OpenSSL.

In chứng chỉ bằng cách sử dụng keytool Java

Phát lệnh sau

keytool -printcert -file GTS_Root_R1.pem

sẽ xuất ra nội dung tương tự như:

Owner: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Issuer: CN=GTS Root R1, O=Google Trust Services LLC, C=US
Serial number: 6e47a9c54b470c0dec33d089b91cf4e1
Valid from: Wed Jun 22 02:00:00 CEST 2016 until: Sun Jun 22 02:00:00 CEST 2036
Certificate fingerprints:
   SHA1: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
   SHA256: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
Signature algorithm name: SHA384withRSA
Subject Public Key Algorithm: 4096-bit RSA key
Version: 3

Extensions:

#1: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]

#2: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]

#3: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: E4 AF 2B 26 71 1A 2B 48   27 85 2F 52 66 2C EF F0  ..+&q.+H'./Rf,..
0010: 89 13 71 3E                                        ..q>
]
]

Để biết hướng dẫn về cách tải keytool, hãy xem phần Tải công cụ khoá Java.

Làm cách nào để xem những chứng chỉ nào được cài đặt trong kho lưu trữ chứng chỉ gốc của tôi?

Điều này khác nhau tuỳ theo hệ điều hành và thư viện SSL/TLS. Tuy nhiên, các công cụ cho phép nhập và xuất chứng chỉ vào và đi từ kho chứng chỉ gốc thường cũng cung cấp một tuỳ chọn để liệt kê các chứng chỉ đã cài đặt.

Ngoài ra, nếu đã xuất thành công chứng chỉ gốc đáng tin cậy vào tệp PEM hoặc kho chứng chỉ gốc của bạn đã chứa các tệp PEM được lưu trữ, bạn có thể thử mở các tệp đó trong bất kỳ trình soạn thảo văn bản nào vì đây là định dạng tệp văn bản thuần tuý.

Bạn có thể gắn nhãn đúng cách tệp PEM, cung cấp thông tin mà con người có thể đọc được của tổ chức phát hành chứng chỉ liên quan (ví dụ như từ gói CA gốc đáng tin cậy của Google):

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1"
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

Tệp cũng có thể chỉ chứa phần chứng chỉ. Trong những trường hợp như vậy, tên của tệp, chẳng hạn như GTS_Root_R1.pem có thể mô tả chứng chỉ thuộc về CA nào. Chuỗi chứng chỉ giữa mã thông báo -----BEGIN CERTIFICATE----- và -----END CERTIFICATE----- cũng được đảm bảo là duy nhất cho mỗi CA.

Tuy nhiên, ngay cả khi thiếu các công cụ trên, vì mỗi chứng chỉ trong gói CA gốc đáng tin cậy của Google đều được gắn nhãn đúng cách, bạn có thể so khớp đáng tin cậy các CA gốc trong gói với các CA gốc trong kho chứng chỉ gốc của bạn bằng Issuer hoặc bằng cách so sánh chuỗi chứng chỉ tệp PEM.

Các trình duyệt web có thể sử dụng kho lưu trữ chứng chỉ gốc riêng hoặc dựa vào kho lưu trữ chứng chỉ gốc mặc định do hệ điều hành cung cấp. Tuy nhiên, tất cả trình duyệt hiện đại đều cho phép bạn quản lý hoặc ít nhất là xem tập hợp các CA gốc mà trình duyệt tin cậy. Hãy xem câu hỏi Các ứng dụng JavaScript có nguy cơ bị lỗi không? để biết thêm chi tiết.

Để biết hướng dẫn dành riêng cho điện thoại di động, hãy xem câu hỏi riêng Làm cách nào để kiểm tra các chứng chỉ gốc đáng tin cậy trên điện thoại di động?.

Phụ lục

Bạn cần thêm thông tin?

Luôn chủ yếu dựa vào tài liệu về hệ điều hành, tài liệu về (các) ngôn ngữ lập trình ứng dụng cũng như tài liệu của mọi thư viện bên ngoài mà ứng dụng của bạn đang sử dụng.

Mọi nguồn thông tin khác bao gồm cả phần Câu hỏi thường gặp này đều có thể đã lỗi thời hoặc không chính xác và không được coi là nguồn thông tin chính thống. Tuy nhiên, bạn vẫn có thể tìm thấy thông tin hữu ích trên nhiều cộng đồng Hỏi và đáp của Stack Exchange, cũng như các trang web như AdamW trên Linux và nhiều nền tảng khác, blog xác nhận, cùng nhiều trang web khác.

Ngoài ra, vui lòng xem Câu hỏi thường gặp về Google Trust Services.

Để biết thêm thông tin chi tiết về các chủ đề nâng cao, chẳng hạn như ghim chứng chỉ, bạn có thể tìm thấy bài viết Chứng chỉ và ghim khoá công khai của Dự án bảo mật ứng dụng web mở (OWASP) và Bản tóm tắt về tính năng ghim để cung cấp nhiều thông tin. Để biết hướng dẫn dành riêng cho Android, vui lòng tham khảo tài liệu chính thức về Các phương pháp hay nhất về bảo mật và quyền riêng tư của Android về Bảo mật bằng HTTPS và SSL. Để thảo luận về chứng chỉ so với tính năng ghim khoá công khai trên Android, bạn có thể thấy bài đăng trên blog của Matthew Dolan Bảo mật Android: Ghim SSL rất hữu ích.

Tài liệu đào tạo về Các phương pháp hay nhất cho Android về bảo mật và quyền riêng tư về Cấu hình bảo mật mạng và bài đăng trên blog của JeroenHD Android 7 Nougat và các tổ chức phát hành chứng chỉ cung cấp thêm thông tin về cách quản lý các chứng chỉ đáng tin cậy khác trên Android.

Để biết danh sách đầy đủ các CA gốc mà AOSP tin cậy, hãy tham khảo kho lưu trữ Git ca-certificates. Đối với mọi phiên bản dựa trên phát triển nhánh Android không chính thức, chẳng hạn như LineageOS, hãy tham khảo các kho lưu trữ thích hợp do nhà cung cấp hệ điều hành cung cấp.