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

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

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

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

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

Thuật ngữ

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

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

Thông tin chung

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

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

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

Sau giai đoạn đầu, 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ột tổ chức phát hành chứng chỉ gốc (CA) nổi tiếng và uy tín rộng rãi đảm bảo. Google đã mua lại từ GMO GlobalSign để dễ dàng chuyển đổi sang CA gốc của Google Trust Services (GTS) do chúng tôi tự phát hành.

Trên thực tế, tất cả máy khách 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 nên có thể thiết lập kết nối an toàn 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, theo thiết kế, CA không thể cấp chứng chỉ có hiệu lực vượt quá thời gian hết hạn của chứng chỉ của chính chứng chỉ đó. Khi GS Root R2 hết hạn vào ngày 15 tháng 12 năm 2021, Google sẽ di chuyển các dịch vụ của mình sang một CA mới GTS Root R1 Cross bằng cách sử dụng chứng chỉ do CA gốc của Google GTS Root R1 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 vào các CA gốc của 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 chữ ký chéo từ GMO GlobalSign bằng cách sử dụ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 một trong hai (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 bởi giai đoạn di chuyển thứ hai.

Đ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ử 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 thông tin sau đây đúng:

dịch vụ của bạn chạy các nền tảng không chuẩn hoặc cũ và/hoặc bạn duy trì kho lưu trữ chứng chỉ gốc của riêng 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ộ chứng chỉ đầy đủ từ gói CA gốc đáng tin cậy của Google

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

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

Bạn cũng nên tiếp tục đồng bộ hoá kho lưu trữ chứng chỉ gốc 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ị thay đổi CA gốc trong tương lai. Tuy nhiên, những thay đổi này sẽ được thông báo trước. 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ề những 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 mới nhất.

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 mà 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ẽ chuyển sang một CA GTS Root R1 Cross mới được phát hành. Điều này có nghĩa là các dịch vụ của chúng tôi sẽ từng bước chuyển đổi sang chứng chỉ lá TLS do CA mới này phát hành.

Hầu hết tất cả ứng dụng và hệ thố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 chứng chỉ này thông qua các bản cập nhật phần mềm thông thường. Ngoài ra, 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 lưu trữ chứng chỉ gốc
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ộ chứng chỉ đầy đủ 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 đưa ra hướng dẫn chung để kiểm thử xem hệ thống của bạn có bị ảnh hưởng hay không.

Hãy xem câu hỏi Tại sao tôi nên đồng bộ hoá kho chứng chỉ gốc của mình với gói CA gốc đáng tin cậy của Google? để biết đầ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 số phát hành 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ề những lần 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 dành riêng cho từng sản phẩm sớm nhất có thể, sau khi thông báo công khai trên blog.

Ngoài ra, 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 một số lượng lớn 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 dữ liệu đó 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 trên Nền tảng Google Maps sử dụng chứa tất cả CA được liệt kê trong gói CA gốc đáng tin cậy của Google, các dịch vụ 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 các thay đổi về CA gốc 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 của mình với gói CA gốc đáng tin cậy của Google? và Loại ứng dụng nào có nguy cơ bị lỗi? để biết thêm thông tin chi tiết.

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

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

Kiểm thử môi trường ứng dụng dựa trên các điểm cuối kiểm thử có trong danh sách dưới đây:

Nếu có thể thiết lập kết nối TLS tới điểm cuối kiểm thử GTS Root R1 Cross, thì bạn sẽ không bị ảnh hưởng bởi thời hạn GS Root R2 hết hạn.
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í sẽ có thể được bảo vệ khỏi thời điểm GTS Root R1 Cross và GlobalSign Root CA – R1 hết hạn trong năm 2028.

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

Khách hàng có thể bị ảnh hưởng cầ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.

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

Có công cụ đơn giản nào tôi có thể sử dụng để xác minh kho lưu trữ chứng chỉ gốc 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ó sẵn trên hầu hết các nền tảng và cung cấp nhiều tuỳ chọn để kiểm thử chế độ thiết lập.

Để biết hướng dẫn cách nhận curl, hãy xem phần Tạo curl bên dưới.

Các lệnh openssl hiển thị bên dưới là dành cho phiên bản 1.1.1 trở lên. Các phiên bản trước 1.1.1 không được hỗ trợ. Nếu bạn đang sử dụng phiên bản cũ, hãy nâng cấp hoặc sửa đổi các lệnh này cho phiên bản của mình nếu cầ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ải 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

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?

Giai đoạn 1 (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.
Giai đoạn hai (di chuyển sang GTS Root R1 Cross) đã được thông báo vào tháng 3 năm 2021 và sẽ được triển khai 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 cuối cùng sẽ được thông báo trước về việc chứng chỉ hết hạn trong tương lai.

Tuy nhiên, bạn sẽ có thể chứng minh ứng dụng của mình trong tương lai nếu tiếp tục lưu trữ chứng chỉ gốc đồng bộ 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.

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

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

Quá trình phát hành theo giai đoạn bắt đầu trong một trung tâm dữ liệu duy nhất.
Quá trình triển khai sẽ dần được mở rộng cho nhiều trung tâm dữ liệu hơn cho đến khi được áp dụng trên toàn cầu.
Nếu phát hiện thấy vấn đề nghiêm trọng ở bất kỳ giai đoạn nào, thì 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 vấn đề.
Dựa trên dữ liệu đầu vào từ các vòng lặp trước, các dịch vụ sau này của Google sẽ được đưa vào bản phát hành cho đến khi 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?

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

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

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ểm 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 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 quá trình xác thực chứng chỉ không thành công.

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

Yêu cầu tối thiểu để ứng dụng TLS có thể 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) DNS, vì vậy, quá trình xử lý chứng chỉ của ứng dụng phải có thể hỗ trợ SAN 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 Những yêu cầu nên đáp ứng để ứng dụng TLS có thể giao tiếp với Google 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 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 sử dụng một hệ điều hành phổ biến, ví dụ: Ubuntu, Red Hat, Windows 10 hoặc Server 2019, OS X) vẫn được duy trì và nhận các bản cập nhật thường xuyên, thì 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ì có thể bạn sẽ có hoặc không có chứng chỉ GTS Root R1. Tuy nhiên, kho chứng chỉ gốc của bạn rất có thể sẽ chứa GlobalSign Root CA – R1, một trong những CA gốc lâu đời nhất và đáng tin cậy nhất.

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

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

Các ứng dụng API JavaScript cho 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 bất kỳ SDK Maps nào cho Android, SDK Maps cho iOS, SDK Địa điểm dành cho Android hoặc SDK Địa điểm dành cho iOS, các quy tắc tương tự sẽ áp dụng như đối với ứ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ị hỏng không? để biết thêm thông tin 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 sẽ cần đảm bảo tự cập nhật gói chứng chỉ của mình. Như đã thảo luận trong câu hỏi Tại sao tôi cần lưu trữ chứng chỉ gốc của mình đồng bộ với gói CA gốc đáng tin cậy của Google?, bạn nên nhập tất cả chứng chỉ từ gói CA gốc của Google đáng tin cậy vào kho lưu trữ chứng chỉ gốc của riêng 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, thì 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ề tính năng 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 nêu 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 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ả 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 kiểm tra 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ỉ từ 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 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ì, thì vì các lý do khác, bạn không thể vá lỗi cho hệ điều hành và thư viện hoặc duy trì kho lưu trữ 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ề những lần di chuyển trong tương lai? để tìm hiểu cách nhận thông tin cập nhật về những lần di chuyển CA gốc trong tương lai. Việc thường xuyên lưu trữ 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 việc gián đoạn dịch vụ trong tương lai do các thay đổi về CA, đồng thời sẽ giúp dịch vụ của bạn chạy sau khi cả GTS Root R1 Cross và GlobalSign Root CA – R1 hết hạn.

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

Việc này sẽ có nguy cơ làm hỏng ứng dụng của bạn bất cứ lúc nào chúng tôi đăng ký chứng chỉ mới hoặc chuyển đổi 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, đồ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 mình khỏi những đ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ỉ liên kết với chứng chỉ đó.

Mọi cách 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 đáng tin cậy.

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

Chứng chỉ gốc của GTS đã được hầu hết trình duyệt hiện đại nhúng và tin cậy. Đồng thời, chữ ký chéo từ GMO GlobalSign sẽ đảm bảo quá trình di chuyển 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ũ. Phiên bản này bao gồm tất cả cá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 cậy. Mặc dù vị trí chính xác còn 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 Settings (Cài đặt).

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

Các thiết bị iOS của Android và Apple vẫn nhận được các bản cập nhật thường xuyên từ nhà sản xuất thiết bị cũng dự kiến là một 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 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, việc hỗ trợ các CA gốc GTS, bao gồm cả GTS Root R1 có thể vẫn bị giới hạn trong các phiên bản Android trước 10.

Đối với 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ả phiên bản iOS 5 trở lên đều hỗ trợ GlobalSign Root CA – R1.

Chúng tôi đã hỗ trợ các CA gốc của GTS, bao gồm cả GTS Root R1 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ụ: các nhà sản xuất hệ điều hành như Apple và Microsoft, các nhóm Android và Chrome OS của chính Google; các nhà phát triển trình duyệt như Mozilla, Apple, Microsoft hay nhóm Chrome của Google; các nhà sản xuất phần cứng, chẳng hạn như điện thoại, hộp giải mã tín hiệu số, TV, máy chơi trò chơi, máy in và nhiều tên khác.

Do đó, rất có thể mọi hệ thống hiện đ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 hệ thống cũ rất có khả năng sẽ hỗ trợ GlobalSign Root CA – R1 – sẽ được dùng để ký chéo các chứng chỉ do Google cấp trong những năm tới.

Tuy nhiên, vì tiến trình đưa 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 vào 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?

Bắt đầu 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 bản phân phối 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.

Đang 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 xây dựng 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 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, một công cụ dòng lệnh tshark và tcpdump, nhưng bạn có thể tìm thấy phiên bản 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 của Tcpdump và LibPCAP tại https://www.tcpdump.org.

Tài liệu về các công cụ hữu ích này có thể được xem trong Hướng dẫn sử dụng Wireshark, tương ứng trên trang man của Tshark và trang hướng dẫn của Tcpdump.

Tải công cụ từ khoá 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). Bạn có thể không cần cài đặt các phương thức này để nhận keytool.. Tuy nhiên, có thể bạn không cần sử dụng keytool để xác minh chứng chỉ gốc, trừ phi ứng dụng của bạn được xây dựng bằng Java.

Việc cần làm trong trường hợp ngừng sản xuất

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.

Làm việc cùng với các quản trị viên hệ thống để nâng cấp kho lưu trữ chứng chỉ gốc cục bộ của bạn.
Kiểm tra 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.
Nếu bạn cần hỗ trợ thêm cho từng 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.
Để được hỗ trợ về những vấn đề 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ợ Nền tảng Google Maps. Lưu ý: Đối với các vấn đề riêng của nền tảng, hướng dẫn chỉ được cung cấp trên cơ sở nỗ lực tối đa.
Gắn dấu sao số phát hành 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ợ Nền tảng Google Maps

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

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

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

Kết quả 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á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ụ tôi cần ở đâu?.

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

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

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

Địa chỉ IP công khai của bạn là gì?
Địa chỉ IP công khai của máy chủ DNS của bạn là gì?
Nếu có thể, hãy chụp gói tcpdump hoặc Wireshark trong 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ũ).
Nếu có thể, hãy trích dẫn nhật ký từ dịch vụ của bạn cho thấy chính xác lý do kết nối TLS (Bảo mật tầng truyền tải) bị lỗi, tốt nhất là kèm theo thông tin đầy đủ về chuỗi chứng chỉ máy chủ.

Để biết hướng dẫn về 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ụ tôi cần ở đâu?.

Đăng trên số phát hành công khai 186840968

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

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

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

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

Trên Windows, bạn có thể sử dụng 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 sẽ cung cấp nhiều thông tin hữu ích. Sau đây là một số hướng dẫn để diễn giải kết quả:

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

Dữ liệu đầu ra từ máy Red Hat Linux với 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 các dòng sau:

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

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

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

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

Các yêu cầu đi chứa tiêu đề 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: */*
>

Giao thức 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ị kết thúc trong quá trình giao tiếp giữa TLS do có 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 biết lần kết nối không thành công:

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

Bắt tay TLS thành công

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

*   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, thì 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 đó, 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 Quay lại.

Để xem ví dụ về dữ liệu nhập 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 trong OpenSSL sẽ như thế nào?

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

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

---
…

Quản lý chứng chỉ đáng tin cậy 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ỉ Android đáng tin cậy

Như đã đề cập trong câu hỏi Các ứng dụng di động có nguy cơ bị hỏng 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ị đườ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 có sẵn các chứng chỉ gốc quan trọng nhất cho mỗi phiên bản Android, dựa trên 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 trở lại nhật ký phiên bản kho lưu trữ GitHub ca-certificates AOSP, nơi hình ảnh hệ thống không còn nữa:

Phiên bản Android	GTS gốc R1	Root CA – R1 của GlobalSign	GlobalSign Root R2 (có hiệu lực đến ngày 15/12/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ở hay 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 vòng đời hiệu quả của hầu hết thiết bị hiện có.

Kể từ phiên bản 7.0, Android cung cấp cho 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ỉ ứ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ư cho Android 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 như vậy có thể chỉ mang lại một phần giải pháp.

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

Cửa hàng tin cậy iOS

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

Tuy nhiên, mọi chứng chỉ bổ sung được cài đặt trên thiết bị iOS sẽ hiển thị trong Settings > General > Profile (Cài đặt > Chung > Hồ sơ). Nếu không có chứng chỉ bổ sung nào được cài đặt, thì mục trong trình đơn Profile (Hồ sơ) có thể không hiển thị.

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

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

Kho chứng chỉ gốc của hệ thống ở đâ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 được sử dụng. Tuy nhiên, trên hầu hết các bản phân phối Linux, bạn có thể tìm thấy các 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 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 lưu trữ 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:

openssl version -d

Lệnh này in ra OPENSSLDIR, tương ứng với thư mục cấp cao nhất mà thư viện này và các cấu hình của thư viện có thể tìm thấy 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 kiểm tra 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 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 của chúng, thường nằm tại /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 Java keytool.

Để nhập một chứng chỉ riêng lẻ vào kho lưu trữ 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 với một đại diện 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ỉ cho 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, 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 với 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, vui lòng tham khảo hướng dẫn chính thức về Chứng chỉ công cụ NSS 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

Nhà phát triển Windows .NET có thể thấy ít nhất các bài viết Microsoft sau đây 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 bảo vệ quyền riêng tư (PEM) là định dạng tệp văn bản tiêu chuẩn thực tế để lưu trữ và gửi chứng chỉ mã hoá, khoá, v.v., được chính thức hoá dưới dạng tiêu chuẩn phi luật định trong RFC 7468.

Mặc dù định dạng tệp là có thể đọc được, nhưng thông tin dữ liệu chứng chỉ nhị phân được mã hoá Base64 thì không. Tuy nhiên, thông số kỹ thuật PEM cho phép tạo văn bản giải thích ở trước hoặc sau nội dung chứng chỉ được mã hoá văn bản. Nhiều công cụ cũng dùng tính năng này để cung cấp bản tóm tắt văn bản rõ ràng về các thành phần 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ụ, chẳng hạn như openssl để giải mã toàn bộ chứng chỉ thành dạng mà con người có thể đọc được. Vui lòng xem phần Cách in chứng chỉ PEM ở dạng mà con người có thể đọc đượ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 chứng chỉ mã hoá. 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á bằng DER. Theo quy ước, tệp ".cer" thường chỉ chứa một chứng chỉ duy nhất.

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

Một số hệ thống, ví dụ: Java keytool chỉ có thể nhập một chứng chỉ duy nhất từ một tệp PEM, ngay cả khi tệp đó có 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 openssl của bộ công cụ 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ó 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 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ể 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 thành PKCS #7?

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

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

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

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

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

Bạn cần cung cấp mật khẩu tệp khi tạo bản 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 lưu trữ chứng chỉ gốc của bạn

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

Khi sử dụng keytool, bạn có thể ra lệnh sau để liệt kê tất cả chứng chỉ trong kho chứng chỉ của mình, cùng với bí danh mà bạn có thể 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ỉ. Bạn sẽ cần có bí danh này 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:

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 alias và alias.pem tương ứng với chứng chỉ mà bạn muốn xuất.

Để biết thêm thông tin, vui lòng tham khảo hướng dẫn Tài liệu tham khảo về công cụ 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ể ra lệnh sau để liệt kê tất cả chứng chỉ trong kho chứng chỉ của mình, cùng với 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ẽ hiển thị 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 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 dùng trong môi trường của mình, đồ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, vui lòng tham khảo hướng dẫn chính thức về Chứng chỉ công cụ NSS cũng như tài liệu về hệ điều hành của bạn.

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

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

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

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

Ra lệnh

openssl x509 -in GTS_Root_R1.pem -text

sẽ xuất 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 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 cách tải keytool, hãy xem phần Tải công cụ từ 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 sẽ 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ỉ đến 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 lưu trữ chứng chỉ gốc của bạn đã chứa các tệp PEM được lưu trữ, thì bạn có thể thử mở các tệp này 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 về 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 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ả chứng chỉ thuộc về CA nào. Chuỗi chứng chỉ giữa mã thông báo -----BEGIN CERTIFICATE----- và -----END CERTIFICATE----- cũng được đảm bảo là duy nhất cho từng CA.

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

Các trình duyệt web có thể sử dụng kho lưu trữ chứng chỉ gốc riêng hoặc dựa vào kho lưu trữ chứng chỉ mặc định do hoạt động 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 thông tin 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 chủ yếu dựa 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ũ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 không chính xác và không được coi là nguồn thông tin đá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 đáp về Stack Exchange, cũng như các trang web như AdamW trên Linux, v.v. và blog 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ề Dịch vụ Google Trust.

Để biết thêm thông tin chi tiết về các chủ đề nâng cao, chẳng hạn như tính năng ghim chứng chỉ, bạn có thể xem bài viết Dự án bảo mật ứng dụng web mở (OWASP) Chứng chỉ và ghim khoá công khai và thông tin Bản tóm tắt về cách ghim. Để biết hướng dẫn cụ thể 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ư Bảo mật bằng HTTPS và SSL. Để thảo luận về tính năng ghim chứng chỉ và khoá công khai trên Android, bạn có thể thấy bài đăng Bảo mật Android: Ghim SSL trên blog của Matthew Dolan.

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

Để biết danh sách đầy đủ các CA gốc được AOSP tin cậy, hãy tham khảo kho lưu trữ GitHub ca-certificates. Đối với mọi phiên bản dựa trên các 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ữ phù hợp do nhà cung cấp hệ điều hành cung cấp.