Эта страница переведена с помощью Cloud Translation API.

Часто задаваемые вопросы о переносе корневого ЦС платформы Google Карт

Этот документ содержит следующие разделы:

Терминология
Общая информация
Поиск неисправностей
Управление доверенными сертификатами
Приложение

Более подробный обзор текущей миграции корневого ЦС Google см. в разделе Что происходит? .

Терминология

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

SSL/TLS-сертификат: Сертификат связывает криптографический ключ с удостоверением.; Сертификаты SSL/TLS используются для аутентификации и установки безопасных подключений к веб-сайтам. Сертификаты выдаются и криптографически подписываются организациями, известными как центры сертификации.; Браузеры полагаются на сертификаты, выданные доверенными центрами сертификации, чтобы знать, что передаваемая информация отправляется на правильный сервер и что она шифруется во время передачи.
Уровень защищенных сокетов (SSL): Secure Sockets Layer был наиболее широко используемым протоколом для шифрования интернет-коммуникаций. Протокол SSL больше не считается безопасным и не должен использоваться.
Безопасность транспортного уровня (TLS): Безопасность транспортного уровня является преемником SSL.
Центр сертификации (ЦС): Центр сертификации похож на офис цифрового паспорта для устройств и людей. Он выдает криптографически защищенные документы (сертификаты), подтверждающие, что объект (например, веб-сайт) является тем, за кого себя выдает.; Перед выдачей сертификата центры сертификации несут ответственность за проверку того, что имена в сертификате связаны с лицом или организацией, запрашивающим его.; Термин Центр сертификации может относиться как к организациям, таким как Google Trust Services, так и к системам, выдающим сертификаты.
Хранилище корневых сертификатов: Хранилище корневых сертификатов содержит набор центров сертификации, которым доверяет поставщик прикладного программного обеспечения. Большинство веб-браузеров и операционных систем имеют собственное хранилище корневых сертификатов.; Чтобы быть включенным в хранилище корневых сертификатов, центр сертификации должен соответствовать строгим требованиям, установленным поставщиком прикладного программного обеспечения.; Обычно они включают соответствие отраслевым стандартам, таким как требования CA/Browser Forum.
Корневой центр сертификации: Корневой центр сертификации (или, точнее, его сертификат) — это самый верхний сертификат в цепочке сертификатов.; Сертификаты корневого ЦС обычно являются самоподписанными. Закрытые ключи, связанные с ними, хранятся в высокозащищенных хранилищах и поддерживаются в автономном режиме для защиты от несанкционированного доступа.
Промежуточный центр сертификации: Промежуточный центр сертификации (или, точнее, его сертификат) — это сертификат, который используется для подписи других сертификатов в цепочке сертификатов.; Промежуточные центры сертификации в основном существуют для обеспечения выдачи онлайн-сертификатов, в то время как сертификат корневого центра сертификации остается в автономном режиме.; Промежуточные центры сертификации также известны как подчиненные центры сертификации.
Выдающий центр сертификации: Выдающий центр сертификации или, точнее, его сертификат — это сертификат, который используется для подписи самого нижнего сертификата в цепочке сертификатов.; Этот самый нижний сертификат обычно называют сертификатом подписчика, сертификатом конечного объекта или конечным сертификатом. В этом документе мы также будем использовать термин сертификат сервера .
Цепочка сертификатов: Сертификаты связаны (криптографически подписаны) с их эмитентом. Цепочка сертификатов состоит из листового сертификата, всех его сертификатов эмитента и корневого сертификата.
Перекрестная подпись: Клиенты поставщиков прикладного программного обеспечения должны обновить свои корневые хранилища сертификатов, включив в них новые сертификаты ЦС, чтобы их продукты могли доверять им. Потребуется некоторое время, прежде чем продукты, содержащие новые сертификаты ЦС, получат широкое распространение.; Для повышения совместимости со старыми клиентами сертификаты ЦС могут быть «перекрестно подписаны» другим старым установленным ЦС. Это эффективно создает второй сертификат ЦС для той же личности (имя и пара ключей).; В зависимости от ЦС, включенных в их корневое хранилище сертификатов, клиенты будут создавать разные цепочки сертификатов до корня, которому они доверяют.

Общая информация

Что происходит?

Ключевой момент: в 2021 году Google продолжит многолетний переход к собственному корневому центру сертификации (CA) Google Trust Services (GTS) , начатый в 2017 году. Корневой центр сертификации используется для проверки безопасности всех TLS-подключений к Google. Платформа карт. Подавляющее большинство клиентов это изменение не затронет, но владельцам некоторых приложений, особенно тем, которые не предприняли никаких действий в 2017 году, может потребоваться обновить свои службы, чтобы обеспечить плавный переход на оставшуюся часть миграции, следуя рекомендациям. в этом документе.

Большая картина

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

После первого этапа безопасность TLS служб платформы Google Maps была гарантирована GS Root R2, очень известным и пользующимся большим доверием корневым центром сертификации (CA), который Google приобрел у GMO GlobalSign, чтобы упростить переход на собственную выпустили корневые центры сертификации Google Trust Services (GTS).

Практически все клиенты TLS (например, веб-браузеры, смартфоны и серверы приложений) доверяют этому корневому сертификату и поэтому могут установить безопасное соединение с серверами платформы Google Maps на первом этапе миграции.

Однако ЦС может по своей конструкции не выдавать сертификаты, действительные после истечения срока действия его собственного сертификата. Поскольку срок действия GS Root R2 истекает 15 декабря 2021 г., Google перенесет свои собственные службы в новый ЦС, GTS Root R1 Cross , используя сертификат, выданный собственным корневым ЦС Google GTS Root R1 .

В то время как подавляющее большинство современных операционных систем и клиентских библиотек TLS уже доверяют корневым ЦС GTS, чтобы также обеспечить плавный переход для большинства устаревших систем, Google приобрел перекрестную подпись от GMO GlobalSign с использованием корневого ЦС GlobalSign — R1 , одного из самые старые и надежные корневые центры сертификации, доступные в настоящее время.

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

Это также относится к клиентам, которые приняли меры на первом этапе миграции в 2018 году, предполагая, что они в то время следовали нашим инструкциям, установив все сертификаты из нашего набора доверенных корневых центров сертификации Google .

Вы должны проверить свои системы, если применимо следующее:

ваши сервисы работают на нестандартных или устаревших платформах и/или вы поддерживаете собственное хранилище корневых сертификатов
вы не предпринимали никаких действий в 2017-2018 годах, на первом этапе миграции корневого ЦС Google, либо не установили полный набор сертификатов из комплекта доверенного корневого ЦС Google

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

Дополнительные технические подробности см. ниже. Общие инструкции см. в разделе Как проверить, нуждается ли мое хранилище корневых сертификатов в обновлении .

Мы также рекомендуем вам продолжать синхронизировать хранилища корневых сертификатов с указанным выше пакетом корневого ЦС, чтобы защитить ваши службы от будущих изменений корневого ЦС. Однако о них будет объявлено заранее. См. разделы Как получать обновления на этом этапе миграции? и Как я могу получить предварительное уведомление о будущих миграциях? для получения дальнейших инструкций о том, как быть в курсе.

Техническое резюме

Ключевой момент: GS Root R2 , корневой центр сертификации, на который в настоящее время опирается платформа Google Maps , истекает 15 декабря 2021 года . Поэтому наши сервисы должны перейти на сертификаты, выданные другим центром сертификации, GTS Root R1 Cross , и разработчики должны ожидать, что их клиенты платформы Google Maps будут проходить аутентификацию в этом ЦС в ближайшие годы. Чтобы сгладить этот переход, GTS Root R1 Cross имеет перекрестную подпись как собственного GTS Root R1 Google, так и GlobalSign Root CA - R1 .

Как было объявлено 15 марта 2021 г. в блоге безопасности Google , GS Root R2 , срок действия корневого центра сертификации Google Maps Platform, который использовался с начала 2018 года, истекает 15 декабря 2021 года. Поэтому в течение этого года Google перейдет на недавно выпущенный корневой сертификат CA GTS Root R1 . Крест . Это означает, что наши услуги будут постепенно переходить на листовые сертификаты TLS, выданные этим новым ЦС.

Почти все современные клиенты и системы TLS уже предварительно настроены с сертификатом GTS Root R1 или должны получать его через обычные обновления программного обеспечения, а GlobalSign Root CA — R1 должен быть доступен даже в более старых устаревших системах.

Однако вам следует проверить свои системы, по крайней мере , если применимы оба следующих пункта:

ваши сервисы работают на нестандартных или устаревших платформах и/или вы поддерживаете собственное хранилище корневых сертификатов
вы не предпринимали никаких действий в 2017-2018 годах, на первом этапе миграции корневого ЦС Google, либо не установили полный набор сертификатов из комплекта доверенного корневого ЦС Google

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

См. вопрос Почему мне следует синхронизировать хранилище корневых сертификатов с доверенным корневым центром сертификации Google? для получения полной информации.

Как получать обновления на этом этапе миграции?

Пометьте общедоступный выпуск 186840968 для получения обновлений. Этот FAQ также обновляется на протяжении всего процесса миграции всякий раз, когда мы сталкиваемся с темами, которые могут представлять общий интерес.

Как я могу получить предварительное уведомление о будущих миграциях?

Мы предлагаем вам подписаться на блог безопасности Google . Мы также постараемся как можно скорее обновить документацию по конкретному продукту после публикации в блоге.

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

Мы используем несколько сервисов Google. Повлияет ли миграция корневого центра сертификации на все из них?

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

См. вопросы Зачем мне синхронизировать хранилище корневых сертификатов с доверенным корневым центром сертификации Google? и Какие виды приложений подвержены риску взлома? для дальнейшего понимания.

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

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

Протестируйте среду своего приложения в соответствии с конечными точками тестирования, перечисленными ниже:

Если вы можете установить TLS-подключение к конечной точке кросс-теста GTS Root R1 , срок действия GS Root R2 не повлияет на вас.
Если вы сможете установить TLS-соединение с тестовой конечной точкой GTS Root R1 , ваше приложение, скорее всего, даже будет защищено от истечения срока действия GTS Root R1 Cross и GlobalSign Root CA — R1 в 2028 году.

Как правило, ваша система будет совместима с этим изменением корневого ЦС, если:

ваша служба работает в поддерживаемой основной операционной системе, и вы установили исправление для операционной системы и библиотек, используемых вашей службой, и вы не поддерживаете собственное хранилище корневых сертификатов, или:
вы следовали нашим предыдущим рекомендациям и установили все корневые центры сертификации из набора доверенных корневых центров сертификации Google.

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

Клиенты, которые могут быть затронуты, должны немедленно установить сертификаты из набора доверенных корневых ЦС Google , чтобы избежать перебоев в обслуживании в будущем.

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

Вы можете найти два инструмента командной строки curl и openssl полезными в своих исследованиях. Оба доступны на большинстве платформ и предлагают широкие возможности для тестирования вашей установки.

Инструкции по получению curl см. в разделе Получение curl ниже.

Команды openssl , показанные ниже, предназначены для версии 1.1.1 или более поздней. Версии до 1.1.1 больше не поддерживаются. Если вы используете более раннюю версию, обновите или измените эти команды в соответствии с вашей версией. Инструкции по получению openssl см. в разделе Получение OpenSSL ниже.

Вы также найдете дополнительные полезные инструменты в разделе Где я могу получить необходимые мне инструменты? ниже.

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

Тестирование хранилища корневых сертификатов по умолчанию

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;

Проверка набора доверенных корневых ЦС Google

Загрузите комплект надежного корневого ЦС Google и выполните следующие действия.

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;

Как и когда будет продолжена миграция корневого ЦС Google?

Первый этап (переход на GS Root R2), объявленный в январе 2017 г. , начался в конце 2017 г. и завершился в первой половине 2018 г.
Второй этап (переход на GTS Root R1 Cross) был объявлен в марте 2021 года и будет запущен в ближайшие месяцы, до истечения срока действия GS Root R2 15 декабря 2021 года.

Графики возможных более поздних этапов миграции будут объявлены задолго до истечения срока действия будущих сертификатов.

Однако вы сможете проверить свои приложения на будущее, если синхронизируете хранилище корневых сертификатов с тщательно подобранным списком корневых ЦС в наборе доверенных корневых ЦС Google .

См. также вопрос Почему мне следует синхронизировать хранилище корневых сертификатов с доверенным корневым центром сертификации Google? для дальнейшего фона.

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

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

Кого затронет, когда и где?

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

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

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

На что обращать внимание

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

В зависимости от конфигурации TLS клиенты могут продолжать отправлять запросы на платформу Google Maps или отказываться от них.

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

В сертификатах платформы Google Maps используются альтернативные имена субъекта DNS (SAN) , поэтому обработка сертификата клиента должна поддерживать SAN, которые могут включать один подстановочный знак в качестве крайней левой метки в имени, например *.googleapis.com .

Другие требования см. в разделе Каковы рекомендуемые требования для клиента TLS для связи с Google? в FAQ по ГТС .

Какие виды приложений подвержены риску взлома?

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

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

Если вы используете основную ОС, например Ubuntu, Red Hat, Windows 10 или Server 2019, OS X), которая все еще поддерживается и получает регулярные обновления, ваше хранилище корневых сертификатов по умолчанию уже должно включать корневой сертификат GTS Root R1 .

Если вы используете устаревшую версию ОС, которая больше не получает обновлений, у вас может быть сертификат GTS Root R1, а может и не быть. Однако ваше хранилище корневых сертификатов, скорее всего, будет содержать корневой ЦС GlobalSign — R1 , один из старейших и пользующихся наибольшим доверием корневых ЦС.

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

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

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

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

См. вопрос Подвержены ли мобильные приложения риску взлома? Больше подробностей.

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

Вам нужно будет обновить пакет сертификатов самостоятельно. Как обсуждалось в разделе «Почему мне следует синхронизировать хранилище корневых сертификатов с доверенным корневым центром сертификации Google?» , мы рекомендуем вам импортировать все сертификаты из набора доверенных корневых ЦС Google в собственное хранилище корневых сертификатов.

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

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

Зачем мне синхронизировать хранилище корневых сертификатов с доверенным корневым центром сертификации Google?

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

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

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

См. вопрос Как я могу получить предварительное уведомление о будущих миграциях? чтобы узнать, как получать обновления о будущих миграциях корневого центра сертификации. Регулярная синхронизация хранилища корневых сертификатов с курируемым списком защитит ваши службы от перебоев в работе в будущем из-за изменений в ЦС, а ваши службы будут работать после истечения срока действия как GTS Root R1 Cross , так и GlobalSign Root CA - R1 .

Также см. вопрос Я создаю продукт, который подключается к службам Google. Каким сертификатам CA мне нужно доверять? в часто задаваемых вопросах GTS для дальнейших рекомендаций.

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

Это может привести к поломке вашего приложения в любой момент, когда мы зарегистрируем новый сертификат или переключим промежуточные центры сертификации. Любое из этих событий может произойти в любое время и без предварительного уведомления, и это в равной степени относится к отдельным сертификатам серверов, например, к сертификатам, обслуживаемым maps.googleapis.com , а также к любому из наших промежуточных центров сертификации, таких как GTS Root R1 Cross .

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

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

Есть ли риск взлома приложений JavaScript?

Корневые сертификаты GTS уже хорошо встроены и пользуются доверием большинства современных браузеров, а перекрестная подпись от GMO GlobalSign должна обеспечить плавную миграцию даже для большинства конечных пользователей устаревших браузеров. Сюда входят все официально поддерживаемые браузеры для Maps JavaScript API.

Каждый современный браузер должен позволять конечным пользователям проверять и обычно редактировать сертификаты, которым доверяет браузер. Хотя точное расположение отличается в каждом браузере, список сертификатов обычно можно найти где-то в разделе «Настройки» .

Мобильные приложения могут сломаться?

Ожидается, что устройства Android и Apple iOS, которые по-прежнему получают регулярные обновления от производителя устройств, будут рассчитаны на будущее. Большинство старых моделей телефонов Android включают как минимум сертификат GlobalSign Root CA — R1 , хотя список доверенных сертификатов может различаться в зависимости от производителя телефона, модели устройства и версии Android.

Однако поддержка корневых центров сертификации GTS, включая GTS Root R1, может быть ограничена в версиях Android до 10.

Для устройств iOS Apple ведет список доверенных корневых центров сертификации для каждой последней версии iOS на своих страницах поддержки. Однако все версии iOS 5 и выше поддерживают GlobalSign Root CA — R1 .

Корневые ЦС GTS, включая корневой GTS R1, поддерживаются, начиная с версии iOS 12.1.3.

См. вопрос Как я могу проверить доверенные корневые сертификаты на своем мобильном телефоне? для получения дополнительной информации.

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

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

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

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

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

Поиск неисправностей

Где я могу получить необходимые мне инструменты?

Получение завитка

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

Получение OpenSSL

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

Получение Wireshark, Tshark или Tcpdump

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

Исходный код Tcpdump и LibPCAP можно найти по адресу https://www.tcpdump.org .

Документацию по этим полезным инструментам можно найти в руководстве пользователя Wireshark , на справочной странице Tshark и на справочной странице Tcpdump соответственно.

Получение ключевого инструмента Java

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

Что делать при остановке производства

Основной способ действий для вас — установить необходимые корневые сертификаты из набора доверенных корневых ЦС Google в хранилище корневых сертификатов, которое использует ваше приложение.

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

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

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

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

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

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

Где находятся ваши затронутые серверы?
На какие IP-адреса Google звонит ваша служба?
Какие API затронуты этой проблемой?
Когда именно проблема началась?

Вывод следующих команд:

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;

Инструкции по получению необходимых инструментов см. в вопросе Где я могу получить необходимые мне инструменты? .

Подача заявки на поддержку

Следуйте инструкциям по созданию обращения в службу поддержки в разделе Поддержка и ресурсы платформы Google Карт .

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

Какие у вас общедоступные IP-адреса?
Какой общедоступный IP-адрес вашего DNS-сервера?
Если возможно, захват пакета tcpdump или Wireshark неудачного согласования TLS с https://maps.googleapis.com/ в формате PCAP с использованием достаточно большой длины снимка для захвата всего пакета без его усечения (например, с использованием -s0 на старые версии tcpdump ).
Если возможно, записывайте в журнал выдержки из вашей службы, показывающие точную причину сбоя соединения TLS, желательно с полной информацией о цепочке сертификатов сервера.

Размещение в публичном выпуске 186840968

При размещении комментария к общедоступной проблеме 186840968 включите информацию, указанную в разделе Начальное устранение неполадок .

Как определить публичный адрес моего 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.

Used TLS library and root certificate bundle

Running curl with the -vvI flags also prints out the used root certificates store, but the exact output may vary per system as shown here.

Output from a Red Hat Linux machine with curl linked against NSS may contain these lines:

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

Output from an Ubuntu or Debian Linux machine may contain these lines:

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

Output from an Ubuntu or Debian Linux machine using the Google root certificate PEM file given using the --cacert flag may contain these lines:

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

User agent

Outgoing requests contain the User-Agent header, which may provide useful information about curl and your system.

An example from a Red Hat Linux machine:

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

Failed TLS handshake

Lines, such as the ones in this code sample, indicate the connection was terminated mid-TLS-handshake because of an untrusted server certificate. The absence of debug output starting with > or < are also strong indicators of an unsuccessful connection attempt:

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

Successful TLS handshake

A successful TLS handshake is indicated by the presence of similar looking lines to the ones in this code sample. The cipher suite used for the encrypted connection should be listed, as should details of the accepted server certificate. Furthermore, the presence of lines starting with > or < indicate that payload HTTP traffic is being successfully transmitted over the TLS encrypted connection:

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

How to print the received server certificates in human readable form

Presuming the output is PEM formatted, eg the output from openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null , you can print out the served certificate following these steps:

Copy the entire Base 64 encoded certificate, including header and footer:
```
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
```

Then do:

openssl x509 -inform pem -noout -text
````

Then paste the contents of your copy buffer into the terminal.
Hit the Return key.

For example input and output, see section How to print PEM certificates in human readable form .

What do cross-signed Google certificates look like in OpenSSL?

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

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

---
…

Managing your trusted certificates

How can I check the trusted root certificates on my mobile phone?

Android trusted certificates

As mentioned under question Are mobile apps at risk of breaking? , Android has since version 4.0 allowed handset users to verify the list of trusted certificates under Settings . This table shows the exact Settings menu path:

Android version	Menu path
1.x, 2.x, 3.x	N/A
4.x, 5.x, 6.x, 7.x	Settings > Security > Trusted credentials
8.x, 9	Settings > Security & Location > Encryption & credentials > Trusted credentials
10+	Settings > Security > Advanced > Encryption & credentials > Trusted credentials

This table illustrates the likely availability of the most critical root certificates per Android version, based on manual verification using currently available Android Virtual Device (AVD) system images, falling back to the AOSP ca-certificates Git repository version history, where system images were no longer available:

Android version	GTS Root R1	GlobalSign Root CA - R1	GlobalSign Root R2 (valid until Dec 15, 2021)
2.3, 3.2, 4.x, 5.x, 6.x, 7.x, 8.x, 9
10+

Updating the Android system root certificates store is generally not possible without a firmware update or rooting the device. However, on most Android versions that are still in wide use, the current set of trusted root certificates is likely to provide uninterrupted service for multiple years to come, beyond the effective lifetime of most currently existing devices.

Beginning with version 7.0, Android offers application developers a secure method for adding trusted certificates which are only trusted by their application. This is done by bundling the certificates with the application and creating a custom network security configuration, as described in the Android Best Practices for Security & Privacy Network Security Configuration training document.

However, as third-party application developers will not be able to influence the network security configuration of traffic originating from the Google Play Services APK , such efforts would likely only provide a partial workaround.

On older legacy devices, your only available option would be to rely on user-added CAs, either installed by a corporate group policy applied to the end user device, or by the end users themselves.

iOS Trust Store

While Apple does not directly show its default set of trusted root certificates to the handset user, the company has links to the sets of trusted root CAs for iOS versions 5 and up from the Apple Support articles:

However, any additional certificates installed on the iOS device should be visible under Settings > General > Profile . If no additional certificates are installed, the Profile menu item may not be displayed.

This table illustrates the availability of the most critical root certificates per iOS version, based on the above sources:

iOS version	GTS Root R1	GlobalSign Root CA - R1	GlobalSign Root R2 (valid until Dec 15, 2021)
5, 6, 7, 8, 9, 10, 11, 12.0
12.1.3+

Where is my system root certificates store and how can I update it?

The location of the default root certificates store varies with operating system and used SSL/TLS library. However, on most Linux distributions, the default root certificates can be found under one of the following paths:

/usr/local/share/ca-certificates : Debian, Ubuntu, older RHEL and CentOS versions
/etc/pki/ca-trust/source/anchors and /usr/share/pki/ca-trust-source : Fedora, newer RHEL and CentOS versions
/var/lib/ca-certificates : OpenSUSE

Other certificate paths may include:

/etc/ssl/certs : Debian, Ubuntu
/etc/pki/tls/certs : RHEL, CentOS

Some of the certificates in these directories are likely symbolic links to files in other directories.

OpenSSL root certificates store

For applications using OpenSSL , you can check the configured location of its installed components, including the default root certificates store using the following command:

openssl version -d

The command prints out OPENSSLDIR , which corresponds to the top level directory the library and its configurations can be found under:

OPENSSLDIR: "/usr/lib/ssl"

The root certificates store is located in the certs subdirectory.

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
…

If OpenSSL relies on the default system root certificates store as in the example above, check the top-level section Where is my system root certificates store and how can I update it? to ensure the system root certificate bundle is up to date.

For instructions getting openssl , see section Getting OpenSSL .

Java root certificates store

Java applications might use their own root certificates store, which on Linux systems is typically located at /etc/pki/java/cacerts or /usr/share/ca-certificates-java , which can be managed using the Java keytool command-line tool.

To import an individual certificate into your Java certificate store, issue the following command:

keytool -import -trustcacerts -file cert.pem -alias alias -keystore certs.jks

Just replace cert.pem with the certificate file corresponding to each recommended root certificate, alias with a unique but meaningful certificate alias, and certs.jks with the certificate database file used in your environment.

For further information, please refer to the following Oracle and Stack Overflow articles:

Mozilla NSS root certificates store

Applications using Mozilla NSS may by default also use a system-wide certificate database typically located under /etc/pki/nssdb , or a user-specific default store under ${HOME}/.pki/nssdb .

For updating your NSS database, use the certutil tool.

To import an individual certificate file into your NSS database, issue the following command:

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

Just replace cert.pem with the certificate file corresponding to each recommended root certificate, cert-name with a meaningful certificate nickname, and certdir with the certificate database path used in your environment.

For further information, please refer to the official NSS Tools certutil manual, as well as your operating system documentation.

Microsoft .NET root certificates store

Windows .NET developers may find at least the following Microsoft articles useful for updating their root certificates store:

Certificate file formats

What is a PEM file?

Privacy-Enhanced Mail (PEM) is a de-facto standard textual file format for storing and sending cryptographic certificates, keys, etc., formalized as a de-jure standard in RFC 7468 .

While the file format itself is human readable, the Base64 encoded binary certificate data information is not. However, the PEM specification permits emitting explanatory text either before or after the text encoded certificate body, and many tools use this feature to also provide a clear-text summary of the most relevant data elements in a certificate.

Tools, such as openssl can also be used to decode the entire certificate into human-readable form. See section How to print PEM certificates in human readable form for more info.

What is a ".crt" file?

Tools that allow exporting of certificates in PEM format commonly use the file extension ".crt" to indicate the file uses a textual encoding.

What is a DER file?

Distinguished Encoding Rules (DER) is a standardized binary format for encoding certificates. Certificates in PEM files are typically Base64 encoded DER certificates.

What is a ".cer" file?

An exported file with a ".cer" suffix may contain a PEM-encoded certificate, but more typically a binary, usually DER-encoded certificate. By convention , ".cer" files generally only contain a single certificate.

My system refuses to import all certificates from roots.pem

Some systems, eg, Java keytool , may only import a single certificate from a PEM file, even if it contains several. See question How do I extract individual certificates from roots.pem? to see how the file can first be split up.

How do I extract individual certificates from roots.pem?

You can split up roots.pem into its component certificates using the following simple bash script:

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

This should create a number of individual PEM files similar to the ones listed here:

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

The individual PEM files, such as 02265526.pem can then be imported separately, or further converted into a file format your certificate store accepts.

How to convert between a PEM file and a format supported by my system

The OpenSSL toolkit command-line tool openssl can be used to convert files between all commonly used certificate file formats. Instructions for converting from a PEM file to most commonly used certificate file formats are listed below.

For a full list of available options, check the official OpenSSL Command Line Utilities documentation .

For instructions getting openssl , see section Getting OpenSSL .

How do I convert a PEM file to DER format?

Using openssl you can issue the following command to convert a file from PEM to DER:

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

How do I convert a PEM file to PKCS #7?

Using openssl you can issue the following command to convert a file from PEM to PKCS #7:

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

How do I convert a PEM file to PKCS #12 (PFX)?

Using openssl you can issue the following command to convert a file from PEM to PKCS #12:

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

You need to provide a file password when creating a PKCS #12 archive. Make sure to store the password somewhere safe, if you don't immediately import the PKCS #12 file into your system.

Listing, printing and exporting certificates from your root certificates store

How do I export a certificate from the Java Key Store as a PEM file?

Using keytool you can issue the following command to list all certificates in your certificate store, together with the alias you can use to export each one:

keytool -v -list -keystore certs.jks

Just replace certs.jks with the certificate database file used in your environment. This command will also show the alias of each certificate, which you will need if you wist to export it.

To export an individual certificate in PEM format, issue the following command:

keytool -exportcert -rfc -keystore certs.jks -alias alias > alias.pem

Just replace certs.jks with the certificate database file used in your environment, and provide an alias and alias.pem corresponding to the certificate you wish to export.

For further information, please refer to the Java Platform, Standard Edition Tools Reference: keytool manual.

How do I export certificates from the NSS root certificates store as a PEM file?

Using certutil you can issue the following command to list all certificates in your certificate store, together with the nickname you can use to export each one:

certutil -L -d certdir

Just replace certdir with the certificate database path used in your environment. This command will also show the nickname of each certificate, which you will need if you wist to export it.

To export an individual certificate in PEM format, issue the following command:

certutil -L -n cert-name -a -d certdir > cert.pem

Just replace certdir with the certificate database path used in your environment, and provide a cert-name and cert.pem corresponding to the certificate you wish to export.

For further information, please refer to the official NSS Tools certutil manual, as well as your operating system documentation.

How to print PEM certificates in human readable form

In the following examples we presume you have the file GTS_Root_R1.pem with the following contents:

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

Printing certificate files using OpenSSL

Issuing the command

openssl x509 -in GTS_Root_R1.pem -text

should output something similar to:

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
        …

For instructions getting openssl , see section Getting OpenSSL .

Printing certificates using Java keytool

Issuing the following command

keytool -printcert -file GTS_Root_R1.pem

should output something similar to:

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

For instructions getting keytool , see section Getting Java keytool .

How do I see what certificates are installed in my root certificates store?

This varies per operating system and SSL/TLS library. However, the tools that allows importing and exporting certificates to and from the root certificates store typically also provide an option to list the installed certificates.

Also, if you have successfully exported the trusted root certificates into PEM files, or your root certificates store already contains stored PEM files, you can try opening the files in any text editor, as it is a plain text file format.

The PEM file may be properly labeled, providing human readable information of the associated certificate authority (example from the trusted Google root CA bundle ):

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

The file may also just contain the certificate part. In such cases, the name of the file, such as GTS_Root_R1.pem may describe which CA the certificate belongs to. The certificate string between the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- tokens is also guaranteed to be unique for each CA.

However, even if you lack the above tools, as each certificate in the trusted Google root CA bundle is properly labeled, you can reliably match the root CAs from the bundle aganist the ones from your root certificates store either by Issuer , or by comparing PEM file certificate strings.

Web browsers may use their own root certificates store, or rely on the default one provided by the operating. However, all modern browsers should allow you to manage or at least view the set of root CAs they trust. See question Are JavaScript applications at risk of breaking? for further details.

For mobile phone specific instructions, see the separate question How can I check the trusted root certificates on my mobile phone? .

Appendix

Need more info?

Always rely primarily on your operating system documentation, the documentation of your application programming language(s), as well as the documentation from any external libraries that your application is using.

Any other source of information including this FAQ may be outdated or otherwise incorrect, and should not be taken as authoritative. However, you may still find useful information on many of the Stack Exchange Q&A communities , as well as sites such as AdamW on Linux and more and the confirm blog , among others.

Please also check out the Google Trust Services FAQ .

For further details about advanced topics, such as certificate pinning, you may find the Open Web Application Security Project (OWASP) Certificate and Public Key Pinning article and Pinning Cheat Sheet informative. For Android specific instructions, please refer to the official Android Best Practices for Security & Privacy Security with HTTPS and SSL training document. For discussion about certificate vs. public key pinning on Android, you may find Matthew Dolan's blog post Android Security: SSL Pinning useful.

The Android Best Practices for Security & Privacy Network Security Configuration training document and JeroenHD's blog post Android 7 Nougat and certificate authorities provide further information about managing additional trusted certificates on Android.

For a comprehensive list of root CAs trusted by AOSP, refer to the ca-certificates Git repository. For any versions based on unofficial Android forks, eg LineageOS, refer to the appropriate repositories provided by the OS vendor.