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:

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

Thuật ngữ

Dưới đây, chúng tôi đã thu thập danh sách các thuật ngữ quan trọng nhất mà bạn cần quen thuộc với tài liệu này. Để có thông tin tổng quan toàn diện hơn về vui lòng chuyển sang Câu hỏi thường gặp về Google Trust Services.

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 dùng để xác thực và thiết lập kết nối an toàn vào trang web. Chứng chỉ do các thực thể phát hành và có chữ ký mã hoá đượ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 các Tổ chức phát hành chứng chỉ đáng tin cậy cấp để biết được thông tin đã truyền được gửi đến đúng máy chủ và thông tin đó được mã hoá trong khi truyền tải.
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á thông tin liên lạc qua Internet. Giao thức SSL không còn được coi là bảo mật nữa và không nên sử dụng.
Bảo mật tầng truyền tải (TLS): Bảo mật tầng truyền tải là giải pháp 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. Giải pháp này cấp tài liệu (chứng chỉ) được bảo vệ bằng mật mã để chứng thực rằng một pháp nhân (ví dụ: trang web) đúng là người mà pháp nhân đó tuyên bố.; Trước khi cấp Chứng chỉ, các CA chịu trách nhiệm xác minh rằng 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ể đề cập đến cả hai tổ chức như Google Dịch vụ tin cậy và vào các hệ thống cấp chứng chỉ.
Kho lưu trữ chứng chỉ gốc: Kho lưu trữ 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ỉ được tin cậy bởi Nhà cung cấp phần mềm ứng dụng. Hầu hết các trình duyệt web và hệ điều hành đều kho chứng chỉ gốc của riêng họ.; Để được đưa vào kho lưu trữ 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 đặt ra.; Thông thường, các nguyên tắc này bao gồm việc tuân thủ các tiêu chuẩn ngành như Các yêu cầu của CA/Diễn đàn trình duyệt.
Tổ chức phát hành chứng chỉ gốc: Tổ chức phát hành chứng chỉ gốc (hay đúng hơn là chứng chỉ của tổ chức này) là chứng chỉ trên cùng 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 lưu trữ tại các cơ sở có độ bảo mật cao và được lưu trữ ngoại tuyến trạng thái để bảo vệ chúng khỏi bị truy cập trái phép.
Tổ chức phát hành chứng chỉ trung gian: Một 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à chứng chỉ được dùng để ký các chứng chỉ khác trong chuỗi chứng chỉ.; Các CA trung gian chủ yếu tồn tại để cho phép cấp chứng chỉ trực tuyến khi cho phép chứng chỉ CA gốc vẫn ở chế độ ngoại tuyến.; Các CA trung gian còn được gọi là CA cấp dưới.
Cơ quan cấp chứng chỉ: Một tổ chức phát hành chứng chỉ, hay đúng hơn là chứng chỉ của tổ chức đó, là chứng chỉ được dùng để ký chứng chỉ ở dưới cùng trong một chứng chỉ của bạn.; 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ỉ leaf. Trong tài liệu này, chúng tôi cũng sẽ sử dụng cụm từ chứng chỉ máy chủ.
Chuỗi chứng chỉ: Chứng chỉ được liên kết với người phát hành chứng chỉ (được ký bằng mã hoá). Đáp chuỗi chứng chỉ được tạo từ leaf-certificate, tất cả các chứng chỉ của nhà phát hành tương ứng và một chứng chỉ gốc.
Ký chéo: Các nhà cung cấp phần mềm ứng dụng ứng dụng phải cập nhật chứng chỉ gốc của mình để thêm các chứng chỉ CA mới để họ được các sản phẩm của họ tin cậy. Có thể mất chút thời gian để các sản phẩm có chứa chứng chỉ CA mới được đượ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 "dấu chéo" của một tổ chức phát hành chứng chỉ (CA) lâu năm khác. Điều này hiệu quả tạo ra 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 CA có trong kho lưu trữ chứng chỉ gốc, ứng dụng sẽ tạo một chuỗi chứng chỉ khác tới một gốc mà họ tin tưởng.

Thông tin chung

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

Lưu ý quan trọng: Vào năm 2021, Google sẽ tiếp tục chuyển đổi sang mô hình tổ chức phát hành chứng chỉ gốc (CA) Google Trust Services (GTS), bắt đầu vào năm 2017. Tổ chức phát hành chứng chỉ gốc được dùng để xác minh tính bảo mật của tất cả kết nối TLS vào Nền tảng Google Maps. Đại đa số ứng dụng khách sẽ không bị ảnh hưởng bởi thay đổi này nhưng chủ sở hữu của một số ứng dụng, đặc biệt là những người dùng không hành động trong năm 2017 có thể cần cập nhật các dịch vụ khác để đảm bảo quá trình chuyển đổi diễn ra suôn sẻ trong phần còn lại của quá trình di chuyển bằng cách theo các đề xuất trong tài liệu này.

Tổng quan

Vào 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 gốc chứng chỉ, chữ ký mã hoá là cơ sở của Internet TLS bảo mật được sử dụng bởi HTTPS.

Sau giai đoạn đầu tiên, bảo mật TLS của các dịch vụ trên Nền tảng Google Maps đã được đảm bảo bởi GS Root R2, một gốc rất nổi tiếng và đáng tin cậy tổ chức phát hành chứng chỉ (CA) mà Google mua lại từ GMO GlobalSign để giảm bớt quá trình chuyển đổi sang CA gốc do Dịch vụ Google Trust Services (GTS) tự cấp.

Trong 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à ứng dụng) tin cậy) và do đó có thể thiết lập kết nối an toàn đến các máy chủ của Nền tảng Google Maps trong giai đoạn đầu tiên của quá trình di chuyển.

Tuy nhiên, theo thiết kế, CA có thể không cấp chứng chỉ hợp lệ ngoài chứng chỉ của chính nó. Khi GS Root R2 hết hạn vào 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, GTS Root R1 Cross, sử dụng chứng chỉ do CA gốc của Google cấp Hàm GTS Root R1.

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

Do đó, hầu hết khách hàng Khách hàng của Nền tảng Google Maps sẽ nhận biết một trong hai (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 tiên của vào năm 2018, giả sử tại thời điểm đó họ làm theo hướng dẫn của chúng tôi, đang cài đặt tất cả chứng chỉ từ gói CA gốc 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 các nền tảng không chuẩn hoặc cũ và/hoặc bạn duy trì kho lưu trữ chứng chỉ gốc của riêng
bạn đã không hành động trong giai đoạn 2017-2018, trong giai đoạn đầu của Di chuyển tổ chức phát hành chứng chỉ gốc hoặc bạn không cài đặt toàn bộ bộ chứng chỉ từ gói Tổ chức phát hành chứng chỉ 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 phải được cập nhật theo chứng chỉ gốc để có thể đảm bảo không bị gián đoạn Nền tảng Google Maps sử dụng 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. Để xem hướng dẫn chung, vui lòng hãy tham khảo 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 cũng nên tiếp tục lưu trữ kho chứng chỉ gốc của mình trong đồng bộ hoá với gói CA gốc chọn lọc ở trên để đảm bảo dịch vụ của bạn hoạt động hiệu quả trong tương lai các thay đổi của tổ chức phát hành chứng chỉ gốc. Tuy nhiên, những việc này sẽ được thông báo trước. Xem các phần 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, CA gốc mà Nền tảng Google Maps đã sử dụng từ đầu năm 2018 sẽ hết hạn vào ngày 15 tháng 12 năm 2021. Do đó, Google sẽ di chuyển sang 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 đổi sang chứng chỉ cơ sở hạ tầng 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 sẵn với Chứng chỉ GTS Root R1 hoặc sẽ nhận được thông qua các bản cập nhật phần mềm thông thường, và GlobalSign Root CA - R1 đều cần có trên các hệ thống cũ.

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

các 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 lưu trữ chứng chỉ gốc của riêng
bạn đã không hành động trong giai đoạn 2017-2018, trong giai đoạn đầu của Di chuyển tổ chức phát hành chứng chỉ gốc hoặc bạn không cài đặt toàn bộ bộ chứng chỉ từ gói Tổ chức phát hành chứng chỉ gốc của Google

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 cung cấp các thông tin chung hướng dẫn kiểm tra xem hệ thống của bạn có bị ảnh hưởng hay không.

Xem 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 của Google đáng tin cậy? để 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 cho bản cập nhật. Câu hỏi thường gặp này cũng được cập nhật trong suốt quá trình di chuyển, bất c�� khi nào chúng tôi 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 làm theo Blog 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 càng sớm càng tốt, 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 nội dung cập nhật trên diễn đàn về những thay đổi có khả năng ảnh hưởng đến số lượng khách hàng lớn hơn.

Chúng tôi sử dụng nhiều dịch vụ của Google. Quá trình di chuyển Tổ chức phát hành chứng chỉ gốc có ảnh hưởng đến tất cả những tổ chức đó không?

Có, quá trình di chuyển Tổ chức phát hành chứng chỉ gốc sẽ diễn ra trên tất 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 xác minh rằng thư mục gốc kho chứng chỉ mà các ứng dụng khách trên Nền tảng Google Maps sử dụng chứa tất cả CA được liệt kê trong gói CA gốc đáng tin cậy của Google, các dịch vụ đó sẽ không bị ảnh hưởng bởi quá trình di chuyển đang diễn ra và giữ nguyên thì tính năng đồng bộ hoá cũng sẽ bảo vệ bạn khỏi những thay đổi về CA gốc trong tương lai.

Xem 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 của Google đáng tin cậy? và Những loại ứng dụng nào có nguy cơ gặp 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 dưới đây cũng cung cấp hướng dẫn chung để thử nghiệm 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 bạn có thể thiết lập kết nối TLS với Điểm cuối thử nghiệm chéo GTS Root R1, bạn sẽ không bị ảnh hưởng bởi ngày hết hạn GS Root R2.
Nếu bạn có thể thiết lập kết nối TLS với Điểm cuối kiểm thử R1 gốc GTS, ứng dụng của bạn thậm chí sẽ được bảo vệ trước khi hết hạn GTS Root R1 Cross và GlobalSign Root CA – R1 vào năm 2028.

Hệ thống của bạn thường sẽ tương thích với thay đổi gốc này đối với tổ chức phát hành chứng chỉ (CA) nếu:

dịch vụ của bạn chạy trên hệ điều hành chính được duy trì và bạn có giữ nguyên cả hệ điều hành và các thư viện mà dịch vụ của bạn sử dụng được vá và bạn không duy trì kho 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ả các CA gốc qua 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 cho để tránh bị gián đoạn dịch vụ trong tương lai.

Xem 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 của Google đáng tin cậy? để biết toàn bộ thông tin chi tiết.

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

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

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

Các lệnh openssl hiển thị bên dưới là 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 dùng một phiên bản cũ, 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. Để xem hướng dẫn về việc tải openssl, hãy xem phần Nhận OpenSSL bên dưới.

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

Để biết hướng dẫn thử nghiệm bê tông, vui lòng 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.

Kiểm thử kho lưu trữ 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.demo.pki.goog/; \
openssl s_client -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;

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

Tải xuống gói CA gốc đáng tin cậy của Google, sau đó hãy 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.demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -CAfile roots.pem -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;

Quá trình di chuyển Tổ chức phát hành chứng chỉ 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ông bố vào tháng 1 năm 2017, bắt đầu từ 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ông bố vào tháng 3 năm 2021, và sẽ triển khai trong vài 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 trước hết hạn chứng chỉ trong tương lai.

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

Xem thêm 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 của Google đáng tin cậy? để 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 dần dần mở rộng sang nhiều trung tâm dữ liệu hơn cho đến khi có mặt trên toàn cầu mức độ phù hợp.
Nếu phát hiện thấy vấn đề nghiêm trọng ở bất kỳ giai đoạn nào, thử nghiệm có thể được hoàn nguyên tạm thời trong khi các vấn đề được giải quyết.
Dựa trên dữ liệu đầu vào từ những lần lặp lại trước, các dịch vụ sau này của Google sẽ được đưa vào bản phát hành cho đến khi tất cả dịch vụ của Google đều được chuyển sang các chứng chỉ mới.

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

Ngày càng 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 trung tâm dữ liệu mới được di chuyển sang. Những thay đổi này sẽ được bản địa hoá một chút, vì các yêu cầu của máy khách có xu hướng được chuyển tiếp đến các máy chủ theo khu vực địa lý gần trung tâm dữ liệu.

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

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 thêm hướng dẫn.

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

Các ứ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 được có thể xác minh kết nối TLS (Bảo mật tầng truyền tải) của họ với Nền tảng Google Maps. Trong phần này trong trường hợp cụ thể, ứng dụng khách thường sẽ đưa ra cảnh báo rằng 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 của Nền tảng Google Maps, hoặc họ có thể từ chối tiếp tục với của bạn.

Những yêu cầu tối thiểu để ứng dụng TLS giao tiếp với Nền tảng Google Maps là gì?

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

Đối với các yêu cầu khác, vui lòng tham khảo mục Ứng dụng TLS cần đáp ứng những yêu cầu nào để giao tiếp với Google? trong phần 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

Các ứng dụng dịch vụ web của Nền tảng Google Maps

Nếu bạn đang dùng một hệ điều hành chính, chẳng hạn như Ubuntu, Red Hat, Windows 10 hoặc Máy chủ 2019, OS X) vẫn được duy trì và nhận các bản cập nhật thường xuyên, chế độ mặc định kho lưu trữ chứng chỉ gốc phải bao gồm 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, bạn có thể hoặc có thể không có chứng chỉ GTS Root R1. Tuy nhiên, 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 mã nguồn cũ nhất và CA gốc đáng tin cậy nhất.

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

Các ứng dụng của 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 trên thư mục gốc chứng chỉ của trình duyệt web đang chạy ứng dụng. Xem phần Các ứng dụng JavaScript có nguy cơ bị lỗi không? để biết thêm 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 dành cho Android, SDK Bản đồ 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 á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.

Xem câu hỏi Ứng dụng di động có có nguy cơ bị lỗi 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 đang được 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 của Google đáng tin cậy?, 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 chứng chỉ gốc của riêng bạn.

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

Để biết thêm thông tin về chứng chỉ hoặc ghim khóa công khai, hãy tham khảo 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 phải luôn đồng bộ hoá kho chứng chỉ gốc của mình với gói CA gốc của Google đáng tin cậy?

Danh sách các CA gốc trong gói CA gốc của Google bao gồm tất cả CA mà các dịch vụ của Google có thể sử dụng hợp lý tại trong tương lai gần.

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

Đ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 nền tảng không được duy trì phiên bản hệ thống của bạn, vì các lý do khác, bạn không thể giữ lại hệ điều hành của mình và thư viện đã được vá, hoặc bạn duy trì kho lưu trữ chứng chỉ gốc của riêng mình.

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. Thường xuyên việc lưu trữ chứng chỉ gốc của bạn đồng bộ với danh sách đã chọn sẽ bảo vệ các dịch vụ của bạn khỏi bị gián đoạn dịch vụ trong tương lai (do những thay đổi của CA) và sẽ duy trì hoạt động của các dịch vụ sau khi cả hai GTS Root R1 Cross và GlobalSign Root CA – R1.

Ngoài ra, vui lòng tham khảo câu hỏi Tôi đang phát triển 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 phần Câu hỏi thường gặp về GTS để có các đề xuất khác.

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

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

Để ngăn chặn điều này cho các dịch vụ của mình, bạn chỉ nên cài đặt thư mục gốc chứng chỉ từ gói CA gốc 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ỉ được neo vào đó.

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

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

Chứng chỉ gốc GTS đã được nhúng và tin cậy bởi hầu hết và dấu chéo từ GMO GlobalSign sẽ đảm bảo ngay cả đối với hầu hết người dùng cuối sử dụng trình duyệt cũ. bao gồm tất cả chính thức các trình duyệt được hỗ trợ cho API Maps JavaScript.

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 chứng chỉ mà trình duyệt tin tưởng. Mặc dù vị trí chính xác còn tuỳ thuộc vào vị trí trình duyệt web, thường thì bạn có thể tìm thấy danh sách chứng chỉ ở đâu đó trong 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ị iOS của Android và Apple vẫn nhận được các bản cập nhật thường xuyên từ thiết bị nhà sản xuất nào cũng được kỳ vọng là bằng chứng trong tương lai. Hầu hết điện thoại Android cũ nhất mô hình ít nhất bao gồm chứng chỉ GlobalSign Root CA - R1, mặc dù danh sách chứng chỉ tin cậy có thể khác nhau 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, các CA gốc GTS, bao gồm cả GTS Root R1 có thể vẫn được hỗ trợ bị hạn chế 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 mỗi phiên bản iOS gần đây phiên bản trên trang hỗ trợ của công cụ đó. 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.

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ẽ có chứng chỉ gốc của Google Trust Services?

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 lớn 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, như Apple và Microsoft, nhưng cũng nhóm Android và Chrome OS của riêng mình; nhà phát triển trình duyệt, chẳng hạn như Mozilla, Apple Microsoft mà còn cả nhóm Chrome của Google; các nhà sản xuất phần cứng, chẳng hạn như điện thoại, hộp giải mã tín hiệu số, 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 bảo trì hỗ trợ GTS Root CA mới của Google, bao gồm GTS Root R1 và thậm chí cả phiên bản cũ các hệ thống có nhiều khả năng sẽ hỗ trợ GlobalSign Root CA - R1, vốn sẽ là được dùng để ký chéo chứng chỉ do Google cấp trong những năm tiếp theo.

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 thời gian quyền kiểm soát Google, 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 có sẵn.

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

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 của hệ điều hành không cung cấp curl, bạn có thể tải ứng dụng này xuống tại https://curl.haxx.se/. Bạn có thể: tải mã nguồn xuống và tự biên dịch công cụ hoặc tải một tệp được biên dịch trước tệp nhị phân, nếu có sẵn cho nền tảng của bạn.

Tải OpenSSL

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

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, nhưng công cụ dòng lệnh tshark của nó và tcpdump, phiên bản được biên dịch trước của hai phiên bản đầu tiên cho các hệ điều hành khác có thể được tại https://www.wireshark.org.

Có thể tìm thấy mã nguồn cho 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 người đàn ông của Tshark và trên trang thông tin người dùng của Tcpdump, .

Tải keytool Java

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

Việc cần làm khi ngừng sản xuất

Việc cần làm chính là cài đặt thư mục gốc cần thiết chứng chỉ từ gói CA gốc đáng tin cậy của Google vào các chứng chỉ gốc mà ứng dụng của bạn sử dụng.

Làm việc cùng với quản trị viên hệ thống để nâng cấp thiết bị kho lưu trữ chứng chỉ gốc.
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 cho 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 theo cách được mô tả trong mục Liên hệ với nhóm hỗ trợ Nền tảng Google Maps. Lưu ý: Đối với các vấn đề riêng của nền tảng, chúng tôi chỉ cung cấp hướng dẫn khi bạn cố gắng hết sức cơ sở.
Gắn dấu sao vấn đề công khai 186840968 cho các bản cập nhật bổ sung 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

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 hướng dẫn khắc phục sự cố chung.

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

Nếu vấn đề chưa được giải quyết và bạn quyết định liên hệ với Nền tảng Google Maps hỗ trợ, hãy sẵn sàng cung cấp 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?
Vấn đề này ảnh hưởng đến(các) API nào?
Chính xác thì vấn đề bắt đầu từ khi nào?

Kết quả đầu ra 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.demo.pki.goog/; \
openssl s_client -connect good.gtsr1.demo.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr1x.demo.pki.goog/; \
openssl s_client -connect good.gtsr1x.demo.pki.goog:443 -showcerts </dev/null;

Để biết 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?.

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

Vui lòng làm theo hướng dẫn dành cho Tạo yêu cầu hỗ trợ dưới 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 mục Khắc phục sự cố ban đầu, vui lòng cung cấp cả 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 của bạn là gì?
Nếu có thể, quá trình chụp gói tcpdump hoặc Wireshark cho TLS không thành công với https://maps.googleapis.com/ ở định dạng PCAP bằng cách sử dụng độ dài chụp nhanh đủ lớn để thu thập toàn bộ gói mà không cần cắt bớt (ví dụ: sử dụng -s0 trên các phiên bản tcpdump cũ hơn).
Nếu có thể, nhật ký trích dẫn từ dịch vụ của bạn cho thấy kết nối TLS chính xác lý do lỗi, tốt nhất là với thông tin chuỗi chứng chỉ máy chủ đầy đủ.

Để biết 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ấn đề công khai 186840968

Khi đăng bình luận về vấn đề công khai 186840968, vui lòng bao gồm 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ể dùng hàm nslookup trong tương tác chế độ:

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

Cách diễn giải kết quả cuộn tròn

Việc chạy curl với cờ -vvI sẽ cung cấp rất nhiều thông tin hữu ích của bạn. Dưới đâ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ị kết quả từ TLS cũng như thông tin chấm dứt kết nối.
Các dòng bắt đầu bằng ">" hiển thị yêu cầu HTTP gửi đi curl đang gửi.
Các dòng bắt đầu bằng "<" hiển thị phản hồi HTTP mà ứng dụng nhận được máy chủ.
Nếu giao thức là HTTPS, thì ">" sẽ xuất hiện hoặc '<' ngụ ý bắt tay TLS thành công.

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 được sử dụng kho lưu trữ chứng chỉ gốc, nhưng đầu ra chính xác có thể khác nhau theo từng hệ thống như trình bày ở đâ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

Đầu ra từ máy Ubuntu hoặc Debian Linux sử dụng tệp PEM của 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 gửi đi chứa tiêu đề Tác nhân người dùng có thể hữu ích thông tin 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ư dòng trong mã mẫu này, cho biết kết nối là đã chấm dứt bắt tay giữa TLS do chứng chỉ máy chủ không đáng tin cậy. Chiến lược phát hành đĩa đơn không có đầu ra gỡ lỗi bắt đầu bằng > hoặc < cũng các chỉ báo rõ ràng cho thấy một lần 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

Quá trình 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 tương tự nhau với các lệnh trong mã mẫu này. Bộ thuật toán mật mã dùng cho mã hoá kết nối cũng như thông tin chi tiết về máy chủ được chấp nhận chứng chỉ. Hơn nữa, sự hiện diệ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 TLS được mã hoá:

*   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

Giả sử dữ liệu đầu ra có định dạng PEM, ví dụ: dữ liệu đầu ra 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ỉ 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 cửa sổ dòng lệnh.
Nhấn phím Return.

Ví dụ về dữ liệu đầ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.demo.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.demo.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 của tôi?

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 trong phần Cài đặt. Bảng này hiển thị các phần Cài đặt chính xác đường dẫn trình đơn:

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
8x, 9	Cài đặt > Bảo mật và Vị trí > Mã hoá và credentials > 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à credentials > Thông tin xác thực đáng tin cậy

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

Phiên bản Android	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)
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 mà không cần cập nhật chương trình cơ sở hoặc can thiệp vào hệ thống của thiết bị. Tuy nhiên, trên hầu hết thiết bị Android phiên bản vẫn đang được sử dụng rộng rãi, nhóm các gốc đáng tin cậy hiện tại chứng chỉ có khả năng cung cấp dịch vụ không gián đoạn trong nhiều năm để vượt ra ngoài vòng đời hiệu quả của hầu hết các thiết bị hiện có.

Kể từ phiên bản 7.0, Android cung cấp cho các nhà phát triển ứng dụng một chế độ bảo mật để thêm chứng chỉ đáng tin cậy mà chỉ được . Bạn có thể thực hiện việc này bằng cách nhóm 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 Các phương pháp hay nhất về Android về bảo mật và Quyền riêng tư Cấu hình bảo mật mạng tài liệu đào tạo của bạn.

Tuy nhiên, vì 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, những nỗ lực đó có thể chỉ mang lại giải pháp một phần.

Trên các thiết bị cũ, lựa chọn duy nhất mà bạn có thể sử dụng là sử dụng CA do người dùng thêm, được cài đặt bởi một chính sách nhóm công ty được áp dụng ở cuối thiết bị của người dùng hoặc do chính người dùng cuối thực hiện.

Cửa hàng tin cậy iOS

Mặc dù Apple không trực tiếp hiển thị nhóm chứng chỉ gốc đáng tin cậy mặc định đến người dùng điện thoại di động, công ty có các đường liên kết đến nhóm CA gốc đáng tin cậy dành cho iOS phiên bản 5 trở lên theo 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 phải hiển thị trong Cài đặt > Chung > Hồ sơ. Nếu không có thêm các chứng chỉ đã được cài đặt, thì mục trong trình đơn Hồ sơ có thể không hiển thị.

Bảng này minh hoạ tính sẵn có của các chứng chỉ gốc quan trọng nhất cho mỗi phiên bản iOS, dựa trên các nguồn bên 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+

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

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

/usr/local/share/ca-certificates: Debian, Ubuntu, RHEL cũ hơn và Phiên bản CentOS
/etc/pki/ca-trust/source/anchors và /usr/share/pki/ca-trust-source: Dành cho người dùng phớt, 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 những 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 ứ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ả vị trí mặc định kho lưu trữ chứng chỉ gốc bằng lệnh sau:

openssl version -d

Lệnh này in ra OPENSSLDIR, tương ứng với cấp cao nhất Bạn có thể tìm thấy thư mục và các cấu hình của thư mục 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 mục cấp cao nhất Kho lưu trữ chứng chỉ gốc của hệ thống nằm ở đâu và làm cách nào để cập nhật chứng chỉ đó? để đảm bảo gói chứng chỉ gốc của hệ thống được cập nhật.

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

Kho lưu trữ 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, trên Linux hệ thống thường được đặt tại /etc/pki/java/cacerts hoặc /usr/share/ca-certificates-java, có thể được quản lý bằng keytool Java công cụ dòng lệnh.

Để nhập một chứng chỉ riêng lẻ vào kho chứng chỉ Java của bạn, hãy phát hành sau đây:

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 với chứng chỉ duy nhất nhưng có ý nghĩa bí danh và certs.jks với tệp cơ sở dữ liệu chứng chỉ được sử dụng trong môi trường.

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

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

Ứng dụng dùng Mozilla NSS theo mặc định cũng có thể sử dụng cơ sở dữ liệu chứng chỉ trên toàn hệ thống thường được đặt dưới /etc/pki/nssdb hoặc cửa hàng 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 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 dùng sau đây:

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 với một chứng chỉ có ý nghĩa biệt hiệu và certdir bằng đường dẫn cơ sở dữ liệu chứng chỉ được sử dụng trong môi trường.

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

Kho lưu trữ chứng chỉ gốc .NET của Microsoft

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

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

Tệp PEM là gì?

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

Mặc dù con người có thể đọc được định dạng tệp này, Tệp nhị phân được mã hoá Base64 . Tuy nhiên, quy cách PEM cho phép đang phát ra nội dung giải thích trước hoặc sau nội dung chứng chỉ được mã hoá bằng văn bản, đồng thời nhiều công cụ sử dụng tính năng này cũng cung cấp bản tóm tắt dạng văn bản rõ ràng về dữ liệu có liên quan nhất trong một chứng chỉ.

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

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

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 ".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á phân biệt (DER) là định dạng nhị phân được chuẩn hoá cho chứng chỉ mã hoá. Chứng chỉ ở định dạng PEM tệp thường Chứng chỉ DER được mã hoá Base64.

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

Tệp đã xuất có đuôi ".cer" hậu tố 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á DER. Theo quy ước, ".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ừ tệp PEM, ngay cả khi tệp này chứa nhiều tệp. Xem câu hỏi Làm cách nào để trích xuất từng chứng chỉ từ roots.pem? để xem 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ể phân tách roots.pem thành các chứng chỉ thành phần bằng cách sử dụng phương thức sau tập lệnh bash đơn giản:

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 ra một số tệp PEM riêng lẻ tương tự như các tệp được liệt kê tại đâ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 các tệp PEM riêng lẻ, chẳng hạn như 02265526.pem riêng biệt hoặc chuyển đổi thêm sang đị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ợ

Công cụ dòng lệnh của bộ công cụ OpenSSL Có thể sử dụng openssl để chuyển đổi tệp giữa tất cả chứng chỉ thường dùng định dạng tệp. Hướng dẫn chuyển đổi từ tệp PEM sang tệp thông dụng nhất được liệt kê bên dưới.

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

Để biết hướng dẫn cách 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 thành DER:

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

Làm thế nào để chuyển đổi tệp PEM thành PKCS #7?

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

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

Làm thế nào để chuyển đổi tệp PEM thành PKCS #12 (PFX)?

Khi sử dụng openssl, bạn có thể đưa ra lệnh sau để chuyển đổi tệp từ PEM tới 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. Nhãn hiệu lưu trữ mật khẩu ở nơi an toàn, nếu bạn không nhập ngay PKCS #12 vào hệ thống của bạn.

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

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ả trong kho chứng chỉ của bạn, cùng với bí danh mà bạn có thể sử dụng để xuất từng tệp:

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 dùng trong môi trường. Lệnh này cũng sẽ hiển thị bí danh của mỗi chứng chỉ. bạn cần đến nếu muốn xuất dữ liệu đó.

Để 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 dùng trong và cung cấp một 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 sử dụng Nền tảng Java, Tài liệu tham khảo về công cụ 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ả trong kho chứng chỉ của bạn, cùng với biệt hiệu bạn có thể sử dụng để xuất từng tệp:

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 dùng trong môi trường. Lệnh này cũng hiển thị biệt hiệu của từng chứng chỉ, bạn cần đến nếu muốn xuất dữ liệu đó.

Để xuất từng chứng chỉ ở định dạng PEM, hãy dùng 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 dùng trong và cung cấp một 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 Chứng chỉ của Công cụ NSS hướng dẫn sử dụng 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 dễ đọc

Trong các ví dụ sau, chúng tôi giả định bạn có tệp GTS_Root_R1.pem với những 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

Ra 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 cách tải openssl, hãy xem phần Tải OpenSSL.

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

Đưa ra 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 cách tải keytool, hãy xem phần Nhận keytool 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ụ mà cho phép nhập và xuất chứng chỉ đến và từ các 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 bạn đã xuất thành công chứng chỉ gốc đáng tin cậy vào PEM hoặc kho chứng chỉ gốc của bạn đã chứa tệp PEM đã lưu trữ, thì bạn có thể thử mở tệp trong bất kỳ trình chỉnh sửa văn bản nào, vì đây là định dạng tệp văn bản thuần tuý.

Tệp PEM có thể được gắn nhãn đúng cách, cung cấp thông tin con người có thể đọc được về tổ chức phát hành chứng chỉ liên quan (ví dụ: gói CA gốc 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 này 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 chẳng hạn như GTS_Root_R1.pem có thể mô tả chứng chỉ thuộc 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 bạn thiếu các công cụ nêu trên, vì mỗi chứng chỉ trong gói CA gốc đáng tin cậy của Google là được gắn nhãn đúng cách, bạn có thể tự tin so khớp các CA gốc từ trình tạo gói các tệp từ chứng chỉ gốc của bạn lưu trữ theo 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 của riêng mình hoặc dựa vào kho lưu trữ chứng chỉ gốc một mã do cơ quan điều hành cung cấp. Tuy nhiên, tất cả các trình duyệt hiện đại sẽ cho phép bạn quản lý hoặc ít nhất là xem nhóm các CA gốc mà họ tin tưởng. 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 chứng chỉ gốc đáng tin cậy trên điện thoại di động của tôi?.

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 của(các) ngôn ngữ lập trình ứng dụng, cũng như tài liệu từ mọi thư viện bên ngoài mà ứng dụng của bạn đang sử dụng.

Bất kỳ nguồn thông tin nào khác bao gồm cả Câu hỏi thường gặp này có thể đã lỗi thời hoặc nếu không thì không chính xác và không nên được coi là có căn cứ đáng tin. Tuy nhiên, bạn có thể vẫn tìm thấy thông tin hữu ích trên nhiều trang Cộng đồng Hỏi và đáp Stack Exchange, như cũng như các trang web như AdamW trên Linux và nhiều nền tảng khác và blog xác nhận, cùng nhiều nội dung 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 Dự án bảo mật ứng dụng web mở (OWASP) Ghim khoá công khai và chứng chỉ bài viết và Bản tóm tắt về tính năng ghim giàu thông tin. Để biết hướng dẫn cụ thể cho Android, vui lòng tham khảo Các phương pháp hay nhất về Android về bảo mật và Quyền riêng tư Bảo mật bằng HTTPS và SSL tài liệu đào tạo của bạn. Để thảo luận về chứng ch�� và việc ghim khoá công khai Trên Android, bạn có thể tìm thấy bài đăng trên blog của Matthew Dolan Bảo mật trên Android: Ghim bằng SSL hữu ích.

Các phương pháp hay nhất về Android về bảo mật và Nội dung đào tạo về Cấu hình bảo mật mạng về quyền riêng tư tài liệu 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ý chứng chỉ đáng tin cậy bổ sung trên Android.

Để xem danh sách đầy đủ các CA gốc mà AOSP tin cậy, hãy tham khảo chứng chỉ ca Kho lưu trữ Git. Đố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, ví dụ: LineageOS, 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.