Патрик Мевзек указал мне на правильный ответ (Спасибо, Патрик!).Поскольку было необходимо провести некоторое расследование, я решил записать его как полный ответ.
Я работаю в Windows Server 2012. Более новые версии, вероятно, будут работать аналогично.Для проверки сертификатов и связи я использую:
Файлы:
Итак, я являюсь клиентомСервер.Существует двусторонняя безопасная сертификация: с помощью очень безопасных методов у нас есть следующие файлы:
- Корневой сертификат, которому можно доверять:
Root.Pem - Цепочка ненадежных сертификатоввыданный корневым сертификатом:
A.Pem, B.Pem, C.Pem - Файл закрытого ключа
MyPrivate.key и доверенный сертификат, выданный C.Pem для подтверждения моей личности: MyCertificate.pem
Если необходимо, Преобразовать файл сертификата в формат PEM
Если сертификаты не в формате PEM, нам нужно сначала преобразовать их.Чтобы проверить, есть ли они в PEM, откройте их в текстовом редакторе.Файл PEM выглядит следующим образом:
-----BEGIN CERTIFICATE-----
MIIFyjCCA7KgAwIBAgIEAJiWjDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJO
...
-----END CERTIFICATE-----
Если это не так, мы можем использовать openSSL для преобразования файла:
openssl.exe x509 -inform DER -in myCertificate.cer -out myCertificate.Pem
- inform: формат входного файла:DER / NET / PEM (ну, если уже PEM вам не нужно конвертировать)
- in / out: входной файл, выходной файл
Проверка цепочки сертификатов
Для дополнительной безопасности я проверял каждый сертификат отдельно.Вероятно, это также безопасно сделать за один шаг.
- Проверьте действительность корневого сертификата.Например, путем проверки отпечатка пальца с помощью опубликованного отпечатка пальца.
- Проверьте действительность недоверенных сертификатов
(1) Выпускается ли A.pem Root.Pem?
openssl.exe verify -show_chain -CAfile root.pem A.pem
Параметр -CAfile содержит доверенный сертификат.Последний файл - это файл, содержащий сертификат для проверки.
Ответ должен быть похож на:
A.pem: OK
Chain:
depth=0: C = NL, ..., CN = <some text describing certificate A> (untrusted)
depth=1: C = NL, ..., CN = <some text describing the trusted root certificate>
(2) B.Pem выдан доверенным A.Pem?
Теперь, когда A.pem можно доверять, мы можем проверить B.Pem.Для этого мы упоминаем промежуточный сертификат A.Pem как ненадежный, как рекомендовано в этот ответ
openssl.exe verify -show_chain -CAfile root.pem -untrusted A.pem B.pem
Ответ:
B.pem: OK
Chain:
depth=0: C = NL, ..., CN = <some text describing certificate B> (untrusted)
depth=1: C = NL, ..., CN = <some text describing certificate A> (untrusted)
depth=2: C = NL, ..., CN = <some text describing the trusted root certificate>
(3) Можем ли мы доверятьОстальная часть цепочки сертификатов?
Так что теперь B можно доверять.Чтобы продолжить проверку цепочки, объедините ненадежные CA-файлы в один файл unrusrusted.pem.Не добавляйте MyCertificate.Pem
-----BEGIN CERTIFICATE-----
MIIGNjCCBB6gAwIBA...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
jCCBB6gAwIBA34F..
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
dZBo31cAYsByRL...
-----END CERTIFICATE-----
И команду:
openssl.exe verify -show_chain -CAfile root.pem -untrusted untrusted.pem myCertificate.pem
Ответ:
MyCertificate.pem: OK
Chain:
depth=0: C = NL, ..., CN = <some text describing MyCertificate> (untrusted)
depth=1: C = NL, ..., CN = <some text describing certificate C> (untrusted)
depth=2: C = NL, ..., CN = <some text describing certificate B> (untrusted)
depth=3: C = NL, ..., CN = <some text describing certificate A> (untrusted)
depth=4: C = NL, ..., CN = <some text describing the trusted root certificate>
Я думаю, что все эти промежуточные шаги не были необходимы дляпроверьте правильность.
Проверьте соединение
Теперь, когда цепочка сертификатов является доверенной, мы можем использовать OpenSsl для проверки соединения.
- Объединить все сертификаты, кроме
MyCertificate.pem в одном файле AllTrusted.pem, используйте текстовый редактор или команду Copy Root.Pem + A.Pem + B.Pem ... Trusted.Pem
Команда:
openssl.exe s_client CAfile Trusted.Pem -connect google.nl:443
Замените google.nl:443 на правильный адрес и порт
Ответить, что-то похожее на:
CONNECTED(00000124)
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=google.com
i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIhWDCCIECgAwIBAgIQaEMB4EOx3++GhdWADJfgEjANBgkqhkiG9w0BAQsFADBU
...
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google LLC/CN=google.com
issuer=/C=US/O=Google Trust Services/CN=Google Internet Authority G3
Сервер отправил сертификат для идентификации себя.Клиент должен использовать этот сертификат и его доверенную CA-цепочку для проверки личности сервера.
Чтобы продолжить общение, нам нужен файл PEM, который содержит упомянутого эмитента и его эмитентов вплоть до корня.Используйте процедуру, описанную выше, чтобы получить полную цепочку сертификатов и добавить все сертификаты в правильном порядке в файл trusted.pem.Если вы скопируете и вставите полученный сертификат в PEM-файл (текст), вы сможете проверить этот полученный сертификат так же, как я проверил MyCertificate.Pem, как описано выше.
После того, как CA сертификат дляполученные сертификаты были установлены, моя команда openssl s_client ответила:
...
SSL handshake has read 8945 by
Verification: OK
---
New, TLSv1.2, Cipher is ...
Server public key is 2048 bit
Start Time: 1551779993
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Итак, цепочка сертификатов для идентификации сервера принята.
Идентифицировать меня на сервере
Следующим шагом будет проверка, могу ли я идентифицировать себя на сервере, используя MyCertficate.pem.
Это первый раз, когда мне нужен мой файл закрытого ключа.Для этого мы будем использовать curl:
Команда:
curl.exe -v --cacert trusted.pem --cert MyCertificate.pem --key MyPrivate.key https://...
- -v: verbose
- - cacert: текстовый файл с объединениемцепочка доверенных ЦС до корня, как проверено с помощью openssl verify
- - Cert: сертификат, который я буду использовать для идентификации себя
- - Ключ: закрытый ключ для этого сертификата
Ответ:
...
* successfully set certificate verify locations:
* CAfile: trustall.pem
...
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS handshake, CERT verify (15):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
...
* Server certificate:
* subject: C=NL; ...
* start date: Apr 19 12:10:31 2016 GMT
* expire date: Apr 19 12:10:31 2019 GMT
...
* issuer: C=NL; O= <description of certificate issuer; should be in trusted.pem>
* SSL certificate verify ok.
> GET /exchange/ciot HTTP/1.1
> Host: ....
> User-Agent: curl/7.64.0
> Accept: */*
>
< HTTP/1.1 400 Bad Request
Что мы видим:
- TrustAll.Pem содержит доверенные сертификаты
- (Out) Client Hello -(In) Server Hello: очевидно, мы находимся на условиях разговора
- Сервер отправляет сертификат и запрашивает один
- Клиент отправляет свой сертификат для идентификации себя
- Отображение полученного сертификата,тот, с которым сервер идентифицирует себя.Ожидается, что эмитент будет в доверенном. Пем
- Полученный сертификат проверяется и принимается.Передача данных может начаться
- Поскольку я не отправлял никаких данных, ответом является
400 Bad Request
Так что этого достаточно, чтобы знать, что и клиент, и сервер используют доверенные сертификаты ичто общение возможно