Доброго времени суток. Подскажите пожалуйста, возможно ли заставить работать JSON-RPC через HTTPS протокол? Или, возможно есть какой-то иной способ шифровать трафик между клиентом и сервером?

В данный момент использую вот эту библиотеку: https://github.com/sergeyfast/eazy-jsonrpc

При работе через HTTP - всё работает ровно, при попытке пропустить запрос через HTTPS - результат просто не возвращается.

Ну вообщето JSON-RPC это протокол формата передачи данных, а HTTPS это ближе к транспортному протоколу.
А где глохнет ответ? И получает сервер пакет данных?

Это сообщение отредактировал(а) Sentox - 25.9.2012, 22:06

Я понимаю, что вопрос звучит несколько странно, но факт имеет место быть (по HTTP - работает, по HTTP'S - нет).

Всё остальное в рамках этого же сервера работает нормально. Сейчас попробую выяснить, на каком именно моменте всё "глохнет".

Сейчас посмотрел у себя, работает JSON с SSL норм. Никаких сбоев нет.
Сервер поддерживает SSL? PHP ...

Это сообщение отредактировал(а) Sentox - 25.9.2012, 23:58

Sentox, да, самое смешное в том, что работает всё, кроме JSON по HTTP's протоколу именно (он же, по протоколу HTTP - работает нормально). Сейчас пытаюсь получить обратно доступ к серверу, что бы посмотреть, возможно ошибка где-то внутри самого сервера...

Добавлено через 10 минут и 25 секунд
P.S. На самом сервере, лежат несколько HTML-страниц, они так нормально открываются как по HTTP, так и по HTTP'S.

Да, стоит логи изучить.

Я нашел ещё 1 сервер (доступ к серверу о котором речь шла изначально, к сожалению утерян). Проблема абсолютно аналогичная:
Вариант 1: протокол HTTP - получаем ответ
Вариант 2: добавляем букву S к HTTP, и сервер не отвечает...

Пример (не) рабочего исходника прикрепляю к письму.

Если в исходном коде, на строке #5, заменить "http://" на "https://", ответ от сервера, мы почему-то перестаём получать.

Добавлено @ 09:45
Только что пересмотрел логи обоих серверов, ошибок нет. На сервере который выполняет роль клиента (подключается к удалённому серверу, отправляет запрос, получает ответ), включил полное отображение ошибок - ошибок нет.

P.S. Задача заключается в том, что бы ВЕСЬ трафик по маршруту "Клиент <-> Сервер" шифровался, соответственно для этих целей, я выбрал SSL (https://). Не думаю, что это поможет, но на всякий случай я уже заказал коммерческую версию сертификата от Comodo. Сегодня постараюсь заменить этот "палёный" сертификат, на "фирменный".

Добавлено @ 09:46
Если есть какой-то более простой, правильный или логичный вариант шифрования трафика между клиентом и сервером - подскажите пожалуйста.

Это сообщение отредактировал(а) WolfAlone - 28.9.2012, 09:52

Присоединённый файл ( Кол-во скачиваний: 3 )
 json_rpc.zip 1,97 Kb

Вот должно помочь. В опциях curl нужно добавлять.
http://unitstep.net/blog/2009/05/05/using-...rotected-sites/

Sentox, скажите пожалуйста, эта проблема решается ещё как-то, кроме как установкой параметра: "отключить проверку сертификата"? Если к сервису будут подключаться "внешние" клиенты, я не смогу каждому лично объяснить, что "нужно отключить проверку сертитфиката в вашем cURL..." и т.д.

Возможно ли решить этот вопрос как-то иначе, например покупкой какого-либо "доверенного" для cURL сертификата?

Добавлено через 2 минуты и 55 секунд
Если например, сертификат браузер кушает без проблем (последний сертификат который я покупал - Comodo PositiveSSL), какова вероятность, что cURL "скушает" его и не нужно будет ничего отключать или ещё как-то менять его настройки?

Там же есть решение с проверкой сертификата. Просто потребуются некоторые настройки на клиенте, друго пути нет, как указать же расширению где его брать.


Можно сделать конфигурационный параметр в классе где будет указываться путь к сертификату.

Если "внешние" клиенты так же програмные, понятное дело стоит и им указывать сертификат для проверки.

Это сообщение отредактировал(а) Sentox - 28.9.2012, 18:11

Sentox, спасибо большое за консультацию, решения действительно помогли.

Напоследок, жду пока оформят сертификат. Хочу всё-таки проверить результат с нормальным сертификатом (не самопальным).

Вчера консультировался со специалистом по SSL. PHP и особенности работы cURL он к сожалению не знает, но по логике вещей, при использовании "платного" сертификата, выше описанная проблема должна решиться сама собой.

О результатах применения "платного" сертификата, обязательно расскажу, возможно кому-то будет интересно.