Как получить сертификат Peer с использованием объекта SSL_CTX

Question

Мое намерение - проверить OU («Организационная единица») в одноранговом сертификате. Использование клиента libCurl для HTTP.

У меня есть объект SSL_CTX со мной во время HTTPs сеанса клиента, который получил от функции обратного вызова, зарегистрированной в «CURLOPT_SSL_CTX_FUNCTION» Как получить сертификат Peer (ceritificate сервера) от SSL_CTX?

Здесь C# код, который я пытаюсь реализовать в C:

Easy.SSLContextFunction sf = new Easy.SSLContextFunction(SSLContextFunctionCallback); 
curlCode = easy.SetOpt(CURLoption.CURLOPT_SSL_CTX_FUNCTION, sf); 
... 

CURLcode SSLContextFunctionCallback(SSLContext ctx, object extraData) 
{ 
    CURLcode retCode = CURLcode.CURLE_OK; 
    IntPtr context = ctx.Context; 
    retCode = ApsVerifyPeer(context); return retCode; 
} 

Мне нужно реализовать функцию ApsVerifyPeer в C/C++ для чтения сертификата партнера и проверить поле OU в сертификате, где у меня есть контекст SSL (SSL_CTX). Не могли бы вы поделиться своими мыслями.

Answer 1

Как получить сертификат Peer (сертификат Ceritificate) от SSL_CTX?

Вы получаете его от SSL*, а не объекта SSL_CTX*. Это связано с тем, что он специфичен для соединения или сеанса.

Вы используете SSL_get_peer_certificate для получения сертификата партнера для подключения или сеанса.

Обратите внимание, что возвращаемый X509* может быть NULL , если не использовал сертификат (например, с сервером и анонимным протоколом).

Если у вас есть X509* назад, тогда обязательно звоните X509_free. Объект X509 подсчитывается по ссылке, и в противном случае он будет утечка памяти (я много раз просачивал эти утечки на протяжении многих лет, потому что люди не знали о его подсчете).

---

Мое намерение состоит в проверке OU ("Организационная единица") в сертификате пэра

Я думаю, вы должны быть осторожны. OU не гарантируется быть уникальным. Я думаю, что единственная гарантия заключается в том, что она будет уникальной в организации на своем уровне в дереве DIT. То есть, в рамках организации, которую она гарантирует, вы найдете не более одного подразделения для «Технологии» на уровне 1 (и вы можете найти другое на уровне 2). Однако две разные организации, каждая из которых имеет подразделение «Технология», произведут хотя бы один неверный результат, который вы не обнаружите.

Я думаю, вам нужно использовать пару {Issuer DN, Cert SerialNumber}, потому что она уникальна. Возможно, вы сможете использовать KEYID, то есть {Issuer Key Id, Subject Key Id}, но вы должны быть осторожны, потому что один и тот же открытый публичный ключ может использоваться в нескольких сертификатах.

Возможно, вы также сможете использовать Subject DN, но, вероятно, он будет уникальным только в одном конкретном PKI. Таким образом, вы можете уйти с {Issuer DN, Subject DN} парами.

И все это основано на пути, который вернется к тому, чему вы доверяете.

Возможно, вы захотите прочитать RFC 4158, Internet X.509 Public Key Infrastructure: Certification Path Building. Он говорит об этих вещах.