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