|
|
ru.perl- RU.PERL ---------------------------------------------------------------------- From : Artem Chuprina 2:5020/400 16 Jul 2007 17:54:54 To : Sergey Gernichenko Subject : Re: SSL LWP -------------------------------------------------------------------------------- Sergey Gernichenko -> Artem Chuprina @ Sun, 15 Jul 2007 21:44:02 +0400: AC>> Э, батенька... Я очень сомневаюсь в существовании публично доступного AC>> описания протокола SSL на русском. Hу то есть в самых общих словах, AC>> может быть, да, а так, чтобы на основании этой информации решить AC>> проблему... AC>>>> Я бы взял AC>>>> openssl (форматы файлов с сертификатами у них одинаковые) и AC>>>> попробовал им (openssl s_client -connect с различными ключами AC>>>> отладки), подсовывая ему эти файлы (и наоборот). У него бывает AC>>>> более внятная диагностика. AC>>>> Опять же, он расскажет, что именно за сертификат подсунули. AC>>>> Правда, расскажет только в случае успешного соединения, но его, AC>>>> кажется, можно уговорить не проверять сертификат. SG>>> В заголовках ответа от сервера присутствует строка Equifax Secure SG>>> Global eBusiness CA-1. Такая же строка есть в файле ca-bundle.crt SG>>> Что еще нужно для того, чтоб клиент (в моем случае LWP) проверил SG>>> сертификат? SG>>> я даже попробовал экспортировать его из оперы, получил файл .pem, SG>>> прописал его в переменную $ENV{HTTPS_CERT_FILE}, но что подсунуть SG>>> в $ENV{HTTPS_KEY_FILE} ? AC>> Так, на глазок (извини, документацию смотреть лениво) HTTPS_CERT_FILE AC>> и HTTPS_KEY_FILE отвечают за _твою_ пару ключ-сертификат. AC>> HTTPS_KEY_FILE так точно за твой ключ - ибо никаких других секретных AC>> ключей у тебя быть не может по определению. Соответственно, актуальны AC>> они только если сервер не только показывает тебе свой сертификат, но и AC>> требует у тебя твой. Сертификат CA должен находиться в ca-bundle либо AC>> лежать соответствующим образом в certs/, которая у тебя CA_DIR. AC>> openssl s_client связывается с сервером или нет? SG> Понятно, значит, ути переменные мне устанавливать со скрипта не нужно. SG> openssl s_client с сервером связязывается, получается, дело не в SG> сертификатах... Hе торопись. Раз связывается, значит, нижеупомянутое "сайт не требует клиентских сертификатов" верно. Hо openssl s_client, будучи инструментом отладочным, не смущается, если серверный сертификат проверить не удалось. Hо сообщает об этом факте. Так, например, $ /usr/bin/openssl s_client -connect castle.ran.pp.ru:541 CONNECTED(00000006) depth=0 /C=RU/ST=Russian Federation/L=Internet/CN=mail.ran.pp.ru/emailAddress=postmaster@ran.pp.ru verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /C=RU/ST=Russian Federation/L=Internet/CN=mail.ran.pp.ru/emailAddress=postmaster@ran.pp.ru verify error:num=27:certificate not trusted verify return:1 depth=0 /C=RU/ST=Russian Federation/L=Internet/CN=mail.ran.pp.ru/emailAddress=postmaster@ran.pp.ru verify error:num=21:unable to verify the first certificate verify return:1 - --- Certificate chain 0 s:/C=RU/ST=Russian Federation/L=Internet/CN=mail.ran.pp.ru/emailAddress=postmaster@ran.pp.ru i:/C=RU/ST=Russian Federation/L=Internet/CN=Artem Chuprina/emailAddress=root@ran.pp.ru - --- Соединиться-то он соединился... Hо честно рассказал, что сертификат issuer'а ему взять неоткуда, а потому проверить сертификат, выданный ему сервером, он не может. Если у тебя verify error'ов нет, то значит, что openssl успешно проверил сертификаты. Иначе - нет. SG> Будем копать, чего еще не хватает. Подозреваю, что надо SG> сэмулировать последовательность запросов или еще чего... SG> Касаемо SSL еще такой вопрос, LWP по умолчанию проверяет серверный SG> сертификат? если нет, то как эту проверку включить? А вот LWP как раз по умолчанию, скорее всего, проверяет сертификат... Бо он не отладочный инструмент, а рабочий. -- Artem Chuprina RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru Unix-like -- для кинестетиков, Emacs -- для аудиалов, Mac -- для визуалов, Windows -- для чайников RockMover in <RM279891167063140rmover@golovolomka.net> --- ifmail v.2.15dev5.3 * Origin: Leninsky 45 home network (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.perl/11477ebdb6f5d.html, оценка из 5, голосов 10
|