Практически любая, сколь-нибудь не стандартная задача выливается в часы малопродуктивного гугления, что печалит. Сегодня я искал ответ на вопрос, как в OSX получить сертификаты сайта, с которым ты планируешь общаться по HTTPS. До кучи дело осложняется тем, что все должно работать не только напрямую, но и через прокси.
Если говорить о Windows, данная задача решается довольно просто, благодаря библиотеке WinHTTP (кажется, ее так звать) и функции
Posts Tagged → cURL
cURL & Proxy & HTTPS & Authorization == CURLE_RECV_ERROR
Да, баги в тулзах преследуют меня всю неделю. На сей раз отличился cURL с древним багом связанным с запросом отправляемым по HTTPS через прокси. Похоже что ситуация не слишком распространенная, т.к. надо не только работать через прокси, но еще на прокси должна быть включена авторизация и при отправке запроса пароль должен быть не указан. В принципе, в такой ситуации ожидаешь код 407, просишь пользователя ввести пароль и наступает счастье. Но вот cURL думает иначе. Вместо того чтоб вернуть 407 и страничку с ошибкой от прокси, которые судя по его логу присутствуют, зачем-то возвращается CURLE_RECV_ERROR.
Ignore 1380 bytes of response-body
Received HTTP code 407 from proxy after CONNECT
Closing connection #0
Failure when receiving data from the peer
Какого-либо корректного выхода из данной ситуации я не нашел. Так что, при работе через прокси, если пароль не задан и возникает ошибка CURLE_RECV_ERROR, единственное что остается – повторить запрос, предварительно указав параметры авторизации на проксе.
cURL и корневые сертификаты
В описанном раньше способе работы с HTTPS соединением есть одна проблема – необходимо каким-то способом тащить за собой актуальный список корневых сертификатов. А тащить, обновлять, следить за изменениями… Вобщем задача не из тривиальных.
Не знаю как на Венде, а в Mac OS X можно все это дело переложить на Apple:
sudo security find-certificate -a -p /System/Library/Keychains/SystemRootCertificates.keychain > roots.pem
После чего передать полученный список корневых сертификатов в cURL.
HTTPS & cURL
В пятницу, работая над одной из наших подсистем, я занимался прикручиванием cURL и тихо охреневал с того, что пишет народ народ в интернете по поводу реализации работы с HTTPS при использовании cURL. Лично я всегда считал что HTTPS необходим для установки защищенного соединения. Из чего следует что, во-первых, данные передаются в шифрованном виде, и во-вторых, мы знаем с кем общаемся.
Так вот, как выяснилось на практике, если с шифрованием ни у кого вопросов не возникает, то вот на авторизацию все кладут болт.
Причем основательно, например так:
curl_easy_setopt( curl_, CURLOPT_SSL_VERIFYPEER, 0 );
Что отключает проверку полученного сертификата. Ну а особо одаренные делают даже так:
curl_easy_setopt( curl_, CURLOPT_SSL_VERIFYHOST, 0 );
Что отключает проверку соответствия хоста, указанного в сертификате, с хостом, с которым мы общаемся.
Что интересно, если проверку канала обычно отключают из за глупости и лени, то проверку хоста может отключить разве что феерический идит, но, как показал гугл, их полно. Подобное решение для меня большая загадка, зачем нужно шифровать данные, если не известно с кем идет общение?
Так вот, как оказалось все дело в том, что если не выключить проверку канала то возникают различные неприятные ошибки связанные с невозможностью проверки сертификата канала. Например вот такие:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
В то же время информации том, что делать в такой ситуации в интернете по большому счету нет. Но все не так уж и страшно, всего-то немного терпения и экспериментов.
Все решается довольно просто. Необходимо скачать набор сертификатов с сайта cURL и передать их в библиотеку при помощи CURLOPT_CAINFO. Хотя в документации к библиотеке и говорится что эта функция не работает под Windows, это не соответствует действительности. Она отлично работает как в Mac OS X так и в Windows. В cURL для установки сертификатов будет вызвана OpenSSL функция SSL_CTX_load_verify_locations, соответственно все сертификаты должны быть в PEM формате.
Собственно это все, после этого все должно отлично работать.