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 CA gốc của Google đang diễn ra, hãy xem phần Điều gì đang xảy ra?.

Thuật ngữ

Dưới đây, 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 làm quen trong tài liệu này. Để biết thông tin tổng quan toàn diện hơn về các thuật ngữ có liên quan, vui lòng chuyển đến Câu hỏi thường gặp về Dịch vụ tin cậy của Google.

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

Thông tin chung

Đang có chuyện gì xảy ra?

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 chứng chỉ gốc riêng. Chữ ký mã hoá là cơ sở của quy trình bảo mật Internet TLS mà HTTPS sử dụng.

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

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

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

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 (Bảo mật tầng truyền tải) đã 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 lại một dấu hiệu chéo từ GMO GlobalSign bằng GlobalSign Root CA – R1. Đây là 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 ứng dụng trên Nền tảng Google Maps của khách hàng sẽ nhận ra (hoặc cả hai) các CA gốc đáng tin cậy này và sẽ hoàn toàn không bị ảnh hưởng trong 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, cho rằng tại thời điểm đó, họ đã làm theo hướng dẫn của chúng tôi, cài đặt tất cả chứng chỉ từ gói CA gốc đáng tin cậy của Google.

Bạn nên xác minh hệ thống của mình nếu những điều sau đây đúng:

  • các 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 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 của quá trình di chuyển CA gốc của Google, hoặc bạn chưa cài đặt bộ đầy đủ chứng chỉ từ gói CA gốc đáng tin cậy của Google

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

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

Bạn cũng nên tiếp tục đồng bộ hoá kho chứng chỉ gốc của mình với gói CA gốc đã chọn ở trên để đảm bảo dịch vụ của bạn không bị ảnh hưởng bởi những thay đổi về CA gốc trong tương lai. Tuy nhiên, những thay đổi 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?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? để biết thêm hướng dẫn về cách theo dõi 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 đó, trong năm nay, 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ỉ lá TLS do CA mới này phát hành.

Hầu hết các ứng dụng và hệ thống TLS hiện đại đều đã được định cấu hình sẵn với 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 áp dụng cả hai điểm sau:

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

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

Xem câu hỏi Tại sao tôi nên lưu trữ chứng chỉ gốc của mình với gói CA gốc đáng tin cậy của Google? để biết đầy đủ 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 để biết nội dung 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 những chủ đề có thể được nhiều người quan tâm.

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

Bạn nên theo dõi Blog 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 cụ thể cho từng sản phẩm sớm nhất có thể, sau thông báo công khai trên blog.

Vui lòng đăng ký nhận Thông báo của Nền tảng Google Maps vì chúng tôi thường xuyên đăng thông tin cập nhật trên diễn đàn về những thay đổi có 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 mạng đó không?

Có, quá trình di chuyển CA gốc sẽ diễn ra trên tất cả các dịch vụ và API của Google, nhưng tiến trình có thể khác nhau theo từng dịch vụ. Tuy nhiên, sau khi bạn xác minh rằng kho lưu trữ chứng chỉ gốc mà ứng dụng khách 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, thì các dịch vụ của bạn sẽ không bị ảnh hưởng trong quá trình di chuyển đang diễn ra và việc đồng bộ hoá những chứng chỉ này 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 nên lưu trữ chứng chỉ gốc của mình với gói CA gốc đáng tin cậy của Google?Loại ứng dụng nào có nguy cơ bị lỗi? để biết thêm thông tin chi tiết.

Phần Cách xác minh xem cửa hàng 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ách xác minh xem kho lưu trữ chứng chỉ gốc của tôi có cần cập nhật hay không

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

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

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

  • dịch vụ của bạn chạy trên một hệ điều hành chính được bảo trì, đồng thời bạn đã giữ lại 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á đồ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 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

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 bị gián đoạn dịch vụ trong tương lai.

Xem câu hỏi Tại sao tôi nên lưu trữ chứng chỉ gốc của mình với gói CA gốc đáng tin cậy của Google? để biết đầy đủ thông tin chi tiết.

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

Bạn có thể thấy hai công cụ dòng lệnh curlopenssl hữu ích trong quá trình đ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 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 thực hiện curl, hãy xem phần Cách curl ở bên dưới.

Các lệnh openssl dưới đây 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 sử dụng một phiên bản cũ, hãy nâng cấp hoặc sửa đổi các lệnh này (nếu cần) cho phiên bản của bạn. Để biết hướng dẫn về cách tải openssl, hãy xem phần Tải OpenSSL dưới đây.

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

Để biết hướng dẫn kiểm thử cụ thể, 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 của bạn

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 gói CA gốc đáng tin cậy của Google xuống, sau đó làm theo các bước sau:

curl -vvI --cacert roots.pem https://maps.googleapis.com; \
openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null; \
curl -vvI --cacert roots.pem https://good.gtsr1.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 CA gốc của Google 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), thông báo vào tháng 1 năm 2017, bắt đầu vào cuối năm 2017 và kết thúc vào nửa đầu năm 2018.
  2. Giai đoạn hai (di chuyển sang GTS Root R1 Cross) đã được công bố vào tháng 3 năm 2021 và sẽ ra mắt trong những tháng tới, trước khi GS Root R2 hết hạn vào ngày 15 tháng 12 năm 2021.

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

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

Ngoài ra, hãy xem câu hỏi Tại sao tôi nên lưu trữ chứng chỉ gốc của mình với gói CA gốc đáng tin cậy của Google? để biết 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

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

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

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

Vì chúng tôi không thể chắc chắn trước được ai sẽ bị ảnh hưởng, thời điểm và địa điểm sẽ bị ảnh hưởng, nên chúng tôi khuyến nghị tất cả khách hàng của mình nên xác minh và cung cấp bằng chứng cho tương lai về dịch vụ của họ trước khi tiến hành các giai đoạn di chuyển CA gốc của Google.

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

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 thể xác minh kết nối TLS của họ với Nền tảng Google Maps. Trong trường hợp này, ứng dụng thường sẽ đưa ra cảnh báo 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 trên Nền tảng Google Maps hoặc từ chối tiếp tục yêu cầu.

Các yêu cầu tối thiểu để một ứ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ủ đề (SAN) của DNS, vì vậy, quá trình xử lý chứng chỉ của ứng dụng phải hỗ trợ SAN. Các chứng chỉ này có thể bao gồm một ký tự đại diện duy nhất dưới dạng nhãn ở ngoài cùng bên trái trong tên, chẳng hạn như *.googleapis.com.

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

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

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

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

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

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

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

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

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

Đối với ứng dụng gốc dành cho thiết bị di động sử dụng SDK Maps cho Android, SDK 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ự sẽ áp dụng cho ứng dụng gọi dịch vụ web của Nền tảng Google Maps.

Hãy xem câu hỏi Các ứng dụng di động 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 phải đảm bảo tự cập nhật gói chứng chỉ của mình. Như đã thảo luận trong câu hỏi Tại sao tôi nên lưu trữ chứng chỉ gốc của mình để đồng bộ hóa với gói CA gốc đáng tin cậy của Google?, bạn nên nhập tất cả chứng chỉ từ gói CA gốc đáng tin cậy của Google vào kho lưu trữ chứng chỉ gốc của riêng mình.

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

Để biết thêm thông tin về 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 lưu trữ chứng chỉ gốc của mình với gói CA gốc đáng tin cậy của Google?

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

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

Điều này đặc biệt quan trọng nếu 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ì các lý do khác, bạn không thể cập nhật hệ điều hành và thư viện, 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 CA gốc trong tương lai. Việc thường xuyên lưu trữ các chứng chỉ gốc được đồng bộ hoá với danh sách đã chọn sẽ giúp 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 các thay đổi về CA, và sẽ giúp các dịch vụ của bạn tiếp tục chạy sau khi hết hạn của cả GTS Root R1 CrossGlobalSign Root CA – R1.

Ngoài ra, vui lòng tham khảo câu hỏi Tôi đang xây dựng một sản phẩm kết nối với các dịch vụ của Google. Tôi cần tin tưởng những chứng chỉ CA nào? trong 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 chi tiết hay chứng chỉ CA trung gian nào?

Việc này sẽ có nguy cơ khiến đơn đăng ký của bạn bị hỏng bất cứ lúc nào chúng tôi đăng ký chứng chỉ mới hoặc chuyển đổi các CA trung gian. Cả hai điều này có thể xảy ra bất cứ lúc nào mà không cần thông báo trước, đồng thời áp dụng như nhau cho từng chứng chỉ máy chủ, chẳng hạn như chứng chỉ do maps.googleapis.com phân phát, 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, đồng thời chỉ dựa vào chứng chỉ gốc để xác minh mức độ đáng tin cậy của toàn bộ chuỗi chứng chỉ liên kết với chứng chỉ đó.

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

Các ứng dụng JavaScript có nguy cơ bị hỏng không?

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

Mọi trình duyệt hiện đại 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 là khác nhau tuỳ theo từng trình duyệt, nhưng thường thì bạn có thể tìm thấy danh sách chứng chỉ ở đâu đó trong phần Cài đặt.

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

Các thiết bị iOS và Android 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 dự kiến sẽ là bằng chứng trong tương lai. Hầu hết các mẫu điện thoại Android cũ đều có ít nhất chứng chỉ GlobalSign Root CA – R1, mặc dù danh sách các chứng chỉ đáng tin cậy có thể khác nhau tuỳ theo nhà sản xuất điện thoại di động, mẫu thiết bị và phiên bản Android.

Tuy nhiên, tính năng hỗ trợ các CA gốc của 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 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 trên các trang hỗ trợ của mình. Tuy nhiên, tất cả iOS phiên bản 5 trở lên đều hỗ trợ GlobalSign Root CA – R1.

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

Hãy xem câu hỏi Làm cách nào để kiểm tra chứng chỉ gốc đáng tin cậy trên điện thoại di động của tôi? để biết thêm 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ẽ bao gồm chứng chỉ gốc của Google Trust Services?

Trong những năm qua, Google đã hợp tác rộng rãi với tất cả các bên thứ ba lớn để duy trì các gói chứng chỉ gốc được sử dụng rộng rãi và đáng tin cậy. 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à Chrome OS của Google; nhà phát triển trình duyệt (chẳng hạn như Mozilla, Apple, Microsoft) và nhóm Chrome của Google; nhà sản xuất phần cứng (ví dụ: đ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ó khả năng mọi hệ thống đang được duy trì đều đã hỗ trợ GTS Root CA mới của Google, bao gồm cả GTS Root R1 và thậm chí cả các hệ thống cũ cũng rất có thể sẽ hỗ trợ GlobalSign Root CA – R1, vốn sẽ được dùng để ký chéo chứng chỉ do Google cấp trong những năm tới.

Tuy nhiên, do tiến trình thêm chứng chỉ của bên thứ ba phần lớn nằm ngoài tầm kiểm soát của Google, nên lời khuyên chung tốt nhất 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 có sẵn.

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ỉ của riêng họ.

Khắc phục sự cố

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

Cuốn cong

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 tệp này xuống qua https://curl.haxx.se/. Bạn có thể tải nguồn xuống và tự biên dịch công cụ hoặc tải tệp nhị phân được biên dịch trước (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 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 nhóm OpenSSL hỗ trợ hoặc chứng thực theo bất kỳ cách cụ thể nào.

Bắt Wireshark, Tshark hoặc Tcpdump

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

Bạn có thể tìm thấy mã nguồn 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 man của Tshark và trên trang hướng dẫn của Tcpdump.

Lấy công cụ chính Java

Công cụ dòng lệnh keytool phải được vận chuyển cùng với mọi phiên bản Bộ phát triển Java (JDK) hoặc Môi trường chạy Java (JRE). Hãy cài đặt các phương thức này để nhận keytool.. Tuy nhiên, ít có khả năng bạn cần 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 trong trường hợp ngừng sản xuất ngừng dịch vụ

Quá trình hành động chính dành cho bạ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 các chứng chỉ gốc lưu trữ ứng dụng của bạn.

  1. Hãy làm việc với các quản trị viên hệ thống để nâng cấp kho chứng chỉ gốc cục bộ.
  2. Xem Câu hỏi thường gặp này để biết các gợi ý áp dụng cho hệ thống của bạn.
  3. Nếu bạn cần hỗ trợ thêm tuỳ theo nền tảng hoặc hệ thống, 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 hỗ trợ chung, hãy liên hệ với nhóm hỗ trợ của chúng tôi, theo mô tả trong phần 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 dựa trên khả năng tối đa.
  5. Gắn dấu sao vấn đề công khai 186840968 để biết thêm thông tin cập nhật liên quan đến quá trình di chuyển.

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

Cách khắc phục sự cố ban đầu

Hãy xem phần Cách xác minh xem kho lưu trữ chứng chỉ gốc của tôi có cần cập nhật hay không để biết 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ủa bạn cũng có thể cung cấp thông tin có giá trị nếu bạn cần nhập hoặc xuất các 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ợ Nền tảng Google Maps, hãy chuẩn bị để cung cấp cả những thông tin sau:

  1. Các máy chủ bị ảnh hưởng nằm ở đâu?
  2. Dịch vụ của bạn đang gọi đến địa chỉ IP nào của Google?
  3. Vấn đề này ảnh hưởng đến(các) API nào?
  4. Chính xác thì vấn đề bắt đầu từ 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.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 về cách sử dụng các công cụ cần thiết, hãy xem câu hỏi Tôi có thể tìm các công cụ tôi cần ở đâu?.

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

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

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

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

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

Đăng bài công khai 186840968

Khi đăng bình luận về sự cố công khai 186840968, vui lòng cung cấp thông tin nêu 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 hàm nslookup ở chế độ tương tác:

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

Cách diễn giải kết quả curl

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

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

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

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

Dữ liệu đầu ra từ máy Linux Red Hat 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

Dữ liệu đầu ra từ máy 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

Dữ liệu đầu ra từ máy Ubuntu hoặc Debian Linux sử dụng tệp PEM cho 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ể cung cấp thông tin hữu ích về curl và hệ thống của bạn.

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

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

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

Các dòng (chẳng hạn như các dòng trong mã mẫu này) cho biết kết nối đã bị chấm dứt khi giao tiếp qua TLS do có một chứng chỉ máy chủ không đáng tin cậy. Việc không có kết quả gỡ lỗi bắt đầu bằng > hoặc < cũng là các chỉ báo rõ ràng cho thấy 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 biểu thị bằng sự hiện diện của các dòng trông giống với các dòng trong mã mẫu này. Bộ thuật toán mật mã dùng cho kết nối đã mã hoá phải được liệt kê, cũng như thông tin chi tiết về chứng chỉ máy chủ được chấp nhận. Hơn nữa, sự hiện diện của các dòng bắt đầu bằng > hoặc < cho biết rằng lưu lượng truy cập HTTP có tải trọng đang được truyền thành công qua kết nối được mã hoá TLS:

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

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

Giả sử kết quả đầu ra được định dạng PEM, chẳng hạn như kết quả từ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null, bạn có thể in chứng chỉ đã 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:

    openssl x509 -inform pem -noout -text
    ````
    
  • Sau đó, dán nội dung của vùng đệm sao chép vào thiết bị đầu cuối.

  • Nhấn phím Return.

Để tìm hiểu 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?

…
---
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ý các chứng chỉ đáng tin cậy của bạn

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 Các ứng dụng di động có nguy cơ bị gián đoạn 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 các chứng chỉ tin cậy trong phần Cài đặt. Bảng này hiển thị chính xác đường dẫn trình đơn Settings (Cài đặt):

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

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

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

Thường thì bạn không thể cập nhật kho lưu trữ chứng chỉ gốc của hệ thống Android nếu không cập nhật chương trình cơ sở hoặc can thiệp vào hệ thống cho 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 gián đoạn trong nhiều năm tới, ngoài 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 các 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ỉ được ứng dụng của họ tin cậy. 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 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ư của Android cho Cấu hình bảo mật mạng.

Tuy nhiên, vì các nhà phát triển ứng dụng bên thứ ba sẽ không thể tác động đến cấu hình bảo mật mạng của lưu lượng truy cập bắt nguồn từ APK Dịch vụ Google Play, nên những nỗ lực đó có thể chỉ 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 cho bạn là dựa vào các CA do người dùng thêm, có thể do chính sách nhóm của công ty áp dụng cho thiết bị của người dùng cuối hoặc do chính người dùng cuối cài đặt.

Cửa hàng tin cậy iOS

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

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

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

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

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à thư viện SSL/TLS đã sử dụng. Tuy nhiên, trên hầu hết các bản phân phối Linux, bạn có thể tìm thấy chứng chỉ gốc mặc định theo một trong các đường dẫn sau:

  • /usr/local/share/ca-certificates: Debian, Ubuntu, các phiên bản RHEL và CentOS cũ hơn
  • /etc/pki/ca-trust/source/anchors/usr/share/pki/ca-trust-source: Panama, 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.

Cửa hàng 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 lưu trữ chứng chỉ gốc mặc định bằng lệnh sau đây:

openssl version -d

Lệnh này sẽ 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ư 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 mặc định của hệ thống như trong ví dụ ở trên, hãy xem phần cấp cao nhất Kho lưu trữ chứng chỉ gốc hệ thống của tôi ở đâu và làm cách nào để cập nhật? để đảm bảo gói chứng chỉ gốc của hệ thống luôn cập nhật.

Để biết hướng dẫn về 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 các hệ thống Linux thường nằm tại /etc/pki/java/cacerts hoặc /usr/share/ca-certificates-java, có thể được quản lý bằng công cụ dòng lệnh keytool của Java.

Để nhập từng chứng chỉ riêng lẻ vào kho chứng chỉ Java, hãy phát 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 mỗi chứng chỉ gốc được đề xuất, alias bằng một bí danh chứng chỉ duy nhất nhưng có ý nghĩa và certs.jks bằng tệp cơ sở dữ liệu chứng chỉ được dùng trong môi trường của bạn.

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

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

Theo mặc định, các ứng dụng 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 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 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 của bạn, hãy phát lệnh sau:

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

Bạn chỉ cần thay thế cert.pem bằng tệp chứng chỉ tương ứng với từng chứng chỉ gốc được đề xuất, cert-name bằng một biệt hiệu có ý nghĩa của chứng chỉ 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, vui lòng tham khảo hướng dẫn chính thức về chứng chỉ Công cụ NNSS, 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 của Microsoft .NET

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

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

Tệp PEM là gì?

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

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

Bạn cũng có thể sử dụng các công cụ như openssl để giải mã toàn bộ chứng chỉ thành dạng mà con người có thể đọc được. Hãy xem mục 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 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à một định dạng nhị phân chuẩn cho các chứng chỉ mã hoá. Các chứng chỉ trong tệp PEM thường là chứng chỉ DER được mã hoá Base64.

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

Tệp đã xuất có hậu tố ".cer" có thể chứa chứng chỉ được mã hoá PEM, nhưng thường là tệp nhị phân, thường là chứng chỉ đượ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ỉ từ tệp PEM, ngay cả khi tệp này chứa nhiều chứng chỉ. Hãy xem câu hỏi Làm cách nào để trích xuất từng chứng chỉ từ roots.pem? để xem cách chia tệp trước.

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

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

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

Thao tác này sẽ tạo một số tệp PEM riêng lẻ tương tự như các tệp được liệt kê dướ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 riêng các 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ể sử dụng công cụ dòng lệnh của bộ công cụ OpenSSL openssl để chuyển đổi tệp giữa tất cả các định dạng tệp chứng chỉ thường dùng. Dưới đây là hướng dẫn chuyển đổi từ tệp PEM sang các định dạng tệp chứng chỉ thường dùng nhất.

Để biết danh sách đầy đủ các tuỳ chọn có thể sử dụng, 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 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ể thực hiện 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 thành PKCS #7?

Khi sử dụng openssl, bạn có thể thực hiện 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 thành PKCS #12 (PFX)?

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

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

Làm thế 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ể phát lệnh sau để liệt kê tất cả chứng chỉ trong kho chứng chỉ của mình, cùng với bí danh mà bạn có thể sử dụng để xuất từng chứng chỉ:

keytool -v -list -keystore certs.jks

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

Để xuất một chứng chỉ riêng lẻ ở đị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 mình, đồng thời cung cấp aliasalias.pem tương ứng với chứng chỉ mà bạn muốn xuất.

Để biết thêm thông tin, vui lòng tham khảo hướng dẫn Tài liệu tham khảo về công cụ Nền tảng Java, Phiên bản chuẩn: 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ể phát lệnh sau để liệt kê tất cả chứng chỉ trong kho chứng chỉ của mình, cùng với biệt hiệu mà bạn có thể sử dụng để xuất từng chứng chỉ:

certutil -L -d certdir

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

Để xuất một chứng chỉ riêng lẻ ở đị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 sử dụng trong môi trường, đồng thời cung cấp cert-namecert.pem tương ứng với chứng chỉ mà bạn muốn xuất.

Để biết thêm thông tin, vui lòng tham khảo hướng dẫn chính thức về chứng chỉ Công cụ NNSS, 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 sẽ cho 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 nội dung tương tự như:

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

Để biết hướng dẫn về cách tải openssl, hãy xem phần Tải 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 nội dung tương tự như:

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

Extensions:

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

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

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

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

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

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

Ngoài ra, nếu đã xuất thành công chứng chỉ gốc đáng tin cậy vào tệp PEM hoặc kho chứng chỉ gốc của bạn đã chứa tệp PEM được lưu trữ, thì bạn có thể thử mở tệp bằng trình chỉnh sửa văn bản bất kỳ 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 của tổ chức phát hành 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 cũng có thể chỉ chứa phần chứng chỉ. Trong những trường hợp như vậy, tên của tệp, chẳng hạn như GTS_Root_R1.pem, có thể mô tả chứng chỉ thuộc về CA nào. Chuỗi chứng chỉ giữa mã thông báo -----BEGIN CERTIFICATE----------END CERTIFICATE----- cũng được đảm bảo là duy nhất cho từng CA.

Tuy nhiên, ngay cả khi bạn thiếu các công cụ trên, vì mỗi chứng chỉ trong gói CA gốc đáng tin cậy của Google đều được gắn nhãn đúng cách, bạn vẫn có thể so khớp một cách chính xác các CA gốc từ gói tổ chức với các CA gốc trong kho lưu trữ chứng chỉ gốc của bạn theo 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 lưu trữ chứng chỉ gốc riêng hoặc dựa trên kho chứng chỉ mặc định do trình điều hành cung cấp. Tuy nhiên, tất cả các trình duyệt hiện đại đều phải cho phép bạn quản lý hoặc ít nhất là xem tập hợp các CA gốc mà họ tin tưởng. Hãy xem câu hỏi Các ứng dụng JavaScript có nguy cơ bị hỏng 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?.

Phụ lục

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

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

Mọi nguồn thông tin 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 sẽ không chính xác và không được coi là nguồn đáng tin cậy. 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 về Stack Exchange, cũng như các trang web như AdamW trên Linux và các trang web khácblog xác nhận, cùng nhiều trang web khác.

Ngoài ra, vui lòng tham khảo 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ể xem bài viết Chứng chỉ và ghim khoá công khai Bản tóm tắt về việc ghim thông tin về Dự án bảo mật ứng dụng web mở (OWASP). Để biết hướng dẫn dành riêng cho Android, vui lòng tham khảo tài liệu đào tạo chính thức Các phương pháp hay nhất của Android về bảo mật và quyền riêng tư về Bảo mật bằng HTTPS và SSL. Để thảo luận về liên quan đến chứng chỉ và ghim khoá công khai trên Android, bạn có thể thấy bài đăng Android Security: SSL Ghim trên blog của Matthew Dolan hữu ích,

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

Để xem danh sách đầy đủ các CA gốc được 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 nhánh phát triển 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.