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, hãy xem phần Vấn đề này là gì?.

Thuật ngữ

Dưới đây là danh sách những thuật ngữ quan trọng nhất mà bạn cần nắm rõ trong tài liệu này. Để biết thông tin tổng quan toàn diện hơn về thuật ngữ liên quan, hãy xem Câu hỏi thường gặp về Google Trust Services.

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

Thông tin chung

Đây là về vấn đề gì?

Tóm tắt: Nếu không làm theo hướng dẫn tại https://pki.goog/faq/#connecting-to-google, bạn có nhiều khả năng gặp phải tình trạng ngừng hoạt động liên quan đến chứng chỉ trong tương lai.

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. Đây là chữ ký mã hoá làm cơ sở cho tính bảo mật của Internet TLS mà HTTPS sử dụng.

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

Hầu như 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, và do đó, có thể thiết lập một kết nối an toàn với 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 KHÔNG ĐƯỢC 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ỉ riêng. Vì GS Root R2 đã hết hạn vào ngày 15 tháng 12 năm 2021, nên Google đã di chuyển các dịch vụ của mình sang một CA mới là GTS Root R1 Cross, sử dụng chứng chỉ do CA gốc của Google là GTS Root R1 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 các CA gốc GTS, nhưng để đảm bảo quá trình chuyển đổi diễn ra 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 GlobalSign Root CA – 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 các ứng dụng Google Maps Platform của khách hàng đều đã nhận ra một (hoặc cả hai) CA gốc đáng tin cậy này và 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.

Đ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ử họ đã làm theo hướng dẫn của chúng tôi vào thời điểm đó, cài đặt tất cả các chứng chỉ từ gói CA gốc đáng tin cậy của Google và nên kiểm tra các bản cập nhật cho tệp đó cũng như cập nhật kho lưu trữ đáng tin cậy ít nhất 6 tháng một lần.

Nếu gặp vấn đề khi kết nối với các dịch vụ của Nền tảng Google Maps, bạn nên xác minh hệ thống của mình nếu thuộc các trường hợp sau:

  • dịch vụ của bạn chạy các nền tảng không chuẩn hoặc nền tảng cũ hoặc bạn duy trì kho chứng chỉ gốc của riêng mình
  • bạn không thực hiện hành động nào trong năm 2017 – 2018, trong giai đoạn đầu tiên của quá trình di chuyển CA gốc của Google, 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

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

Hãy xem phần bên dưới để biết thêm thông tin kỹ thuật. Để biết hướng dẫn chung, 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 đồng bộ hoá các kho chứng chỉ gốc với gói CA gốc được tuyển chọn ở trên để chứng minh các dịch vụ của bạn trước những thay đổi trong tương lai đối với CA gốc. Tuy nhiên, chúng tôi sẽ thông báo trước về những thay đổi này. Hãy 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 lần di chuyển trong tương lai? để biết thêm hướng dẫn về cách nắm bắt thông tin.

Tóm tắt về kỹ thuật

Như đã thông báo vào ngày 15 tháng 3 năm 2021 trên Google Security Blog, GS Root R2, CA gốc mà Nền tảng Google Maps sử dụng từ đầu năm 2018 đã 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 phát hành.

Hầu hết các hệ thống và ứng dụng TLS hiện đại đều đã được định cấu hình sẵn 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à GlobalSign Root CA – R1 thậm chí sẽ 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 đều á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 nền tảng cũ hoặc bạn duy trì kho chứng chỉ gốc của riêng mình
  • bạn không thực hiện hành động nào trong năm 2017 – 2018, trong giai đoạn đầu tiên của quá trình di chuyển CA gốc của Google, 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

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 hướng dẫn về cách kiểm thử để biết 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 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? để biết thông tin chi tiết đầy đủ.

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 cho vấn đề công khai 186840968 để nhận thông tin cập nhật. Chúng tôi cũng sẽ 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 chúng tôi gặp phải những chủ đề có thể được quan tâm rộng rãi.

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

Các chứng chỉ gốc mới sẽ được công bố tại https://pki.goog/updates/ và có một nguồn cấp dữ liệu RSS mà bạn có thể đăng ký để nhận thông báo về các bản cập nhật. Chúng tôi chỉ công bố các chứng chỉ gốc mới. Chúng tôi không thông báo về những thay đổi đối với chuỗi chứng chỉ chuyển đổi giữa các gốc lâu năm và những thay đổi này có thể xảy ra bất cứ lúc nào. Bạn không được ghim vào một gốc hoặc trung gian duy nhất và bạn phải tin tưởng vào toàn bộ các gốc của Google được đề cập trong https://pki.goog/faq/#connecting-to-google nếu muốn đảm bảo kết nối đáng tin cậy với Google.

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 công bố công khai trên blog.

Ngoài ra, hãy đăng ký nhận Thông báo của Google Maps Platform 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ó thể ả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 chứng chỉ này không?

Có. Việc 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 từng dịch vụ. Tuy nhiên, sau khi bạn xác minh rằng các kho chứng chỉ gốc mà ứng dụng khách Google Maps Platform của bạn sử dụng có 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, các dịch vụ của bạn sẽ không bị ảnh hưởng bởi quá trình di chuyển đang diễn ra và việc đồng bộ hoá các kho này (ít nhất 6 tháng một lần) cũng sẽ bảo vệ bạn khỏi những thay đổi trong tương lai đối với CA gốc.

Hãy xem các câu hỏi 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? và Những loại ứng dụng nào có nguy cơ bị hỏng? để biết thêm thông tin chi tiết.

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 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 tất cả các gốc trong phần "Root CAs" (CA gốc) của https://pki.goog/repository/

Hệ thống của bạn thường sẽ tương thích với các thay đổi về CA gốc nếu:

  • dịch vụ của bạn chạy trên một hệ điều hành chính thống được duy trì, đồng thời bạn đã vá cả hệ điều hành và các thư viện mà dịch vụ của bạn sử dụng, đồng thời 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 từ gói CA gốc đáng tin cậy của Google, đồng thời tiếp tục cập nhật kho lưu trữ đáng tin cậy của bạn thường xuyên.

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

Xem câu hỏi 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? để biết thông tin chi tiết đầy đủ.

Có công cụ nào mà tôi có thể dùng để xác minh bộ nhớ chứng chỉ gốc của chúng tôi không?

Bạn có thể thấy 2 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 lựa chọn để kiểm thử chế độ thiết lập của bạn.

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

Các lệnh openssl được trình bày 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 đ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 nhận openssl, hãy xem phần Nhận 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ể lấy các công cụ mình cần ở đâu? bên dưới.

Để biết hướng dẫn cụ thể về cách kiểm thử, hãy xem bài viết 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

Ví dụ này dành cho GTS R1, bạn nên kiểm thử dựa trên tất cả các gốc GTS.

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; \

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

  1. Giai đoạn đầu (di chuyển sang GS Root R2), được công bố 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.
  2. Giai đoạn thứ hai (di chuyển sang GTS Root R1 Cross) được công bố vào tháng 3 năm 2021 và triển khai trong những tháng 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 gốc mới sẽ được thông báo trước khi chứng chỉ hết hạn trong tương lai, nhưng các quá trình chuyển đổi giữa các gốc hiện có sẽ không được thông báo.

Đảm bảo ứng dụng của bạn luôn sẵn sàng cho tương lai bằng cách đồng bộ hoá kho chứng chỉ gốc 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.

Bạn cũng có thể xem câu hỏi 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? để biết thêm thông tin.

Kế hoạch triển khai chung cho từng dịch vụ của Google

  1. Quá trình phát hành theo giai đoạn bắt đầu ở một trung tâm dữ liệu duy nhất.
  2. Quá trình triển khai sẽ dần được 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.
  3. Nếu phát hiện thấy vấn đề nghiêm trọng ở bất kỳ giai đoạn nào, các thử nghiệm có thể tạm thời được khôi phục trong khi vấn đề được giải quyết.
  4. Dựa trên thông tin đầ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 quá trình triển khai cho đến khi tất cả các dịch vụ của Google đều được di chuyển sang các chứng chỉ mới.

Đối tượng bị ảnh hưởng, thời điểm và địa điểm?

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. Các thay đổi sẽ có phần mang tính cục bộ, vì các yêu cầu của máy khách thường được chuyển tiếp đến các máy chủ trong các trung tâm dữ liệu gần về mặt địa lý.

Vì không thể biết chắc chắn trướ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 nên xác minh và chuẩn bị sẵn sàng cho các dịch vụ của mình trước các giai đoạn di chuyển CA gốc có thể có của Google.

Hãy xem bài viết 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ú ý

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 của chúng với Nền tảng Google Maps. Trong trường hợp này, các ứng dụng thường sẽ đưa ra cảnh báo rằng quá trình xác thực chứng chỉ đã thất bại.

Tuỳ thuộc vào cấu hình TLS, các ứ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 với yêu cầu đó.

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

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

Mặc dù các phiên bản TLS cũ 1.0 và 1.1 vẫn được hỗ trợ, nhưng bạn không nên sử dụng các phiên bản này và nên sử dụng TLS 1.3 nếu có thể.

Để biết các yêu cầu và đề xuất khác, hãy tham khảo các phần Yêu cầu được đề xuất đối với một ứng dụng TLS để giao tiếp với Google là gì? và Tại sao nhiều Dịch vụ của Google vẫn cho phép kết nối bằng TLS 1.0 và TLS 1.1? trong Câu hỏi thường gặp về GTS.

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

Ứng dụng sử dụng kho 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 áp đặt

Các ứng dụng dịch vụ web của 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ẫn được duy trì và nhận các bản cập nhật thường xuyên, thì kho chứng chỉ gốc mặc định của bạn có lẽ đã bao gồm các chứng chỉ gốc GTS.

Nếu đang 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 có hoặc không có chứng chỉ gốc GTS. Tuy nhiên, kho chứng chỉ gốc của bạn có thể sẽ chứa GlobalSign Root CA – R1, một trong những CA gốc lâu đời nhất và được tin cậy rộng rãi nhất, được dùng để ký chéo các gốc GTS khi cần.

Đố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, hãy áp dụng các nguyên tắc trong câu hỏi Ứng dụng di động có nguy cơ bị lỗi không?

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

Các ứng dụng Maps JavaScript API thường dựa vào chứng chỉ gốc của trình duyệt web đang 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 di động sử dụng bất kỳ SDK nào của Maps cho Android, SDK của Maps cho iOS, SDK Địa điểm cho Android hoặc SDK Địa điểm cho iOS, các quy tắc tương tự cũng áp dụng cho các ứng dụng gọi 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ơ bị lỗi không? để biết thêm thông tin chi tiết.

Ứng dụng sử dụng gói chứng chỉ riêng hoặc sử 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 sẽ cần tự cập nhật gói chứng chỉ. Như đã thảo luận trong câu hỏi 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?, chúng tôi khuyên bạn nên nhập tất cả chứng chỉ từ gói CA gốc đáng tin cậy của Google vào kho chứng chỉ gốc của riêng bạn và thường xuyên cập nhật kho chứng chỉ.

Google không khuyến khích việc ghim chứng chỉ hoặc khoá công khai cho các miền của Google mà ứng dụng của bạn kết nối. Nếu ghim, bạn sẽ có nguy cơ cao bị hỏng.

Để biết thêm thông tin về việc ghim chứng chỉ hoặc 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 được tuyển chọn gồm các CA gốc trong gói CA gốc đáng tin cậy của Google bao gồm tất cả các CA có thể được các dịch vụ của Google sử dụng trong tương lai gần.

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

Đ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 duy trì, vì những lý do khác mà bạn không thể vá hệ điều hành và thư viện của mình, 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 hoạt động 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 hoạt động di chuyển CA gốc trong tương lai. Việc thường xuyên đồng bộ hoá kho 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 tình trạng gián đoạn dịch vụ trong tương lai do các thay đổi về CA và sẽ 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, hãy 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 những chứng chỉ CA nào?trong phần Câu hỏi thường gặp về GTS để biết thêm các đề xuất.

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

Nếu làm như vậy, ứng dụng của bạn có nguy cơ bị hỏng bất cứ lúc nào chúng tôi đăng ký một chứng chỉ mới hoặc chuyển đổi CA trung gian. Một trong hai trường hợp 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 và áp dụng cho cả các chứng chỉ máy chủ riêng lẻ (chẳng hạn như những chứng chỉ do maps.googleapis.com cung cấp) cũng như bất kỳ CA trung gian nào 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 bạn khỏi điều 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ỉ được neo vào đó.

Mọi hoạt động 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 được tin cậy.

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

Hầu hết các trình duyệt hiện đại đều đã tích hợp và tin tưởng các chứng chỉ gốc GTS, đồng thời chữ ký chéo của 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ũ. Trong đó có tất cả các trình duyệt được hỗ trợ chính thức cho Maps JavaScript API.

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 tưởng. Mặc dù vị trí chính xác khác nhau tuỳ theo từng trình duyệt, nhưng danh sách chứng chỉ thường nằm ở đâu đó trong phần Cài đặt.

Ứng dụng di động có nguy cơ bị hỏng không?

Các thiết bị Android và Apple iOS vẫn nhận được các bản cập nhật thường xuyên từ nhà sản xuất thiết bị cũng được kỳ vọng sẽ có khả năng sử dụng lâu dài. 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, 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ị hạn chế trong các phiên bản Android trước phiên bản 10.

Đối với thiết bị iOS, Apple duy trì 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 mình. Tuy nhiên, tất cả cá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ừ iOS phiên bản 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? để biết thêm thông tin 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?

Trong những năm qua, Google đã làm việ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 được tin cậy và 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), cũng như các nhóm Android và ChromeOS của Google; nhà phát triển trình duyệt (chẳng hạn như Mozilla, Apple, Microsoft, cũng như 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ã tín hiệu truyền hình, TV, máy chơi trò chơi, máy in, v.v.).

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

Tuy nhiên, vì thời gian đưa chứng chỉ của bên thứ ba vào 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 mà 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 của riêng họ.

Khắc phục sự cố

Tôi có thể lấy các công cụ mình cần ở đâu?

Nhận curl

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 curl 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 một tệp nhị phân được biên dịch sẵn xuống (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ể tìm thấy danh sách các tệp nhị phân do bên thứ ba tạo bằng cách truy cập vào 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, nhưng công cụ dòng lệnh tshark và tcpdump của công cụ này, các phiên bản được biên dịch sẵn của hai công cụ đầu tiên cho các hệ điều hành khác có thể được tìm thấy tại https://www.wireshark.org.

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

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

Lấy keytool Java

Công cụ dòng lệnh keytool phải được phân phối cùng với mọi phiên bản Java Development Kit (JDK) hoặc Java Runtime Environment (JRE). Cài đặt những ứng dụng này để nhận keytool. Tuy nhiên, bạn không cần thiết phải sử dụng keytool để xác minh chứng chỉ gốc, trừ phi ứng dụng của bạn được tạo bằng Java.

Việc cần làm khi xảy ra sự cố ngừng hoạt động trong quá trình phát hành công khai

Hành động chính mà bạn cần thực hiện là cài đặt các 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 chứng chỉ gốc mà ứng dụng của bạn sử dụng.

  1. Hãy hợp tác với quản trị viên hệ thống để nâng cấp kho chứng chỉ gốc cục bộ.
  2. Hãy xem phần Câu hỏi thường gặp này để biết các mẹo áp dụng cho hệ thống của bạn.
  3. 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.
  4. Để được trợ giúp 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ợ của Google Maps Platform. Lưu ý: Đối với các vấn đề cụ thể về nền tảng, chúng tôi chỉ cung cấp hướng dẫn trong khả năng có thể.

  5. Gắn dấu sao cho vấn đề công khai 186840968 để biết 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ợ của 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 hướng dẫn khắc phục sự cố chung.

Phần Quản lý các chứng chỉ đáng tin cậy 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 Nền tảng Google Maps, hãy chuẩn bị sẵn sàng cung cấp thêm những thông tin sau:

  1. Các máy chủ chịu ảnh hưởng của bạn nằm ở đâu?
  2. Dịch vụ của bạn đang gọi đến địa chỉ IP nào của Google?
  3. (Các) API nào bị ảnh hưởng bởi vấn đề này?
  4. Vấn đề bắt đầu xảy ra chính xác là khi nào?

  5. 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;
curl -vvI https://good.gtsr2.demosite.pki.goog/; \
openssl s_client -connect good.gtsr2.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr3.demosite.pki.goog/; \
openssl s_client -connect good.gtsr3.demosite.pki.goog:443 -showcerts </dev/null; \
curl -vvI https://good.gtsr4.demosite.pki.goog/; \
openssl s_client -connect good.gtsr4.demosite.pki.goog:443 -showcerts </dev/null; \

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

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

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à dịch 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, hãy 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 sử dụng tcpdump hoặc Wireshark để ghi lại gói đàm phán TLS không thành công đối với https://maps.googleapis.com/ ở định dạng PCAP, sử dụng độ dài ảnh chụp nhanh đủ lớn để ghi lại toàn bộ gói mà không cắt bớt (ví dụ: sử dụng -s0 trên các phiên bản trước của tcpdump).
  • Nếu có thể, hãy cung cấp đoạn trích nhật ký từ dịch vụ của bạn cho biết chính xác lý do thất bại khi kết nối TLS, tốt nhất là có đầy đủ thông tin về chuỗi chứng chỉ máy chủ.

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

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

Khi đăng bình luận về vấn đề công khai 186840968, hãy cung cấp thông tin có 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 đầu ra của curl

Việc chạy curl bằng 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ả đầu ra:

  • Các dòng bắt đầu bằng "*" hiển thị đầu ra từ quá trình thương lượng 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 ">" cho biết yêu cầu HTTP đi mà curl gửi.
  • Các dòng bắt đầu bằng "<" cho biết phản hồi HTTP mà ứng dụng nhận được từ máy chủ.
  • Nếu giao thức là HTTPS, thì sự xuất hiện của các dòng ">" hoặc "<" ngụ ý một quy trình bắt tay TLS thành công.

Thư viện TLS và gói chứng chỉ gốc đã dùng

Việc chạy curl bằng cờ -vvI cũng sẽ in ra kho chứng chỉ gốc đã dùng, nhưng đầu ra chính xác có thể khác nhau tuỳ theo hệ thống như minh hoạ ở đây.

Đầu ra từ một máy Red Hat Linux có curl được liên kết với NSS có thể chứa những 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 dùng hệ điều hành Ubuntu hoặc Debian Linux có thể chứa những dòng sau:

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

Đầu ra từ máy Linux Ubuntu hoặc Debian bằ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 gửi đ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ụ trên một máy dùng hệ điều hành 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: */*
>

Không bắt tay được với TLS

Các dòng, chẳng hạn như các dòng trong mẫu mã này, cho biết kết nối đã bị chấm dứt trong 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à dấu hiệu rõ ràng cho thấy bạn không kết nối được:

*** 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

Cái bắt tay TLS thành công được biểu thị bằng sự xuất hiện của các dòng tương tự như các dòng trong mẫu mã này. Bạn nên liệt kê bộ mật mã được dùng cho kết nối được mã hoá, cũng như thông tin chi tiết về chứng chỉ máy chủ được chấp nhận. Ngoài ra, 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 của 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 các chứng chỉ máy chủ đã nhận ở dạng người dùng có thể đọc được

Giả sử đầu ra có định dạng PEM, ví dụ: đầu ra từ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null, bạn có thể in chứng chỉ được phân phát 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 đó, hãy dán nội dung trong vùng đệm sao chép vào thiết bị đầu cuối.

  • Nhấn phím Return.

Để xem 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ủa Google được ký chéo trông như thế nào trong OpenSSL?

{# disableFinding(LINE_OVER_80)}

…
---
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ỉ tin cậy

Làm cách nào để kiểm tra chứng chỉ gốc 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 xác minh danh sách chứng chỉ đáng tin cậy trong phần Cài đặt. Bảng này cho biết đường dẫn chính xác đến trình đơn 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 đăng nhập > Thông tin đăng nhập đáng tin cậy
10+ Cài đặt > Bảo mật > Nâng cao > Mã hoá và thông tin đăng nhập > Thông tin đăng nhập đáng tin cậy

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

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ường, bạn không thể cập nhật kho 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 các phiên bản Android vẫn đang đượ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 bị gián đoạn trong nhiều năm tới, vượt quá thời gian hoạt động 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 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 tưởng. Việc này được thực hiện bằng cách 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ác phương pháp hay nhất về bảo mật và quyền riêng tư trên Android Cấu hình bảo mật mạng.

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, nên những nỗ lực như vậy có thể chỉ cung cấp một giải pháp tạm thời một phần.

Trên các thiết bị cũ, lựa chọn duy nhất bạn có thể sử dụng là dựa vào các CA do người dùng thêm, được cài đặt bằng 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.

iOS Trust Store

Apple không trực tiếp cho người dùng thiết bị di động xem bộ chứng chỉ gốc đáng tin cậy mặc định của mình. Thay vào đó, công ty này cung cấp các đường liên kết đến bộ CA gốc đáng tin cậy cho iOS phiên bản 5 trở lên trong các bài viết của Apple Support:

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

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 theo phiên bản iOS, dựa trên các nguồn nêu trên:

Phiên bản iOS 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)
5, 6, 7, 8, 9, 10, 11, 12.0
12.1.3+

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

Vị trí của kho lưu trữ chứng chỉ gốc mặc định sẽ thay đổi theo hệ điều hành và thư viện SSL/TLS được 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 các 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ũ
  • /etc/pki/ca-trust/source/anchors và /usr/share/pki/ca-trust-source: Fedora, 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 chứng chỉ gốc 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 chứng chỉ gốc mặc định bằng lệnh sau:

openssl version -d

Lệnh này in ra 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ác cấu hình của thư viện:

OPENSSLDIR: "/usr/lib/ssl"

Kho 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 chứng chỉ gốc mặc định của hệ thống như trong ví dụ trên, hãy kiểm tra phần cấp cao nhất Kho chứng chỉ gốc của hệ thống ở đâu và làm cách nào để cập nhật kho 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 về cách lấy openssl, hãy xem phần Lấy OpenSSL.

Kho chứng chỉ gốc Java

Các ứng dụng Java có thể sử dụng kho chứng chỉ gốc riêng. Trên các hệ thống Linux, kho này thường nằm ở /etc/pki/java/cacerts hoặc /usr/share/ca-certificates-java và có thể được quản lý bằng công cụ dòng lệnh keytool của Java.

Để nhập một chứng chỉ riêng lẻ vào kho chứng chỉ Java, hãy phát hành 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, hãy tham khảo các bài viết sau đây của Oracle và Stack Overflow:

Kho 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 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 hành 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 dùng trong môi trường của bạn.

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

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

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

Đị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 tiêu chuẩn trên thực tế để lưu trữ và gửi các chứng chỉ, khoá mật mã, v.v., được chính thức hoá thành một tiêu chuẩn theo luật định trong RFC 7468.

Mặc dù bản thân đị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, quy cách PEM cho phép phát ra văn bản giải thích trước hoặc sau phần nội dung chứng chỉ được mã hoá bằng văn bản và nhiều công cụ sử dụng tính năng này để cung cấp bản tóm tắt văn bản thuần tuý về các phần tử dữ liệu phù hợp nhất trong chứng chỉ.

Bạn cũng có thể 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 ".crt" để cho biết tệp sử dụng một phương thức mã hoá văn bản.

Tệp DER là gì?

Quy tắc mã hoá riêng biệt (DER) là một định dạng nhị phân được tiêu chuẩn hoá để mã hoá chứng chỉ. 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 được 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á DER. Theo quy ước, cá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, ví dụ: Java keytool, chỉ có thể nhập một chứng chỉ duy nhất từ tệp PEM, ngay cả khi tệp đó chứa nhiều chứng chỉ. 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 nhỏ tệp này trước.

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 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 ra một số tệp PEM riêng lẻ tương tự như các 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 từng tệp PEM, chẳng hạn như 02265526.pem hoặc chuyển đổi thêm thành đị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 mà hệ thống của tôi hỗ trợ

Bạn có thể 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.

Để xem danh sách đầy đủ các lựa chọn có sẵn, 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 về cách lấy openssl, hãy xem phần Lấy OpenSSL.

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

Khi dùng openssl, bạn có thể đưa ra lệnh sau để chuyển đổi một 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ể đưa ra lệnh sau để chuyển đổi một 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 một 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.

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 dùng keytool, bạn có thể phát hành lệnh sau để liệt kê tất cả chứng chỉ trong kho chứng chỉ, cùng với bí danh mà bạn có thể 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 dùng trong môi trường của mình. Lệnh này cũng sẽ cho thấy biệt hiệu của từng chứng chỉ. Bạn sẽ cần biệt hiệu này nếu muốn xuất chứng chỉ.

Để xuất từng chứng chỉ ở định dạng PEM, hãy phát 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 môi trường của bạn, đồng thời 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, hãy tham khảo hướng dẫn Java Platform, Standard Edition Tools Reference: keytool {: .external}.

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

Khi dùng certutil, bạn có thể đưa ra lệnh sau để liệt kê tất cả chứng chỉ trong kho chứng chỉ, cùng với biệt hiệu mà bạn có thể 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 dùng trong môi trường của bạn. Lệnh này cũng sẽ cho biết biệt hiệu của từng chứng chỉ. Bạn sẽ cần biệt hiệu này nếu muốn xuất chứng chỉ.

Để xuất từng chứng chỉ ở định dạng PEM, hãy phát 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 môi trường của bạn, đồng thời 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, hãy tham khảo hướng dẫn chính thức về NSS Tools certutil 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 rằng 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 lấy openssl, hãy xem phần Lấy OpenSSL.

In chứng chỉ bằng keytool của 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 lấy keytool, hãy xem phần Lấy Java keytool.

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

Điều này tuỳ thuộc vào từng 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ỉ đến và đi từ kho chứng chỉ gốc thường cũng cung cấp một lựa chọn để liệt kê các chứng chỉ đã cài đặt.

Ngoài ra, nếu đã xuất thành công các chứng chỉ gốc đáng tin cậy vào tệp PEM hoặc kho lưu trữ 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 này 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 mà con người có thể đọc được về cơ quan cấp chứng chỉ được liên kết (ví dụ: 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 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 tệp, chẳng hạn như GTS_Root_R1.pem có thể mô tả CA mà chứng chỉ thuộc về. Chuỗi chứng chỉ giữa các mã thông báo -----BEGIN CERTIFICATE----- và -----END CERTIFICATE----- cũng là duy nhất đối với mỗi CA.

Tuy nhiên, ngay cả khi không có 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 đều được gắn nhãn đúng cách, nên bạn có thể so khớp một cách đá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 mình bằng Issuer hoặc bằng cách so sánh các chuỗi chứng chỉ tệp PEM.

Các trình duyệt web có thể sử dụng kho chứng chỉ gốc riêng hoặc dựa vào kho chứng chỉ gốc mặc định do hệ điều hành cung cấp. Tuy nhiên, tất cả các trình duyệt hiện đại đều cho phép bạn quản lý hoặc ít nhất là xem bộ CA gốc mà chúng tin tưởng. 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 thông tin chi tiết.

Để biết hướng dẫn cụ thể cho điện thoại di động, hãy xem câu hỏi riêng biệt 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?.

Phụ lục

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

Luôn dựa chủ yếu 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 kể 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 nên được coi là nguồn thông tin chính thức. 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.

Bạn cũng có thể xem Câu hỏi thường gặp về Google Trust Services.

Để xem phần giới thiệu ngắn gọn về mật mã học, PKI, chứng chỉ và chuỗi chứng chỉ, bạn có thể xem danh sách phát PKI Bootcamp trên YouTube của Paul Turner.

Để 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ể tham khảo bài viết Ghim chứng chỉ và khoá công khai của Dự án bảo mật ứng dụng web mở (OWASP) và Bảng tham khảo về ghim. Để biết hướng dẫn cụ thể về Android, hãy tham khảo tài liệu đào tạo 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ư trên Android Bảo mật bằng HTTPS và SSL. Để thảo luận về việc ghim chứng chỉ so với khoá công khai trên Android, bạn có thể xem bài đăng trên blog của Matthew Dolan Android Security: SSL Pinning (Bảo mật Android: Ghim SSL).

Tài liệu đào tạo Các phương pháp hay nhất về bảo mật và quyền riêng tư trên Android Cấu hình bảo mật mạng 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.

Để xem 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 các 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.