forum.opennet.ru

Составление сообщения

Исходное сообщение

"Stunnel конфигурация"
Отправлено Licha Morada, 05-Мрт-20 03:16

> Причём если я правильно понимаю, то это ошибка уровня приложения, а не
> уровня SSL:
> <html> <head> <title>Invalid Cert</title> </head>CN=heresCN,OU=heresOU,O=HeresO,C=US
> is not valid on this url</html>
Если это приехало в качестве контента для cURL, значит клиент и сервер договорились о HTTP, значит у них получилось SSL. Код ответа, случайно, не 403? По смыслу содержимого, похоже на творчески выраженную ошибку аутентикации по сертификату.
> Собственно, в чём вопрос. В чём может быть разница между SSL соединением
> которое иницирует cURL и соединением, которое делает stunnel? Они же должны
> идентично отрабатывать?
Либо cURL втихаря какие-то свои хедеры прицепляет когда HTTPS, либо сервер... уж не знаю что он может насамодельничать.
> В какую сторону копать?
Надо бы посмотреть в лог веб сервера и в лог приложения.
Ещё может помочь сделать дамп переменных окружения на сервере, либо посмотреть на хедеры, как запроса так и ответа (--verbose в помощь), в случае HTTPS напрямую и в случае stunnel.
Это обшие соображения, сам я на такое поведение не напарывался. Мы, обычно, вместо stunnel сразу обратный прокси на Nginx пихаем. Оверкилл, но ни разу не было чтоб критично по ресурсам оказывалось. С другой стороны, "мы" это инфраструктура, аутентикация на уровне приложения, даже по сертификату, проходит мимо.

Исходное сообщение
"Stunnel конфигурация" Отправлено Licha Morada, 05-Мрт-20 03:16
> Причём если я правильно понимаю, то это ошибка уровня приложения, а не > уровня SSL: > <html> <head> <title>Invalid Cert</title> </head>CN=heresCN,OU=heresOU,O=HeresO,C=US > is not valid on this url</html> Если это приехало в качестве контента для cURL, значит клиент и сервер договорились о HTTP, значит у них получилось SSL. Код ответа, случайно, не 403? По смыслу содержимого, похоже на творчески выраженную ошибку аутентикации по сертификату. > Собственно, в чём вопрос. В чём может быть разница между SSL соединением > которое иницирует cURL и соединением, которое делает stunnel? Они же должны > идентично отрабатывать? Либо cURL втихаря какие-то свои хедеры прицепляет когда HTTPS, либо сервер... уж не знаю что он может насамодельничать. > В какую сторону копать? Надо бы посмотреть в лог веб сервера и в лог приложения. Ещё может помочь сделать дамп переменных окружения на сервере, либо посмотреть на хедеры, как запроса так и ответа (--verbose в помощь), в случае HTTPS напрямую и в случае stunnel. Это обшие соображения, сам я на такое поведение не напарывался. Мы, обычно, вместо stunnel сразу обратный прокси на Nginx пихаем. Оверкилл, но ни разу не было чтоб критично по ресурсам оказывалось. С другой стороны, "мы" это инфраструктура, аутентикация на уровне приложения, даже по сертификату, проходит мимо.

Ваше сообщение

Имя*:

EMail:

Для отправки новых сообщений в текущей нити на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.

Заголовок*:

Сообщение*:

>> Причём если я правильно понимаю, то это ошибка уровня приложения, а не 
>> уровня SSL: 
>> <html> <head> <title>Invalid Cert</title> </head>CN=heresCN,OU=heresOU,O=HeresO,C=US 
>> is not valid on this url</html>

> Если это приехало в качестве контента для cURL, значит клиент и сервер 
> договорились о HTTP, значит у них получилось SSL. Код ответа, случайно, 
> не 403? По смыслу содержимого, похоже на творчески выраженную ошибку аутентикации 
> по сертификату.

>> Собственно, в чём вопрос. В чём может быть разница между SSL соединением 
>> которое иницирует cURL и соединением, которое делает stunnel? Они же должны 
>> идентично отрабатывать?

> Либо cURL втихаря какие-то свои хедеры прицепляет когда HTTPS, либо сервер... уж 
> не знаю что он может насамодельничать.

>> В какую сторону копать?

> Надо бы посмотреть в лог веб сервера и в лог приложения.
> Ещё может помочь сделать дамп переменных окружения на сервере, либо посмотреть на 
> хедеры, как запроса так и ответа (--verbose в помощь), в случае 
> HTTPS напрямую и в случае stunnel.

> Это обшие соображения, сам я на такое поведение не напарывался. Мы, обычно, 
> вместо stunnel сразу обратный прокси на Nginx пихаем. Оверкилл, но ни 
> разу не было чтоб критично по ресурсам оказывалось. С другой стороны, 
> "мы" это инфраструктура, аутентикация на уровне приложения, даже по сертификату, проходит 
> мимо.

При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру