Вопрос по ssl, openssl, x509 – Проверка домена сертификата в OpenSSL

5

Мне нужно подтвердить домен сертификата X509 с помощью C-land OpenSSL.

Насколько я понимаю, библиотека не делает этого для меня, и я должен примерно реализовать следующий алгоритм:

If the dnsName field of the subjectAlternativeName extension is present, set name to that value. Otherwise, set name to the CN field of the subject. Compare name against the requested hostname, allowing each asterisk to match [A-Za-z0-9_]+, but not 'dot' (.).

Мне кажется, что для этого должно быть достаточно кода, но я не нашел ни одного.

Кто-нибудь может найти пример этого? Или, в качестве альтернативы, проверьте работоспособность моего алгоритма?

РЕДАКТИРОВАТЬ: Это то, что я придумал:https://gist.github.com/2821083, Кажется действительно странным, что OpenSSL оставил бы это до вызова кода.

Вместо «установки» значение, основанное на том, что вы найдете в сертификате, вы должны сделать это наоборот: проверьте, имеет ли то, что вы ожидаете, соответствующую запись SAN DNS. Это связано с тем, что в расширении SAN может быть несколько записей DNS. (Между прочим, в RFC 6125 есть более точные правила сопоставления подстановочных знаков.) Bruno

Ваш Ответ

2   ответа
5

Вы в значительной степени на месте - хотя остерегайтесь предметных альтернативных имен и необработанных IP-адресов и полных доменных имен. Вы можете хотеть украсть

BOOL SSL_X509_getIDs(apr_pool_t *p, X509 *x509, apr_array_header_t **ids)

и родственные друзья изhttp://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_util_ssl.c и вызываемый в ssl_engine_init.c (который, кстати, на стороне сервера) для всех вариантов.

Когда вы действуете в обратном вызове openssl - также учитывайте дату & amp; время и цепочка, если вы не указали это уже в CTX.

Dw.

2

It seems really strange that OpenSSL would leave this up to calling code.

Да, это очень проблематичное упущение на практике, потому что многие приложения не понимают, что они должны выполнять проверку вручную.

OpenSSL 1.1.0 будет включать проверку имени хоста (это вHEAD сейчас (по состоянию на сентябрь 2013 года)). Согласно журналам изменений, существует-verify_name вариант иapps.c отвечает на-verify_hostname переключатель. Ноs_client не отвечает ни на один из переключателей, поэтому неясно, как проверка имени хоста будет осуществляться или вызываться для клиента.

If the dnsName field of the subjectAlternativeName extension is present, set name to that value.

Может быть несколько альтернативных имен субъектов (SAN), поэтому будьте готовы к более чем одному.

Otherwise, set name to the CN field of the subject.

Полагаю, тебе тоже нужно проверить это на совпадение.

Compare name against the requested hostname, allowing each asterisk to match [A-Za-z0-9_]+, but not 'dot' (.).

Это гораздо более болезненно. Вы также должны убедиться, что вы не соответствуете рДВУ или нДВУ. Например, вы не хотите совпадать с сертификатом, выданным против gTLD*.com, Этот сертификат, вероятно, был выдан плохим парнем;)

ccTLD имеют вид * .eu, * .us или & # xB87; & # xBB2; & # xB99; & # xBCD; & # xB95; & # xBC8; (Nic.lk). Их около 5000 или около того, и Mozilla предлагает список наhttp://publicsuffix.org/, Необработанный список находится наhttps://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1.

It seems to me that there should be plenty of code kicking around to do this, but I haven't found any.

В дополнение к предложению Ван Гулика вы также можете попробовать Curl. Я вполне уверен, что Curl содержит код соответствия имени хоста.

Вы даже можете убедиться, что сертификаты правильно сформированы. Группа, ответственная в контексте Интернета - это форумы CA / Browser. Они имеют базовые и расширенные требования для создания сертификатов:

Baseline Certificate Requirements, https://www.cabforum.org/Baseline_Requirements_V1_1_6.pdf Extended Validation Certificate Requirements, https://www.cabforum.org/Guidelines_v1_4_3.pdf

В базовых документах вы найдете, например, IP-адрес, указанный в качестве общего имени (CN), также должен быть указан в дополнительных именах субъектов (SAN).

В расширенной документации вы обнаружите, что зарезервированные IP-адреса (RFC 1918) не могут присутствовать в расширенном сертификате проверки (EV); и сертификаты EV не могут содержать подстановочные знаки.

Похожие вопросы