Как получить Root CA Certificate Fingerprint с использованием OpenSSL

Question

С помощью следующей команды, я могу проверить sha1 отпечаток представленного сертификата:

$ openssl s_client -connect hooks.slack.com:443 -showcerts < /dev/null 2>/dev/null | openssl x509 -in /dev/stdin -sha1 -noout -fingerprint 
SHA1 Fingerprint=AB:F0:5B:A9:1A:E0:AE:5F:CE:32:2E:7C:66:67:49:EC:DD:6D:6A:38 

Но что, если я хочу, чтобы получить отпечаток пальца верхнего уровня Подписание полномочий?

$ openssl s_client -connect hooks.slack.com:443 < /dev/null 2>/dev/null 
CONNECTED(00000003) 
--- 
Certificate chain 
0 s:/C=US/ST=California/L=San Francisco/O=Slack Technologies, Inc/CN=*.slack.com 
    i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3 
1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3 
    i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA <- **I WANT THIS SHA1** 

В случае, если я хочу, чтобы проверить это на хранилище ключей Java, чтобы проверить окончательно, если он содержит тот же CA.

geotrustglobalca, 18-Jul-2003, trustedCertEntry, 
Certificate fingerprint (SHA1): DE:28:F4:A4:FF:E5:B9:2F:A3:C5:03:D1:A3:49:A7:F9:96:2A:82:12 

С "geotrustglobalca" и "/ C = US/O = GeoTrust Inc./CN=GeoTrust Global CA" не очень сопоставимы.

Answer 1

Поскольку «geotrustglobalca» и «/ C = US/O = GeoTrust Inc./CN=GeoTrust Global CA» на самом деле не сопоставимы.

Я блуждаю по бассейну с ответом на «эквивалентность сертификата X.509», так как его не легко увидеть или легко достать.

Во-первых, вы должны быть осторожны, сравнивая сертификаты на равенство. Если <certificate bits 1> == <certificate bits 2>, то вы можете сказать, что они являются тем же самым сертификатом и равны. Однако обратное не выполняется.

Чтобы понять обратное, вам нужно знать две вещи. Во-первых, ЦС иногда перевыпускают сертификат с почти одинаковыми параметрами. Основываясь на имени субъекта, они эквивалентны; но на основе бит они не равны. Некоторые ЦС сделали это в прошлом, чтобы перейти от SHA-1 к SHA-256.

Второе, что нужно понять, это то, что является важными битами, поэтому вы можете определить, являются ли сертификаты эквивалентными. IETF не имеет документа для проверки X.509. Ближайшим является RFC 4158: Internet X.509 Public Key Infrastructure: Certification Path Building, смешанный с некоторыми другими документами, такими как правила выдачи (которые не совпадают с правилами проверки).

В соответствии с RFC 4158, то можно однозначно идентифицировать сертификат, либо:

• {Issuer DN, Serial Number} пары
• {Authority Key identifier (AKID), Subject Key identifier (SKID)} пара

угловой корпус СА повторно выдав результаты Root CA in:

1. изменения хеша
2. порядковый номер изменения
3. открытый ключ остается
4. отличительное имя остается

Пункт (3), открытый ключ остается, является существенным, потому что это не означает, что ни один ключ Идентификатор Authority (AKID) или Тема Ключ идентификатора (SKID) изменений. Пункт (4), Знаменитое имя остается, является значительным, потому что его много людей используют для сравнения (и это стало причиной многих ошибок безопасности на протяжении многих лет).

В этом случае идентификаторы ключей будут одинаковыми, поэтому вы должны принять решение, даже если серийный номер изменился. (Серийный номер должен изменяться в соответствии с правилами IETF и CA/B).

очень нечетный углом так, что пришло в открытом ключах пиннинга в последнее время, сервер представляет собой эллиптический сертификат кривого с использованием параметров домена (полное расширение p, g, Q и т.д.), но клиент ожидает именованный кривой (например, secp256r1). Должен ли этот ключ приниматься как эквивалент? (IETF говорит, что сертификат должен использовать именованную кривую).

---

Учитывая вышеизложенную информацию, эта информация бесполезна в вашем сравнении:

• "geotrustglobalca"

И эта информация неполна для сравнения:

• "/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA"

В этом случае вы должны ошибаться на стороне осторожности и отклонять сравнение для равенства или эквивалентности.

Answer 2

В подобной ситуации с сертификатом зашифровать ДАВАЙТЕ на виртуальный хостинг решение, которое я имел успех с указанием servername параметра:

openssl s_client -connect hooks.slack.com:443 -servername hooks.slack.com -showcerts < /dev/null 2>/dev/null | openssl x509 -in /dev/stdin -sha1 -noout -fingerprint 

Answer 3

Я не уверен, что это прямо отвечает на ваш вопрос, но если сервер подарков корневой сертификат как часть цепочки (это необязательно, поэтому он может и не быть), вы можете использовать параметр -showcerts, чтобы показать все из них.

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

echo "" | openssl s_client -showcerts -connect eistest.mtsu.edu:443 2>&1 |\ 
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p;/-END CERTIFICATE-/a\\x0' |\ 
sed -e '$ d' |\ 
xargs -0rl -I% sh -c "echo '%' | openssl x509 -subject -issuer -fingerprint -noout" 

Повторение нулевой строки в openssl s_client не позволяет ожидать соединения с тайм-аутом. Первое sed выдаст только отформатированные сертификаты PEM, разделенные символом NUL.