Gts root r1 сертификат

Мы обнаруживаем, что сертификат, который у нас есть в Java 11, был одним из GlobalSign, но с именем, заканчивающимся на «R2»:

Сертификат R2 в доверенном хранилище

Однако в некоторых случаях та же конечная точка Google возвращает конечную точку с именем, заканчивающимся на «R1»:

Сертификат R1 отсутствует в хранилище доверенных сертификатов

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

Для класса я ищу цепочку сертификатов TLS для google.com. Когда я нажимаю в браузере Chrome или Firefox, корневой сертификат отображается как GTS Root R1 со сроком действия до 2036 года, самоподписанный, поэтому это должен быть корневой сертификат.

Однако, если я проверю то же самое в Python, используя следующий код, я получу сертификат GTS Root R1 со сроком действия 2028, который подписан GlobalSign nv-sa, так что на этот раз это НЕ корневой сертификат!

Возможно ли, что Google.com возвращает две разные цепочки сертификатов в зависимости от того, какой клиент выполняет запрос? Если он предполагает, что клиент принимает GTS Root R1 в качестве корневого сертификата, он возвращает этот сертификат, иначе он возвращает сертификат, подписанный GlobalSign nv-sa?

Если да, то почему?

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

1 ответ

Так что благодаря President James K. Polk, думаю, я лучше понимаю, что происходит:

Таким образом, браузер получает цепочку сертификатов, как указано в вопросе. Затем он начинается с конечного узла цепочки сертификатов, которым является Certificate #0. Браузер просматривает свой список сохраненных корневых сертификатов для проверки листового сертификата. Если он не найдет его, он перейдет к следующей записи, Certificate #1.

Дополнительно:  Методы решения ошибки 0xc0000221

В примере с google.com он обнаруживает, что у него есть корневой сертификат для Certificate #1, и использует его, игнорируя Certificate #2. Хотя я не совсем уверен, почему он это делает:

Одна запись в блоге, описывающая это, находится здесь: https: //scotthelme.co.uk/cross-signing-alternate-trust-paths-how-they-work/

1 Дек 2021 в 17:47

2 ответа

Вы можете обратиться к репозиторию PKI Google, в котором перечислены 5 ЦС.

Согласно FAQ, они фактически перечисляют 36 различных ЦС в файле root.pem (как от 28 апреля 2022 г.).

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

29 Апр 2022 в 01:42

Не ответ (пока?) на реальную проблему, только на «нормально ли это», но и слишком длинный для комментариев.

Согласно моим недавним заметкам, www.google.com при доступе из моего местоположения использовались сертификаты под GTS CA 1O1 с этим промежуточным сертификатом под GlobalSign Root CA — R2, как показано на первом изображении. Обратите внимание, что срок действия промежуточного сертификата истекает через 6 месяцев, как и срок действия корневого сертификата, в котором он находится, что является хорошей причиной для прекращения его использования. (https://crt.sh/?caid=10 показывает два «перекрестных» сертификата для R2 под GlobalSign Root CA (см. ниже) с более длительным сроком действия, но оба они аннулированы.)

На сегодняшний день я получаю сертификат под GTS CA 1C3 под GTS Root R1 — пока что, как и ваш второй рисунок, — но затем перешел под GlobalSign Root CA БЕЗ R1. В частности, я получаю этот промежуточный сертификат для GTS CA 1C3 и это перекрестный сертификат для GTS Root R1, который действителен до 2027 и 2028 годов и отображается здесь, на веб-сайте GTS, как GTS CA 1C3 и GTS Root R1 Cross соответственно. И этот сертификат для этого корня GlobalSign, который фактически является R1 , так как другими известными в настоящее время корнями GlobalSign являются R2-6, но без имени R1 — долгое время находился по крайней мере в хранилищах доверенных сертификатов Java и Mozilla/Firefox; Я не могу легко проверить историю на других. crt.sh не знает НИ ОДНОГО сертификата с именем R1. Я хотел бы отметить, что Firefox имеет в своем доверенном хранилище сертификат root для GTS Root R1 (а также R2-R4), что означает, что он может сократить цепочку, но не делает этого; AFAICS ни одна из Java не имеет ни одного из этих корней GTS.

Дополнительно:  The root of the trouble

Более того, сертификаты leaf, которые я получаю, имеют как CommonName, так и SubjectAltName www.google.com NOT *.google.com. Это в значительной степени подтверждает, что вы получаете другой сервер, чем я.

Может помочь, если вы сможете извлечь сертификат «GlobalSign R1», который у вас, по-видимому, есть в каком-то хранилище доверенных сертификатов, и опубликовать его для просмотра или поиска, а также остальную часть цепочки, которую вы можете получить с помощью keytool -printcert -rfc -sslserver www.google.com и/или если вы можете определить, с какого адреса (адресов) Google вы получаете эту цепочку сертификатов, чтобы другие (например, я) могли попробовать ее, хотя даже один адрес может быть передан на несколько физических серверов.

16 Июн 2021 в 12:05

Оцените статью
Master Hi-technology
Добавить комментарий