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

Документ состоит из следующих разделов:

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

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

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

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

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

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

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

Внимание! В 2021 году Google продолжит переход на собственный корневой центр сертификации (ЦС) Google Trust Services (GTS). Это долгий процесс, который начался в 2017 году. Новый корневой ЦС используется для подтверждения безопасности всех подключений TLS к платформе Google Карт. На большую часть клиентов это изменение никак не повлияет, но владельцам некоторых приложений (особенно тем, кто не принимал никаких мер в 2017 году) потребуется проверить и обновить свои клиентские сервисы, чтобы гарантировать плавный переход. Для этого им необходимо выполнить рекомендации, приведенные в этом документе.

Обзор

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

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

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

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

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

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

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

Вам необходимо проверить свои системы в следующих случаях:

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

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

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

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

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

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

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

Практически все современные TLS-клиенты и системы по умолчанию поддерживают сертификат GTS Root R1 или должны получать его в ходе стандартных обновлений ПО. А сертификат GlobalSign Root CA – R1 должен быть доступен даже в уже устаревших системах.

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

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

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

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

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

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

Как можно заранее узнать о будущих переходах?

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

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

Переход на новый корневой ЦС затронет все сервисы Google, которые мы используем?

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

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

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

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

Если TLS-подключение к тестовой конечной точке GTS Root R1 Cross устанавливается успешно, значит приложение должно работать без проблем до истечения срока действия 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 вы найдете в соответствующем разделе.

Подробнее о полезных инструментах…

Также ознакомьтесь с инструкциями по тестированию.

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дополнительные рекомендации вы можете найти в этом разделе на странице часто задаваемых вопросов.

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

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

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

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

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

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

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

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

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

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

Для устройств iOS компания Apple публикует актуальный список доверенных корневых ЦС по каждой из версий iOS на своих страницах поддержки. Все версии iOS, начиная с версии 5, поддерживают GlobalSign Root CA – R1.

Корневые центры сертификации GTS, в том числе GTS Root R1, поддерживаются начиная с iOS версии 12.1.3.

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

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

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

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

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

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

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

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

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

Если в вашем дистрибутиве ОС нет инструмента 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

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

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

Основным решением в этой ситуации будет установка необходимых сертификатов из пакета доверенных корневых ЦС 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.

Использованная библиотека 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/<user>/Downloads/roots.pem
  CApath: /etc/ssl/certs

Предупреждение. Существует много распространенных библиотек SSL/TLS (см. таблицу сравнения на сайте curl), в каждой из которых можно использовать разные хранилища сертификатов и пакеты корневых сертификатов. Если инструмент curl связан не с той библиотекой SSL/TLS, которую использует приложение, следует отдельно удостовериться, что обе эти библиотеки используют одно и то же хранилище сертификатов, чтобы результаты теста были достаточно надежными.

Агент пользователя

Исходящие запросы содержат заголовок 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 libssh1/1.4.2
> Host: maps.googleapis.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-подключение:

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

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

Если результаты возвращаются в формате PEM, как, например, выходные данные openssl s_client -connect maps.googleapis.com:443 -showcerts </dev/null, то вы можете распечатать сертификаты следующим образом:

Полностью скопируйте закодированный в Base 64 сертификат, включая заголовок и нижний колонтитул:
```
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----
```
Затем выполните следующую команду:
```
openssl x509 -inform pem -noout -text
````
```
Вставьте содержимое буфера обмена в окно терминала.
Нажмите Ввод.

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

Как выглядят сертификаты Google с перекрестной подписью в 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

---
…

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

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

Доверенные сертификаты 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	GTS Root R1	GlobalSign Root CA – R1	GlobalSign Root R2 (действует до 15 декабря 2021 г.)
2.3, 3.2, 4.x, 5.x, 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 должны быть видны в разделе Настройки > Основные > Профиль. Если дополнительных сертификатов нет, пункт меню Profile (Профиль) может не отображаться.

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

Версия iOS	GTS Root R1	GlobalSign Root CA – R1	GlobalSign Root R2 (действует до 15 декабря 2021 г.)
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 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
…

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

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

Хранилище корневых сертификатов Java

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

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

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

Замените текст cert.pem названием файла сертификата, соответствующего рекомендуемому корневому сертификату, alias – уникальным и понятным псевдонимом сертификата, а certs.jks – названием файла вашей базы сертификатов.

Дополнительные сведения можно найти в следующих статьях на сайтах Oracle и Stack Overflow:

Хранилище корневых сертификатов Mozilla NSS

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

Чтобы добавить сертификат в хранилище NSS, воспользуйтесь инструментом certutil.

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

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

Замените текст cert.pem названием файла сертификата, соответствующего каждому рекомендуемому корневому сертификату, cert-name – понятным псевдонимом сертификата, а certdir – путем к вашей базе сертификатов.

Дополнительные сведения можно найти в официальном руководстве по работе с программой certutil для NSS и документации к вашей операционной системе.

Хранилище корневых сертификатов Microsoft .NET

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

Форматы файлов для сертификатов

Что такое 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 в мою систему

Некоторые программы, например Java keytool, могут импортировать из 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}" $(openssl x509 -in "${f}" -noout -issuer_hash).pem; \
done

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

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

Затем PEM-файлы (такие как 02265526.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 в систему, сохраните этот пароль в надежном месте.

Вывод, печать и экспорт сертификатов из вашего хранилища

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

Чтобы получить список всех сертификатов в хранилище с указанием их псевдонимов, необходимых для экспорта, выполните следующую команду в keytool:

keytool -v -list -keystore certs.jks

Замените certs.jks названием файла вашей базы сертификатов. Эта команда также позволяет получить псевдонимы сертификатов, необходимые для их экспорта.

Чтобы экспортировать отдельный сертификат в формате PEM, выполните следующую команду:

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

Замените certs.jks названием файла вашей базы сертификатов и укажите значения для alias и alias.pem того сертификата, который вы хотите экспортировать.

Дополнительные сведения можно найти в руководстве Java Platform, Standard Edition Tools Reference: keytool (Платформа Java, справочник по инструментам в стандартном выпуске: keytool).

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

Чтобы получить список всех сертификатов в хранилище с указанием их псевдонимов, необходимых для экспорта, выполните следующую команду в certutil:

certutil -L -d certdir

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

Чтобы экспортировать отдельный сертификат в формате PEM, выполните следующую команду:

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

Замените certdir путем к вашей базе сертификатов и укажите значения для cert-name и cert.pem того сертификата, который вы хотите экспортировать.

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

В примерах ниже предполагается, что у вас есть файл GTS_Root_R1.pem со следующим содержимым:

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

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

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

openssl x509 -in GTS_Root_R1.pem -text

Выходные данные должны быть похожи на эти:

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
        …

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

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

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

keytool -printcert -file GTS_Root_R1.pem

Выходные данные должны быть похожи на эти:

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

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

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

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

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

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

# Operating CA: Google Trust Services LLC
# Issuer: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Subject: C=US, O=Google Trust Services LLC, CN=GTS Root R1
# Label: "GTS Root R1"
# Serial: 6e:47:a9:c5:4b:47:0c:0d:ec:33:d0:89:b9:1c:f4:e1
# MD5 Fingerprint: 82:1A:EF:D4:D2:4A:F2:9F:E2:3D:97:06:14:70:72:85
# SHA1 Fingerprint: E1:C9:50:E6:EF:22:F8:4C:56:45:72:8B:92:20:60:D7:D5:A7:A3:E8
# SHA256 Fingerprint: 2A:57:54:71:E3:13:40:BC:21:58:1C:BD:2C:F1:3E:15:84:63:20:3E:CE:94:BC:F9:D3:CC:19:6B:F0:9A:54:72
-----BEGIN CERTIFICATE-----
…
-----END CERTIFICATE-----

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

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

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

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

Приложение

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

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

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

Ознакомьтесь также с ответами на часто задаваемые вопросы о Google Trust Services.

Более подробная информация по сложным темам, таким как закрепление сертификатов, содержится в этой статье по проекту обеспечения безопасности веб-приложений (OWASP – Open Web Application Security Project) и в краткой памятке. Инструкции для 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, можно найти в репозиториях, поддерживаемых поставщиками этих ОС.