Вопросы и ответы по переводу платформы Google Карт на собственный корневой ЦС Google

Общие сведения

Устранение неполадок

Управление доверенными сертификатами

Приложение

Общие сведения

Что меняется?

Обзор

Google претворяет в жизнь многолетний план по созданию и применению собственных корневых сертификатов, или криптографических подписей, на которых основывается работа технологий безопасности TLS/SSL при взаимодействии через HTTPS.

В настоящее время безопасность шифрования TLS на платформе Google Карт гарантируется корневым сертификатом, который выдан глобальным ЦС GeoTrust. Это всемирно известный и широко используемый центр сертификации, принадлежащий компании Symantec. Почти все клиенты, использующие TLS (веб-браузеры, смартфоны и серверы приложений), знают этот корневой сертификат, а значит могут гарантировать защищенное подключение к серверам платформы Google Карт.

К началу 2020-х годов компания Google планирует перевести все сервисы платформы Google Карт на корневой сертификат собственного центра сертификации, известного как Google Trust Services (GTS).

На промежуточном этапе этого перехода в 2018 году платформа Google Карт переведена на другой корневой сертификат GlobalSign (GS), широко используемый как доверенный. Компания Google приобрела права на использование этого корневого сертификата и центра сертификации GlobalSign, от которого выдан этот сертификат, чтобы упростить процесс перехода.

Почти все клиенты, использующие TLS, уже сейчас признают корневой сертификат GlobalSign, поэтому этот промежуточный переход никак не повлияет на их работу с платформой Google Карт.

Однако в определенных сценариях использования, особенно в узкоспециализированных, например на встроенных устройствах или в очень старых браузерах и операционных системах, у некоторых клиентов может отсутствовать корневой сертификат GlobalSign. Такие клиенты необходимо обновить, установив новый сертификат, чтобы они могли защищать подключение к платформе Google Карт. Компания Google не имеет возможности обнаруживать такие клиенты, а значит владельцам приложений придется самостоятельно проверить свои приложения. Google Trust Services предоставляет для этих целей тестовые конечные точки HTTPS, которые перечислены на сайте GTS. Технические подробности приводятся ниже.

Скорее всего, к моменту перехода большинство систем будет готово к использованию сертификатов GTS, но выполнив рекомендации из этого документа, вы сможете избежать проблем при переходе даже в узкоспециализированных системах.

Техническая сводка

Как было объявлено 16 марта 2017 года на портале пользовательской поддержки тарифного плана Premium платформы Google Карт и ранее в блоге Google по безопасности, компания Google создала собственный корневой центр сертификации GTS. Как и другие сервисы Google, платформа Google Карт будет постепенно переходить на сертификаты TLS, подписанные корневыми ЦС GTS.

В качестве промежуточного шага компания Google приобрела уже существующий и широко используемый как доверенный центр сертификации GS Root R2. Для платформы Google Карт переход с корневого сертификата GeoTrust на этот новый сертификат был начат в конце 2017 года и завершен в начале 2018 года.

Почти для всех клиентов, использующих TLS, корневой сертификат GS Root R2 включен в заводскую конфигурацию или передан в ходе плановых обновлений программного обеспечения, но если для подключения к платформе Google Карт используются старые клиенты, на которых может отсутствовать доверие к этому сертификату, разработчикам необходимо проверить все такие клиенты и при необходимости передать на них новый сертификат.

Корневой сертификат GS Root R2 и все корневые сертификаты GTS можно получить на сайте GTS. Также сайт GTS предоставляет для целей тестирования несколько конечных точек с сертификатами TLS, подписанными каждым из центров сертификации. Например, если клиент успешно устанавливает TLS-подключение к тестовой конечной точке GS Root R2, значит он доверяет сертификату GS Root R2 и предстоящие изменения не должны его затронуть.

Компания Google использовала корневой ЦС GS Root R2 до конца 2018 года. После этого возможен перевод платформы Google Карт на прямое использование центра сертификации GTS или, при некоторых обстоятельствах, возврат к сторонним центрам сертификации, включая GS Root R3.

Как следить за этим переходом?

Чтобы быть в курсе новостей, пометьте для отслеживания общедоступную страницу проблемы 67842936. Также в ходе переноса будет обновляться эта статья с вопросами и ответами по мере появления новых аспектов, интересных для широкой публики.

Мы используем много сервисов Google. На все ли из них повлияет переход на новый корневой ЦС?

Да, переход на новый корневой ЦС затронет все сервисы и API Google, но в разные сроки. Однако, если вы убедились, что приложение доверяет всему набору корневых сертификатов, которые перечислены в образце PEM-файла от Google, такое приложение уже готово к изменениям в корневых сертификатах, независимо от используемого в нем набора API и сервисов Google. Подробная информация приведена в ответе на вопрос Нужно ли устанавливать все корневые сертификаты из образца PEM-файла, предоставленного Google?

Как узнать, нужно ли обновлять хранилище сертификатов?

Протестируйте среду приложения по тестовым конечным точкам, которые перечислены вместе с корневыми ЦС на сайте GTS. Если TLS-подключение к тестовой конечной точке GS Root R2 и тестовой среде для сертификата Google устанавливается успешно, значит приложение должно работать без проблем по крайней мере до конца 2018 года.

Мы настоятельно рекомендуем установить все сертификаты из образца PEM-файла от Google, чтобы подготовить свою систему ко всем предстоящим изменениям, если у вас нет полной уверенности в том, что вы всегда будете поддерживать актуальность рабочей среды и своевременно устанавливать исправления.

Есть ли простой инструмент для проверки хранилища сертификатов?

Инструмент командной строки curl, доступный на большинстве платформ, дает широкие возможности для проверки среды. Инструкции по получению curl приведены в разделе Как получить curl.

Тестирование хранилища сертификатов, используемого по умолчанию
# Google certificate test sandbox
$ curl -vvI https://cert-test.sandbox.google.com/
# GS Root R2
$ curl -vvI https://good.gsr2demo.pki.goog/
# GS Root R4
$ curl -vvI https://good.gsr4demo.pki.goog/
# GS Root R3
$ curl -vvI https://valid.r3.roots.globalsign.com/
# GTS Root R1
$ curl -vvI https://good.r1demo.pki.goog/
# GTS Root R2
$ curl -vvI https://good.r2demo.pki.goog/
# GTS Root R3
$ curl -vvI https://good.r3demo.pki.goog/
# GTS Root R4
$ curl -vvI https://good.r4demo.pki.goog/
$ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
$ openssl s_client -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null
Проверка пакета корневого ЦС Google
Скачайте образец PEM-файла от Google и выполните описанные ниже действия.
# Google certificate test sandbox
$ curl -vvI --cacert roots.pem https://cert-test.sandbox.google.com/
# GS Root R2
$ curl -vvI --cacert roots.pem https://good.gsr2demo.pki.goog/
# GS Root R4
$ curl -vvI --cacert roots.pem https://good.gsr4demo.pki.goog/
# GS Root R3
$ curl -vvI --cacert roots.pem https://valid.r3.roots.globalsign.com/
# GTS Root R1
$ curl -vvI --cacert roots.pem https://good.r1demo.pki.goog/
# GTS Root R2
$ curl -vvI --cacert roots.pem https://good.r2demo.pki.goog/
# GTS Root R3
$ curl -vvI --cacert roots.pem https://good.r3demo.pki.goog/
# GTS Root R4
$ curl -vvI --cacert roots.pem https://good.r4demo.pki.goog/
$ openssl s_client -CAfile roots.pem -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
$ openssl s_client -CAfile roots.pem -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null

Как будет проходить переход?

Когда будет проходить переход?

Первый этап, который включал переход на сертификаты, выданные промежуточными ЦС, закрепленными в GS Root R2, начался в конце 2017 года и завершился в первой половине 2018 года.

График следующих этапов перехода будет объявлен в ближайшие годы, но в любом случае задолго до истечения срока действия сертификата GS Root R2 (2021 год).

Общий план внедрения для каждого сервиса Google

  • Поэтапное внедрение начнется с одного центра обработки данных.
  • Изменение будет постепенно внедряться в других центрах обработки данных, пока не будет достигнуто глобальное покрытие.
  • При обнаружении серьезных проблем на любом этапе все тестовые развертывания могут временно откатываться к предыдущему состоянию, пока не будут решены эти проблемы.
  • На основе информации, полученной на предыдущих этапах, изменение будет внедряться в остальных сервисах Google, пока не будет реализован полный переход всех сервисов Google на новые сертификаты.

На кого, когда и как это повлияет?

По мере перехода центров обработки данных все больше разработчиков, работающих с платформой Google Карт, будут получать новые сертификаты. Эти изменения будут до некоторой степени территориально ограниченными, поскольку запросы клиентов в большинстве случаев перенаправляются к серверу в ближайшем центре обработки данных. Мы не можем заранее уверенно сообщить, на кого, когда и где повлияет это изменение, поэтому рекомендуем всем клиентам уже сейчас проверить свои системы на совместимость с грядущими изменениями, пока не начались следующие этапы перехода на корневой центр сертификации Google.

Чего следует остерегаться

Клиенты, на которых не настроены необходимые корневые сертификаты, не смогут подтвердить TLS-подключение к платформе Google Карт. В такой ситуации клиенты обычно выдают предупреждение о сбое при проверке сертификата. В зависимости от используемой конфигурации TLS клиенты могут продолжать попытки обращения к платформе Google Карт или перестать отправлять такие запросы.

Каковы минимальные требования для взаимодействия клиента TLS с платформой Google Карт?

Изучите раздел Каковы минимальные требования для взаимодействия клиента TLS с сервисами Google? в этой статье.

Платформа Google Карт не предусматривает дополнительных требований.

Приложения каких типов могут перестать работать?

Приложения, которые используют системное хранилище сертификатов без дополнительных ограничений со стороны разработчиков

Приложения веб-сервисов платформы Google Карт

Если вы используете одну из популярных ОС (например, Ubuntu, Red Hat, Windows 7+ или Server 2008+, OS X), для которой предоставляется поддержка и регулярные обновления, то в вашем хранилище сертификатов уже наверняка есть сертификат GS Root R2.

Если ваша версия ОС уже устарела и не обновляется, в ней может отсутствовать сертификат GS Root R2. Например, этот сертификат есть в версии Windows XP SP2, но отсутствует в версии Windows XP SP1. На всех старых устройствах необходимо проверить, доверяют ли они этому сертификату.

Для мобильных приложений, которые напрямую обращаются к веб-сервисам платформы Google Карт, применимы рекомендации из ответа на вопрос Есть ли риск, что перестанут работать мобильные приложения?

Клиентские приложения платформы Google Карт

Приложения, которые работают с Google Maps JavaScript API, обычно используют корневые сертификаты того веб-браузера, в котором запущено приложение. Подробная информация приведена в ответе на вопрос Есть ли риск, что перестанут работать приложения, использующие Google Maps JavaScript API?

К оригинальным мобильным приложениям на Android и iOS, которые используют SDK Google Карт или Places, применяются те же правила, что к приложениям, которые обращаются к веб-сервисам платформы Google Карт.

Подробная информация приведена в ответе на вопрос Есть ли риск, что перестанут работать мобильные приложения?

Приложения, которые используют собственные пакеты сертификатов или расширенные функции безопасности, например закрепление сертификатов

Вам придется самостоятельно обновить пакет сертификатов. Как уже упоминалось в ответе на вопрос Нужно ли устанавливать все корневые сертификаты из образца PEM-файла, предоставленного Google?, мы рекомендуем импортировать в хранилище сертификатов все корневые сертификаты из образца PEM-файла от Google.

Если вы используете закрепленные сертификаты или открытые ключи для доменов Google, к которым подключается ваше приложение, обязательно добавьте эти сертификаты и открытые ключи в список доверенных объектов для приложения.

Подробную информацию о закреплении сертификатов и открытых ключей можно найти в ресурсах, перечисленных в этом разделе.

Нужно ли устанавливать все корневые сертификаты из образца PEM-файла, предоставленного Google?

Чтобы сразу подготовить систему к предстоящему изменению, установите все сертификаты из образца PEM-файла от Google. Это особенно важно в тех случаях, если операционная система не получает регулярных обновлений в штатном порядке или вы поддерживаете собственные пакеты сертификатов для приложения.

Почему не нужно устанавливать промежуточные сертификаты ЦС?

Устанавливайте только те корневые сертификаты, которые включены в образец PEM-файла от Google, и доверьте корневому сертификату подтверждение подлинности всей цепочки связанных с ним сертификатов. Это в равной степени относится как к сертификатам отдельных серверов (например, для узла maps.googleapis.com), так и к любым промежуточным центрам сертификации (GIAG3, GTS CA 1O1, GIAG4 и т. п.).

В любой современной реализации библиотек для работы с TLS предусмотрена возможность автоматически проверять такие цепочки доверия, если есть доверие к корневому центру сертификации.

Есть ли риск, что перестанут работать приложения, использующие Google Maps JavaScript API?

Корневой центр сертификации GlobalSign R2 входит в стандартную конфигурацию и является доверенным в большинстве современных браузеров. Это означает, что такие браузеры смогут ещё некоторое время успешно подключаться к сервисам Google. Если браузер активно обновляется, почти наверняка в определенный момент он начнет поддерживать все остальные корневые ЦС Google.

Но не забывайте, что нормальная работа с Google Maps JavaScript API гарантируется только в поддерживаемых браузерах, поэтому мы рекомендуем выбрать один из включенных в этот список браузеров и поддерживать его актуальность, чтобы в будущем не возникло никаких проблем.

Есть ли риск, что перестанут работать мобильные приложения?

Устройства Android и Apple, которые получают регулярные обновления от производителя, должны быть защищены от любых проблем. На большинстве старых смартфонов Android уже установлены по меньшей мере сертификаты GS Root R2 и GS Root R3, но список доверенных сертификатов зависит от производителя устройства, модели и версии Android. В новых версиях Android Open Source Project (AOSP), которые используются на устройствах Google Nexus и Pixel, также по умолчанию есть поддержка сертификата GS Root R4. Поддержка корневых ЦС GTS пока очень ограничена во всех выпущенных версиях Android.

Для устройств iOS компания Apple публикует актуальный список доверенных корневых ЦС по каждой из версий iOS на своих страницах поддержки. Все версии iOS, начиная с версии 5, поддерживают GS Root R2 и R3, а в версиях 7 и выше также поддерживается GS Root R4. Как и в текущих версиях Android, в iOS корневые сертификаты GTS на момент написания этой статьи ещё не поддерживаются.

Подробная информация приведена в разделе Как проверить доверенные корневые сертификаты на мобильном телефоне?

Когда в моем браузере или операционной системе появятся корневые сертификаты Google Trust Services?

Google активно сотрудничает со всеми третьими сторонами, которые поддерживают распространенные пакеты доверенных корневых сертификатов. Сюда относятся производители операционных систем, например Apple и Microsoft, внутренние подразделения Google по разработке Android и Chrome OS, производители браузеров Mozilla, Apple, Microsoft, внутреннее подразделение Google по разработке Chrome, а также производители различного оборудования, такого как мобильные телефоны, телеприставки, телевизоры, игровые консоли, принтеры и т. д.

Поскольку компания Google не в силах существенным образом повлиять на сроки включения сертификатов в списки, используемые третьими лицами, мы можем лишь порекомендовать регулярно применять все доступные обновления систем. Некоторые организации, как, например, Mozilla в рамках программы сертификатов ЦС, уже опубликовали собственные графики включения новых сертификатов.

Устранение неполадок

Где можно найти нужные мне инструменты?

Как получить curl

Если в вашем дистрибутиве ОС нет инструмента curl, его можно скачать по адресу https://curl.haxx.se/. Вы можете скачать исходный код и самостоятельно скомпилировать этот инструмент или скачать готовый исполняемый файл, если он доступен для вашей платформы.

Как получить OpenSSL

Если в вашем дистрибутиве ОС нет инструмента openssl, вы можете скачать исходный код со страницы https://www.openssl.org/ и скомпилировать его. На странице https://www.openssl.org/community/binaries.html есть список исполняемых файлов, скомпилированных третьими сторонами. Но помните, что ни одна из этих сборок не поддерживается разработчиками OpenSSL и не рекомендуется ими к использованию.

Как получить Wireshark и tcpdump

В большинстве дистрибутивов Linux эти инструменты уже есть, но для других ОС вы можете получить скомпилированные версии wireshark на сайте https://www.wireshark.org. Исходный код для tcpdump и LibPCAP можно получить на сайте https://www.tcpdump.org.

Как получить Java keytool

Инструмент командной строки keytool обычно включается во все версии пакетов Java Development Kit (JDK) и среды Java Runtime Environment (JRE). Установите их, чтобы получить keytool.. Впрочем, keytool обычно не требуется для проверки корневых сертификатов, если ваше приложение не разработано на основе Java.

Что делать в случае прерывания работы приложения?

Основным решением в этой ситуации будет установка необходимых сертификатов из образца PEM-файла от Google в используемое вашим приложением хранилище доверенных сертификатов. Некоторые полезные сведения мы собрали в разделе Управление доверенными сертификатами.
  1. Обратитесь к системному администратору, чтобы обновить локальное хранилище сертификатов.
  2. Ознакомьтесь с рекомендациями в этой статье, которые подходят для вашей системы.
  3. Если вам потребуется дополнительная поддержка по конкретной платформе или системе, обратитесь к поставщику этой системы.
  4. Чтобы получить поддержку общего характера, обратитесь в нашу службу поддержки.
  5. Чтобы быть в курсе новостей о переходе, пометьте для отслеживания общедоступную страницу проблемы 67842936.

Обращение в службу поддержки платформы Google Карт

Первоначальный поиск и устранение неполадок

Базовые рекомендации по устранению неполадок приведены в ответе на вопрос Как узнать, нужно ли обновлять хранилище сертификатов?

Если вам нужно экспортировать или импортировать корневые сертификаты, вы можете найти полезную информацию в разделе Управление доверенными сертификатами.

Если самостоятельно проблему решить не удастся, при обращении в службу поддержки платформы Google Карт будьте готовы ответить на следующие вопросы:

  1. Где расположены проблемные серверы?
  2. К каким IP-адресам Google обращается ваш сервис?
  3. На какие API распространяется проблема?
  4. Когда точно началась эта проблема?
  5. Выходные данные следующих команд:
    # Google Maps Platform service
    $ curl -vvI https://maps.googleapis.com/
    # Google Search site
    $ curl -vvI https://www.google.com/
    # Google certificate test sandbox
    $ curl -vvI https://cert-test.sandbox.google.com/
    # GS Root R2
    $ curl -vvI https://good.gsr2demo.pki.goog/
    # GS Root R3
    $ curl -vvI https://valid.r3.roots.globalsign.com/
    # GTS Root R1
    $ curl -vvI https://good.r1demo.pki.goog/
    $ openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null 2>/dev/null
    $ openssl s_client -connect cert-test.sandbox.google.com:443 -showcerts </dev/null 2>/dev/null
    

Инструкции по получению необходимых инструментов приведены в ответе на вопрос Где можно найти нужные мне инструменты?

Как определить общедоступный адрес моего DNS-сервера?

В среде Linux для этого можно выполнить следующую команду:
dig -t txt o-o.myaddr.l.google.com
В среде Windows можно использовать nslookup в интерактивном режиме:
C:\> nslookup -
set type=TXT
o-o.myaddr.l.google.com

Как правильно анализировать выходные данные curl и гарантировать надежность результатов?

Выполнение curl с параметрами -vvI предоставит вам много полезной информации. Ниже приводятся некоторые рекомендации по анализу этих результатов.
  • Строки, в начале которых стоит *, отображают выходные данные рукопожатия TLS и сведения о завершении подключения.
  • Строки, в начале которых стоит >, отображают исходящие HTTP-запросы от curl.
  • Строки, в начале которых стоит <, отображают полученный HTTP-ответ от сервера.
  • Если использовался протокол HTTPS, наличие строки > или < означает успешное рукопожатие TLS.
Использованная библиотека TLS и пакет корневых сертификатов

Выполнение curl с параметрами -vvI также выводит сведения об использованном хранилище сертификатов, но точные выходные данные зависят системы, как показано ниже.

Выходные данные на компьютере под управлением Red Hat Linux, где инструмент curl связан с NSS, будут содержать такие строки:

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

Выходные данные на компьютере под управлением Ubuntu или Debian Linux будут содержать такие строки:

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

Выходные данные на компьютере под управлением Ubuntu или Debian Linux, где используется предоставленный Google PEM-файл корневых сертификатов, при указании параметра запуска --cacert будут содержать такие строки:

* successfully set certificate verify locations:
* CAfile: /home/<username>/Downloads/roots.pem
  CApath: /etc/ssl/certs
Агент пользователя

Исходящие запросы содержат заголовок User-Agent (Агент пользователя), который может предоставить полезные сведения о curl и системе в целом.

Вот пример с компьютера под управлением 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 libssh2/1.4.2
> Host: cert-test.sandbox.google.com
> Accept: */*
>
Сбой при рукопожатии TLS
Приведенные ниже строки и подобные им означают обрыв подключения в процессе рукопожатия TLS из-за отсутствия доверия сертификату сервера. Отсутствие в выходных данных строк, которые начинаются с > или <, также служит важным признаком неудачной попытки подключения:
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
Успешное рукопожатие TLS
Успешное рукопожатие TLS определяется по наличию строк, похожих на приведенные ниже. В них должен быть указан набор шифров, используемый для зашифрованного подключения, а также подробные сведения о принятом сертификате сервера. Более того, наличие строк, которые начинаются с > или <, означает успешную передачу полезного трафика HTTP через зашифрованное TLS-подключение:
* 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=*.googleapis.com
*  start date: Jul 29 17:24:40 2019 GMT
*  expire date: Oct 27 17:24:40 2019 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.
> HEAD / HTTP/1.1
> User-Agent: curl/7.64.0
> Host: maps.googleapis.com
> Accept: */*
>
< HTTP/1.1 302 Found
Как распечатать полученные сертификаты сервера в понятной для человека форме?
Если результаты возвращаются в формате PEM, как, например, выходные данные openssl s_client ... -showcerts, то вы можете распечатать сертификаты следующим образом:
  1. Полностью скопируйте закодированный в Base 64 сертификат, включая заголовок и нижний колонтитул:
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
    
  2. openssl x509 -inform pem -noout -text
    
  3. Вставьте содержимое буфера обмена в окно терминала.
  4. Нажмите клавишу ВВОД.
Пример входных и выходных данных приведен в разделе Как распечатать сертификаты PEM в понятной для человека форме?.

Как выглядят сертификаты Google в OpenSSL?

Новый сертификат, привязанный к корневому сертификату GlobalSign Root CA - R2

Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.googleapis.com
   i:C = US, O = Google Trust Services, CN = GTS CA 1O1
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:C = US, O = Google Trust Services, CN = GTS CA 1O1
   i:OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.googleapis.com

issuer=C = US, O = Google Trust Services, CN = GTS CA 1O1

Управление доверенными сертификатами

Как проверить доверенные корневые сертификаты на мобильном телефоне?

Доверенные сертификаты Android

Как уже упоминалось в этом разделе, начиная с версии Android 4.0 пользователи мобильных телефонов могут проверять список доверенных сертификатов через меню Настройки. В таблице ниже приведены точные пути в меню Настройки для разных версий.

Версия Android Путь меню
1.x, 2.x, 3.x
4.x, 5.x, 6.x, 7.x Настройки > Безопасность > Надежные сертификаты
8.x, 9 Настройки > Защита и местоположение > Шифрование и учетные данные > Надежные сертификаты
10 Настройки > Безопасность > Дополнительно > Шифрование и учетные данные > Надежные сертификаты

Следующая таблица демонстрирует ожидаемую доступность наиболее важных корневых сертификатов в разных версиях Android на основе данных ручной проверки доступных на данный момент системных образов виртуальных устройств Android (AVD) или списка AOSP ca-certificates из истории версий в репозитории Git, если системные образы уже недоступны:

Версия Android GS Root R2 GS Root R3 GS Root R4 GTS
2.3, 3.2, 4.x, 5.0
5.1, 6.x, 7.x, 8.x, 9
10

Обновление хранилища сертификатов в системе Android обычно невозможно выполнить без обновления прошивки или настройки root-доступа. Однако текущий набор доверенных корневых сертификатов на большинстве используемых версий Android скорее всего будет обеспечивать бесперебойную работу сервиса ещё многие годы, намного дольше ожидаемого срока службы большинства современных устройств.

Начиная с версии 7.0 Android предлагает разработчикам приложений надежный метод для добавления доверенных сертификатов, которые будут доверенными только для их приложения. Это выполняется путем объединения сертификатов с приложением и создания пользовательской конфигурации сетевой безопасности, как описано в этом документе из рекомендаций Android по обеспечению безопасности и конфиденциальности

Однако поскольку сторонние разработчики приложений не могут изменять настройки сетевой безопасности для трафика, исходящего из Google Play Services APK, такие действия обеспечат лишь частичное решение.

На более старых устройствах будет возможным только полагаться на добавленные пользователем центры сертификации, которые устанавливаются на устройства конечных пользователей корпоративными групповыми политиками или самими конечными пользователями.

Доверенное хранилище iOS

Компания Apple не демонстрирует набор доверенных корневых сертификатов пользователям мобильных устройств, но предоставляет ссылки на наборы доверенных корневых ЦС для всех версий iOS начиная с 5 в статьях службы поддержки Apple Списки доступных доверенных корневых сертификатов в ОС iOS и ОС iOS 5 и 6: список доступных доверенных корневых сертификатов.

Любые установленные дополнительные сертификаты на устройстве iOS должны быть видны в разделе Settings (Настройки) > General (Общие) > Profile (Профиль). Если дополнительных сертификатов нет, пункт меню Profile (Профиль) может не отображаться.

В таблице ниже приведены сведения о доступности самых важных корневых сертификатов для версий iOS на основе указанных выше источников:

Версия iOS GS Root R2 GS Root R3 GS Root R4 GTS
5, 6
7, 8, 9, 10, 11, 12.0
12.1.3+

Где находится системное хранилище сертификатов и как его обновить?

Расположение хранилища сертификатов по умолчанию зависит от операционной системы и используемой библиотеки SSL/TLS. Впрочем, на большинстве дистрибутивов Linux стандартные корневые сертификаты размещаются по одному из следующих путей: /usr/local/share/ca-certificates (Debian, Ubuntu, старые версии RHEL и CentOS), /etc/pki/ca-trust/source/anchors и /usr/share/pki/ca-trust-source (Fedora, новые версии RHEL и CentOS) или /var/lib/ca-certificates (OpenSUSE). Могут использоваться и такие пути к сертификатам: /etc/ssl/certs (Debian, Ubuntu) или /etc/pki/tls/certs (RHEL, CentOS). Некоторые сертификаты в этих каталогах, скорее всего, будут символическими ссылками на файлы в других каталогах.

OpenSSL

Для приложений, которые используют OpenSSL, можно проверить заданное расположение установленных компонентов, включая хранилище сертификатов по умолчанию, с помощью следующей команды:
openssl version -d
Эта команда распечатывает OPENSSLDIR, то есть каталог высшего уровня, в котором следует искать библиотеку и её настройки:
OPENSSLDIR: "/usr/lib/ssl"
Хранилище сертификатов расположено в подкаталоге certs.
$ ls -l /usr/lib/ssl/certs
lrwxrwxrwx 1 root root 14 Feb 13  2017 /usr/lib/ssl/certs -> /etc/ssl/certs
$ ls -l /etc/ssl/certs
…
-rw-r--r-- 1 root root 212177 Sep  5 00:45 ca-certificates.crt
…
lrwxrwxrwx 1 root root     62 Sep  5 00:39 GlobalSign_Root_CA_-_R2.pem -> /usr/share/ca-certificates/mozilla/GlobalSign_Root_CA_-_R2.crt
…

Если OpenSSL использует стандартное системное хранилище сертификатов, выполните инструкции из первого абзаца этого раздела выше, чтобы проверить актуальность пакета корневых сертификатов в системном хранилище.

Инструкции по получению openssl приведены в этом разделе.

Mozilla NSS

Приложения, использующие Mozilla NSS, также могут по умолчанию использовать системную базу сертификатов, которая обычно размещается в каталоге /etc/pki/nssdb или хранилище по умолчанию для конкретного пользователя (${HOME}/.pki/nssdb). Чтобы обновить NSS, изучите документацию по инструменту certutil, в которой объясняется, как добавить новые сертификаты, а также официальную документацию по используемой ОС.

Microsoft .NET

Разработчики Windows .NET могут найти полезную информацию по обновлению хранилищ сертификатов в следующих статьях Microsoft:

Java

Приложения Java могут использовать собственное хранилище сертификатов, которое в системах Linux обычно расположено в каталоге /etc/pki/java/cacerts или /usr/share/ca-certificates-java. Следующие статьи с сайтов Stack Overflow и Oracle помогут вам обновить хранилище сертификатов для Java с помощью инструмента командной строки Oracle keytool:

Что такое PEM-файл?

Формат Privacy-Enhanced Mail (PEM) является стандартом де-факто для хранения и передачи криптографических сертификатов, ключей и т. п., который закреплен де-юре в документе RFC 7468.

Этот формат легко воспринимается человеком, в отличие от кодировки Base64. Также спецификация PEM допускает размещение пояснительного текста перед основным содержимым сертификата в текстовой кодировке или после него, и многие инструменты используют эту возможность для предоставления сводной информации о самых важных элементах сертификата в формате простого текста.

Такие инструменты, как openssl, могут также использоваться для декодирования сертификата в читаемый человеком формат. Более подробная информация содержится в разделе Как распечатать сертификаты PEM в понятной для человека форме?

Что такое файл с расширением .crt?

Инструменты, которые позволяют экспортировать сертификаты в формат PEM, обычно используют расширение файла .crt, чтобы указать на текстовое кодирование файла.

Что такое DER-файл?

Distinguished Encoding Rules (DER) представляет собой стандартизированный двоичный формат для кодирования сертификатов. Сертификаты в PEM-файлах обычно являются сертификатами DER, закодированными по стандарту Base64.

Что такое файл с расширением .cer?

Экспортированный файл с расширением .cer может содержать сертификат в кодировке PEM, но обычно это будет двоичный сертификат, чаще всего в кодировке DER. По конвенции файлы с расширением .cer обычно содержат только один сертификат.

Не удается импортировать все сертификаты из roots.pem в мою систему

Некоторые системы принимают к импорту только PEM-файлы, которые содержат один сертификат. См. ниже ответ на вопрос Как извлечь отдельные сертификаты из roots.pem?, чтобы узнать, как разделить этот файл.

Как извлечь отдельные сертификаты из roots.pem?

Вы можете разделить roots.pem на отдельные сертификаты с помощью следующего скрипта Bash:
csplit -z -f roots.pem. roots.pem '/-----END CERTIFICATE-----/+1' '{*}' &>/dev/null &&\
for f in roots.pem.*;\
  do mv "${f}"\
    $(printf %b $(openssl x509 -in ${f} -noout -issuer|sed -e 's/"//g'|sed -e 's#/#_#g')).pem;\
done
В результате будет создано несколько отдельных PEM-файлов, таких как приведенные ниже:
issuer=C=BE,O=GlobalSignnv-sa,OU=RootCA,CN=GlobalSignRootCA.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=ComodoCALimited,CN=AAACertificateServices.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODOCertificationAuthority.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODOECCCertificationAuthority.pem
issuer=C=GB,ST=GreaterManchester,L=Salford,O=COMODOCALimited,CN=COMODORSACertificationAuthority.pem
issuer=C=IE,O=Baltimore,OU=CyberTrust,CN=BaltimoreCyberTrustRoot.pem
issuer=C=SE,O=AddTrustAB,OU=AddTrustExternalTTPNetwork,CN=AddTrustExternalCARoot.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustCommercial.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustNetworking.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustPremiumECC.pem
issuer=C=US,O=AffirmTrust,CN=AffirmTrustPremium.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootG2.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertAssuredIDRootG3.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootG2.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertGlobalRootG3.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertHighAssuranceEVRootCA.pem
issuer=C=US,O=DigiCertInc,OU=www.digicert.com,CN=DigiCertTrustedRootG4.pem
issuer=C=US,O=Entrust,Inc.,OU=Seewww.entrust.net_legal-terms,OU=(c)2009Entrust,Inc.-forauthorizeduseonly,CN=EntrustRootCertificationAuthority-G2.pem
issuer=C=US,O=Entrust,Inc.,OU=Seewww.entrust.net_legal-terms,OU=(c)2012Entrust,Inc.-forauthorizeduseonly,CN=EntrustRootCertificationAuthority-EC1.pem
issuer=C=US,O=Entrust,Inc.,OU=www.entrust.net_CPSisincorporatedbyreference,OU=(c)2006Entrust,Inc.,CN=EntrustRootCertificationAuthority.pem
issuer=C=US,O=GeoTrustInc.,CN=GeoTrustGlobalCA.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR1.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR2.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR3.pem
issuer=C=US,O=GoogleTrustServicesLLC,CN=GTSRootR4.pem
issuer=C=US,O=StarfieldTechnologies,Inc.,OU=StarfieldClass2CertificationAuthority.pem
issuer=C=US,O=TheGoDaddyGroup,Inc.,OU=GoDaddyClass2CertificationAuthority.pem
issuer=C=US,ST=Arizona,L=Scottsdale,O=GoDaddy.com,Inc.,CN=GoDaddyRootCertificateAuthority-G2.pem
issuer=C=US,ST=Arizona,L=Scottsdale,O=StarfieldTechnologies,Inc.,CN=StarfieldRootCertificateAuthority-G2.pem
issuer=C=US,ST=NewJersey,L=JerseyCity,O=TheUSERTRUSTNetwork,CN=USERTrustECCCertificationAuthority.pem
issuer=C=US,ST=NewJersey,L=JerseyCity,O=TheUSERTRUSTNetwork,CN=USERTrustRSACertificationAuthority.pem
issuer=O=Cybertrust,Inc,CN=CybertrustGlobalRoot.pem
issuer=O=Entrust.net,OU=www.entrust.net_CPS_2048incorp.byref.(limitsliab.),OU=(c)1999Entrust.netLimited,CN=Entrust.netCertificationAuthority(2048).pem
issuer=OU=GlobalSignECCRootCA-R4,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignECCRootCA-R5,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R2,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R3,O=GlobalSign,CN=GlobalSign.pem
issuer=OU=GlobalSignRootCA-R6,O=GlobalSign,CN=GlobalSign.pem
roots.pem
Затем PEM-файлы issuer=….pem можно импортировать по отдельности или преобразовать в другой формат файла, который принимается вашим хранилищем сертификатов.

Как преобразовать PEM-файл в формат, поддерживаемый моей системой, и обратно?

Для преобразования файлов в любой распространенный формат файла сертификатов можно использовать инструмент командной строки openssl из набора средств OpenSSL. Инструкции по такому преобразованию приведены ниже.

Полный список доступных вариантов есть в официальной документации по утилитам командной строки OpenSSL.

Инструкции по получению openssl приведены в этом разделе.

Как преобразовать PEM-файл в DER-файл?

При использовании openssl вы можете выполнить следующую команду для преобразования файла из формата PEM в формат DER:
openssl x509 -in roots.pem -outform der -out roots.der

Как преобразовать PEM-файл в PKCS #7?

При использовании openssl вы можете выполнить следующую команду для преобразования файла из формата PEM в формат PKCS #7:
openssl crl2pkcs7 -nocrl -certfile roots.pem -out roots.p7b

Как преобразовать PEM-файл в PKCS #12 (PFX)?

При использовании openssl вы можете выполнить следующую команду для преобразования файла из формата PEM в формат PKCS #12:
openssl pkcs12 -export -info -in roots.pem -out roots.p12 -nokeys

При создании архива PKCS #12 вам нужно предоставить пароль к файлу. Если вы не можете немедленно импортировать файл PKCS #12 в систему, сохраните этот пароль в надежном месте.

Как экспортировать сертификаты из хранилища сертификатов NSS в формате PEM-файла?

Изучите документацию по инструменту certutil Mozilla NSS, а также обсуждение на сайте сообщества Red Hat об экспорте сертификата из cert8.db в формате файла .pem.

Как распечатать сертификаты PEM в понятной для человека форме?

В следующих примерах предполагается, что у вас есть файл GlobalSign_Root_CA_-_R2.pem со следующим содержимым:
-----BEGIN CERTIFICATE-----
MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G
A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp
Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1
MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG
A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL
v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8
eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq
tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd
C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa
zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB
mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH
V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n
bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG
3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs
J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO
291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS
ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd
AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7
TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg==
-----END CERTIFICATE-----

Печать сертификатов с помощью OpenSSL

Выполнение команды
openssl x509 -in GlobalSign_Root_CA_-_R2.pem -text
должно возвращать следующие строки перед сертификатом:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:00:00:00:00:01:0f:86:26:e6:0d
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
        Validity
            Not Before: Dec 15 08:00:00 2006 GMT
            Not After : Dec 15 08:00:00 2021 GMT
        Subject: OU=GlobalSign Root CA - R2, O=GlobalSign, CN=GlobalSign
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:a6:cf:24:0e:be:2e:6f:28:99:45:42:c4:ab:3e:
                    21:54:9b:0b:d3:7f:84:70:fa:12:b3:cb:bf:87:5f:
                    c6:7f:86:d3:b2:30:5c:d6:fd:ad:f1:7b:dc:e5:f8:
                    60:96:09:92:10:f5:d0:53:de:fb:7b:7e:73:88:ac:
                    52:88:7b:4a:a6:ca:49:a6:5e:a8:a7:8c:5a:11:bc:
                    7a:82:eb:be:8c:e9:b3:ac:96:25:07:97:4a:99:2a:
                    07:2f:b4:1e:77:bf:8a:0f:b5:02:7c:1b:96:b8:c5:
                    b9:3a:2c:bc:d6:12:b9:eb:59:7d:e2:d0:06:86:5f:
                    5e:49:6a:b5:39:5e:88:34:ec:bc:78:0c:08:98:84:
                    6c:a8:cd:4b:b4:a0:7d:0c:79:4d:f0:b8:2d:cb:21:
                    ca:d5:6c:5b:7d:e1:a0:29:84:a1:f9:d3:94:49:cb:
                    24:62:91:20:bc:dd:0b:d5:d9:cc:f9:ea:27:0a:2b:
                    73:91:c6:9d:1b:ac:c8:cb:e8:e0:a0:f4:2f:90:8b:
                    4d:fb:b0:36:1b:f6:19:7a:85:e0:6d:f2:61:13:88:
                    5c:9f:e0:93:0a:51:97:8a:5a:ce:af:ab:d5:f7:aa:
                    09:aa:60:bd:dc:d9:5f:df:72:a9:60:13:5e:00:01:
                    c9:4a:fa:3f:a4:ea:07:03:21:02:8e:82:ca:03:c2:
                    9b:8f
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier:
                9B:E2:07:57:67:1C:1E:C0:6A:06:DE:59:B4:9A:2D:DF:DC:19:86:2E
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.globalsign.net/root-r2.crl

            X509v3 Authority Key Identifier:
                keyid:9B:E2:07:57:67:1C:1E:C0:6A:06:DE:59:B4:9A:2D:DF:DC:19:86:2E

    Signature Algorithm: sha1WithRSAEncryption
         99:81:53:87:1c:68:97:86:91:ec:e0:4a:b8:44:0b:ab:81:ac:
         27:4f:d6:c1:b8:1c:43:78:b3:0c:9a:fc:ea:2c:3c:6e:61:1b:
         4d:4b:29:f5:9f:05:1d:26:c1:b8:e9:83:00:62:45:b6:a9:08:
         93:b9:a9:33:4b:18:9a:c2:f8:87:88:4e:db:dd:71:34:1a:c1:
         54:da:46:3f:e0:d3:2a:ab:6d:54:22:f5:3a:62:cd:20:6f:ba:
         29:89:d7:dd:91:ee:d3:5c:a2:3e:a1:5b:41:f5:df:e5:64:43:
         2d:e9:d5:39:ab:d2:a2:df:b7:8b:d0:c0:80:19:1c:45:c0:2d:
         8c:e8:f8:2d:a4:74:56:49:c5:05:b5:4f:15:de:6e:44:78:39:
         87:a8:7e:bb:f3:79:18:91:bb:f4:6f:9d:c1:f0:8c:35:8c:5d:
         01:fb:c3:6d:b9:ef:44:6d:79:46:31:7e:0a:fe:a9:82:c1:ff:
         ef:ab:6e:20:c4:50:c9:5f:9d:4d:9b:17:8c:0c:e5:01:c9:a0:
         41:6a:73:53:fa:a5:50:b4:6e:25:0f:fb:4c:18:f4:fd:52:d9:
         8e:69:b1:e8:11:0f:de:88:d8:fb:1d:49:f7:aa:de:95:cf:20:
         78:c2:60:12:db:25:40:8c:6a:fc:7e:42:38:40:64:12:f7:9e:
         81:e1:93:2e

Инструкции по получению openssl приведены в этом разделе.

Печать сертификатов с помощью Java keytool

Выполнение команды
keytool -printcert -file GlobalSign_Root_CA_-_R2.pem
должно возвращать следующие выходные данные:
Owner: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Issuer:
CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Serial number:
400000000010f8626e60d
Valid from: Fri Dec 15 09:00:00 CET 2006 until: Wed Dec 15
09:00:00 CET 2021
Certificate fingerprints:
   MD5:
94:14:77:7E:3E:5E:FD:8F:30:BD:41:B0:CF:E7:D0:30
   SHA1:
75:E0:AB:B6:13:85:12:27:1C:04:F8:5F:DD:DE:38:E4:B7:24:2E:FE
   SHA256:
CA:42:DD:41:74:5F:D0:B8:1E:B9:02:36:2C:F9:D8:BF:71:9D:A1:BD:1B:1E:FC:94:6F:5B:4C:99:F4:2C:1B:9E
   Signature algorithm name: SHA1withRSA
   Version: 3

Extensions:

#1:
ObjectId: 2.5.29.35 Criticality=false
AuthorityKeyIdentifier [
KeyIdentifier [
0000: 9B E2 07 57 67 1C 1E C0   6A 06 DE 59 B4 9A 2D DF  ...Wg...j..Y..-.
0010:
DC 19 86 2E                                        ....
]
]

#2: ObjectId:
2.5.29.19 Criticality=true
BasicConstraints:[
  CA:true
  PathLen:2147483647
]
#3: ObjectId: 2.5.29.31 Criticality=false
CRLDistributionPoints [
[DistributionPoint:
     [URIName: http://crl.globalsign.net/root-r2.crl]
]]
#4: ObjectId: 2.5.29.15 Criticality=true
KeyUsage [
  Key_CertSign
  Crl_Sign
]
#5: ObjectId: 2.5.29.14 Criticality=false
SubjectKeyIdentifier [
KeyIdentifier [
0000: 9B E2 07 57 67 1C 1E C0   6A 06 DE 59 B4 9A 2D DF  ...Wg...j..Y..-.
0010:
DC 19 86 2E                                        ....
]
]

Инструкции по получению keytool приведены в этом разделе.

Как узнать, какие сертификаты установлены в моем хранилище сертификатов?

Это зависит от операционной системы и используемой библиотеки SSL/TLS. Однако инструменты, которые используются для импорта и экспорта сертификатов в хранилище и обратно, обычно также предоставляют возможность вывести список установленных сертификатов.

Кроме того, если вы успешно экспортировали доверенные корневые сертификаты в PEM-файлы или в вашем хранилище сертификатов уже есть сохраненные PEM-файлы, вы можете попробовать открыть эти файлы в любом текстовом редакторе, поскольку это файлы в формате обычного текста.

В PEM-файл можно добавить удобочитаемые метки с информацией о центре сертификации (пример из образца PEM-файла от Google):

# Operating CA: GlobalSign
# Issuer: CN=GlobalSign O=GlobalSign OU=GlobalSign Root CA - R2
# Subject: CN=GlobalSign O=GlobalSign OU=GlobalSign Root CA - R2
# Label: "GlobalSign Root CA - R2"
# Serial: 4835703278459682885658125
# MD5 Fingerprint: 94:14:77:7e:3e:5e:fd:8f:30:bd:41:b0:cf:e7:d0:30
# SHA1 Fingerprint: 75:e0:ab:b6:13:85:12:27:1c:04:f8:5f:dd:de:38:e4:b7:24:2e:fe
# SHA256 Fingerprint: ca:42:dd:41:74:5f:d0:b8:1e:b9:02:36:2c:f9:d8:bf:71:9d:a1:bd:1b:1e:fc:94:6f:5b:4c:99:f4:2c:1b:9e
-----BEGIN CERTIFICATE-----
MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G
A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp
Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1
MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG
A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL
v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8
eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq
tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd
C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa
zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB
mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH
V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n
bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG
3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs
J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO
291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS
ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd
AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7
TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg==
-----END CERTIFICATE-----

Этот файл также может содержать только сертификат. В таких случаях центр сертификации, выдавший этот сертификат, может быть указан в названии этого файла, например GlobalSign_Root_CA_-_R2.pem. Строка сертификата между токенами -----BEGIN CERTIFICATE----- и -----END CERTIFICATE----- гарантировано уникальна для каждого ЦС, и вы можете сравнивать эти строки в разных PEM-файлах, если невозможно иным способом определить ЦС.

Например, вы можете сравнить каждый из сертификатов в образце PEM-файла от Google с содержимым PEM-файлов из вашего хранилища сертификатов. Поскольку в пакете корневых ЦС Google все сертификаты имеют понятные метки, вы сможете надежно определить, какие из сертификатов уже есть в вашем хранилище сертификатов, а какие нужно в него добавить, даже если в PEM-файлах из вашего хранилища нет таких меток.

Инструкции для мобильных телефонов приведены в ответе на вопрос Как проверить доверенные корневые сертификаты на мобильном телефоне?

Приложение

Нужна дополнительная информация?

В первую очередь обратитесь к документации по операционной системе, по используемому в приложении языку (или языкам) программирования, а также по любым внешним библиотекам.

Любые другие источники информации, включая эту статью, могут содержать устаревшую или некорректную информацию и не должны восприниматься как истина в последней инстанции. Среди прочего, вы также можете найти полезную информацию во многих сообществах вопросов и ответов на Stack Exchange, на сайте AdamW, посвященном Linux, в блоге confirm и на других сайтах. Изучите статью с вопросами и ответами по GTS, а также статью об использовании сертификатов X.509 и SSL для защищенного обмена данными.

Более подробная информация по сложным темам, таким как закрепление сертификатов, содержится в этой статье по проекту обеспечения безопасности веб-приложений (OWASP – Open Web Application Security Project) и в краткой памятке. Инструкции для Android можно найти в обучающем документе с рекомендациями по безопасности и конфиденциальности для Android Security with HTTPS and SSL (Обеспечение безопасности с помощью HTTPS и SSL). Сравнительное обсуждение методов закрепления сертификатов и открытых ключей в системе Android есть в записи блога Мэтью Долана Android Security: SSL Pinning (Безопасность в Android: закрепление для SSL).

В обучающем документе с рекомендациями по безопасности и конфиденциальности для Android Network Security Configuration (Конфигурация безопасности сети) и записи блога JeroenHD Android 7 Nougat and certificate authorities (Android 7 Nougat и центры сертификации) вы можете найти подробную информацию об управлении дополнительными доверенными сертификатами в системе Android.

Полный список доверенных центров сертификации AOSP содержится в репозитории Git ca-certificates. Любые версии для неофициальных ответвлений Android, таких как LineageOS, можно найти в соответствующих репозиториях, поддерживаемых поставщиками этих ОС.