libcurl ssl сертификаты

Вот хорошие комментарии к параметрам cURL: http://php.ru/manual/function.curl-setopt.html

Попробуй ещё код на питоне отсюда, если что-то не получится.

c = pycurl.Curl()
c.setopt(pycurl.URL, FirstDataAPI_URL)
c.setopt(pycurl.HTTPHEADER, ["Accept:"])
c.setopt(pycurl.POST, 1)
c.setopt(pycurl.POSTFIELDS, urllib.urlencode(FirstDataAPI_PostData))
import StringIO
b = StringIO.StringIO()
c.setopt(pycurl.WRITEFUNCTION, b.write)
c.setopt(pycurl.FOLLOWLOCATION, 1)
c.setopt(pycurl.MAXREDIRS, 5)
c.setopt(pycurl.SSLCERT, '/home/dgiftcard/disney/ssl/digitalID.p12')
c.setopt(pycurl.SSLCERTPASSWD, 'xxx')
c.setopt(pycurl.SSLKEY, '/home/dgiftcard/disney/ssl/digitalID.pem')
c.setopt(pycurl.SSLKEYPASSWD, 'xxx')
c.perform()
results = b.getvalue()

а digitalID.p12 и digitalID.pem это что?

сам генеришь или кто-то выдаёт?

Я SSL знаю только на уровне ssh-keygen && ssh-add.
Но как понял, SSLKEY - закрытый ключ (навроде ~/.ssh/id_rsa), SSLKEYPASSWD - пароль который ты задавал при генерации, SSLCERT - открытый ключ какого-то корневого сервера, и SSLCERTPASSWD - пароль от этого ключа (сертификата) [я правда не понимаю зачем он]. Я в криптографии полный ноль, поставь лучше правильный тэги к теме - «криптография», «openssl».

таториал сначала почитай: https://tools.ietf.org/html/rfc5280

глупые вопросы отпадут сами собой

алсо, неосиляторов переписи тред

просто в примере видно, что используются 3 каких то файла, у тебя два

только не понятно, что такое «testcert.pem», «cacert.pem» и «testkey.pem»;

testcert.pem - клиентский сертификат

testkey.pem - клиентский приватный ключ

cacert.pem - сертификат CA, которому мы решили доверять.

И, да, тебе правильно посоветовали - иди читать про основы SSL и PKI.

Жестковато для tutorial.

Я SSL знаю только на уровне ssh-keygen && ssh-add.

SSH и SSL никак не связаны. Кроме того, что и там и там используется асимметричное шифрование.

этого я уже обчитался, вот и колбасит, потому что бы не делал, не работает

вот генерирую сертификат и ключ

openssl req -x509 -newkey rsa:2048 -days 365 -keyout private-key.pem -out certificate.pem

вот делаю curl запрос с ключём

curl https://89.108.107.117/ -D -  -E ssl/private-key.pem:98789  --trace -

== Info: Hostname was NOT found in DNS cache
== Info:   Trying 89.108.107.117...
== Info: Connected to 89.108.107.117 (89.108.107.117) port 443 (#0)
== Info: unable to use client certificate (no key found or wrong pass phrase?)
== Info: Closing connection 0
curl: (58) unable to use client certificate (no key found or wrong pass phrase?)

вроде бы всё перепробовал, не получается по https достучаться туда, а браузером получается

вот делаю curl запрос с ключём

А сертификат curl будет передавать Пушкин? -E подразумевает, что в этом файле и сертификат и ключ. Есть опции --cert и --key, которые позволят задать ключ и сертификат через разные файлы.

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

причём всё что она генерирует можно называть сертификатом, только не тем который нужен для результата, а потом бинго, с другой стороны выясняется, что тот приз который ты выиграл в локальном лохотроне не совместим с лохотроном удалённым

у меня такое ощущение будто эта технология создана напёрсточниками

У меня такое ощущение, что ты мозг напрягать не хочешь. Поверь, вся эта сложность во многом не потому, что разработчики дебилы, а потому, что предметная область реально сложная и упростить ее сильно не получается. Поэтому либо прикладываешь усилия и учишь матчасть, либо идешь работать в другую область.

а чего сложного было не сваливать все яйца в одну кучу?

иначе, что мешало соединить вместе: vim+tar+mc+gzip+wget+htop+cat+httpd и не называть .tar например .zip или .py например .txt

видимо хороший вкус мешал