Различные порядки цепочек сертификатов при использовании HTTPS/TLS Node по сравнению с OpenSSL s_client

Question

Я пытаюсь проанализировать цепочку сертификатов с использованием запроса HTTPS от Node. Я тестирую его на npmjs.com (а не www.npmjs.com). Когда я тестирую его на OpenSSL, он показывает мне, что цепочка находится в неправильном порядке.

openssl s_client -connect npmjs.com:443 -showcerts 

OpenSSL Response First Certificate

subject: /OU=GT40876434/OU=See www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated - RapidSSL(R)/CN=*.npmjs.com 

issuer: /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3 

Следующая Сертификат ->

subject: /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 

issuer: /C=US/O=Equifax/OU=Equifax Secure Certificate Authority 

Следующая Сертификат ->

subject: /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3 

issuer: /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 

Однако, когда я иду к шагу через цепочку сертификатов с помощью запроса HTTPS моего узла, если сокет испускается и я

socket.getPeerCertificate(true) 

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

в Node Response First Certificate:

subject 
{ OU: 
    [ 'GT40876434', 
'See www.rapidssl.com/resources/cps (c)14', 
'Domain Control Validated - RapidSSL(R)' ], 
    CN: '*.npmjs.com' } 
issuer 
{ C: 'US', O: 'GeoTrust Inc.', CN: 'RapidSSL SHA256 CA - G3' } 

Следующая Сертификат ->

subject 
{ C: 'US', O: 'GeoTrust Inc.', CN: 'RapidSSL SHA256 CA - G3' } 
issuer 
{ C: 'US', O: 'GeoTrust Inc.', CN: 'GeoTrust Global CA' } 

Следующая Сертификат ->

subject 
{ C: 'US', O: 'GeoTrust Inc.', CN: 'GeoTrust Global CA' } 
issuer 
{ C: 'US', O: 'GeoTrust Inc.', CN: 'GeoTrust Global CA' } 

Почему это происходит?

Answer 1

Похоже, что узел переупорядочивает сертификаты для возврата в getPeerCertificates, чтобы они отображали правильный порядок в цепочке доверия (*). Но в действительности сертификатов в неправильном порядке, как это можно видеть на openssl s_client, а также в analysis of SSLLabs:

Chain issues Incorrect order 

---

(*) соответствующий код в узел-4.5.0 (LTS) находится в src/node_crypto.cc функция void SSLWrap<Base>::GetPeerCertificate. Там он извлекает сертификат листа и оригинальные одноранговые сертификаты из библиотеки openssl, используя SSL_get_peer_certificate (сертификат листа) и SSL_get_peer_cert_chain (цепочка). Затем он не возвращает сертификаты в исходном порядке цепочки, но просматривает цепочку и добавляет сертификаты в порядке, как они зависят друг от друга, путем проверки с помощью X509_check_issued.

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

Он также добавит эмитента сертификата, даже если он не содержит в себе цепь (которой обычно нет). Таким образом, вы не только получаете другой порядок сертификатов, как показано в вашем примере, но и фактически разные сертификаты.Сервер отправляет следующие сертификаты в следующем порядке:

[A] /OU=GT40876434/OU=See www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated - RapidSSL(R)/CN=*.npmjs.com 
[B] /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA, issued by Equifax 
[C] /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3 

Но getPeerCertificate возвращает следующее:

[A] /OU=GT40876434/OU=See www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated - RapidSSL(R)/CN=*.npmjs.com 
[C] /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA - G3 
[R] CA/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA, self-signed 

Таким образом сертификат [B] не будет включен, но вместо того, чтобы сертификат [R], который является корневой сертификат содержащихся в хранилище доверия. Оба имеют один и тот же объект и ключ, но подписаны разными сущностями. [B] подписывается Equifax, тогда как [R] является самоподписанным.