ошибка сертификата SSL при выполнении ВИХРЕВОГО запроса к IP-адресу
Я пытаюсь отправить ВИХРЕВОЙ запрос к серверу с IP-адресом x.x.x.x. Это - часть медицинской системы контроля. На сервере я настроил виртуальные хосты к subdomain.example.com и на порте 80 и на 443. Для сертификата SSL я использую Wildcard-сертификат *.example.com, который я использую на этом сервере также еще немного серверов.
Когда я пытаюсь завихриться к http://x.x.x.x это получает ответ соответственно. Но когда я завихряюсь к https://x.x.x.x это дает следующую ошибку сертификата:
завихрение: (51) SSL: имя предмета сертификата '*.example.com' не соответствует названию целевого узла 'x.x.x.x'
Я знаю, что это вызвано тем, что сертификат характерен для доменного имени, и я пытаюсь отправить запрос с помощью IP-адреса. Но поскольку я сказал, что это - ограничение, которое я имею (rackspace медицинский контроль подсистемы балансировки нагрузки).
Вокруг существует ли работа??
Я сделаю этот ответ новым, так как он идет в совершенно другом направлении. На самом деле, это не ответ на поставленный вопрос, но, возможно, это направление, в котором должен двигаться OP.
Обычная конфигурация при использовании балансировщика нагрузки заключается в том, что SSL сертификат вообще не живет на веб-сервере, а скорее SSL передается балансировщику нагрузки.
Конечный пользователь делает HTTPS запрос к балансировщику нагрузки. Балансировщик нагрузки разворачивает SSL и передает запрос через незашифрованный HTTP на веб-сервер с заголовком, который говорит веб-серверу, что оригинальный запрос был зашифрован. (важно для встраивания URL-адресов в ответ, а также для того, чтобы избежать обслуживания защищенного содержимого по http)
.Вы можете использовать доменное имя как обычно, но переопределить резольвер следующим образом:
curl -v --resolve subdomain.example.com:443:x.x.x.x https://subdomain.example.com/
Однако, может быть неудобно поддерживать много таких отображений. Вы можете просто проигнорировать несоответствие cert:
curl --insecure https://subdomain.example.com/
IF вы хотите, вы можете использовать --insecure --verbose и разобрать сообщения, чтобы проверить, что cert предназначен для ожидаемого домена, но это, вероятно, более трудоемко, чем использование --resolve