Рейтинг:0

Нечетная ошибка TLS при использовании curl на исходном сервере x.509

флаг in

Я надеюсь, что кто-то может помочь объяснить, что происходит в этой ситуации.

На данный момент у меня есть домен из доменов Google, и я использую cloudflare для управления DNS. Я не использую никаких функций TLS/SSL от cloudflare, универсальный SSL отключен, а также не проксирую свои DNS-запросы. Я использую caddy в качестве обратного прокси-сервера на своем сервере, и я использую встроенный клиент acme, который получает сертификаты от letsencrypt. Я получаю сертификаты в порядке, и все мои внешние сайты показывают используемый сертификат, который находится на моем сервере. Однако, когда я запускаю завиток команду на моем сервере через HTTPS, я получаю это странное поведение:

Чтобы объяснить больше, я пытаюсь отправить запрос на завивание на мой сервер/экземпляр gotify. Вот результат, когда я использую команду gotify cli получить инициализацию затем я ввожу свой домен с помощью https:// и получаю этот вывод (это происходит для всех моих доменов (когда я запускаю основные команды curl ниже после команды gotify), но просто использую gotify cli в качестве примера того, где ошибка происходит от):

x509: сертификат недействителен ни для одного имени, но хотел, чтобы он соответствовал gotify.mydomain.com

Итак, я запускаю эти команды curl, чтобы выяснить, что происходит.

Команда: curl -v https://gotify.mydomain.com Вывод:

* ALPN, предлагая h2
* ALPN, предлагающий http/1.1
* успешно установить места проверки сертификата:
* CA-файл: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), рукопожатие TLS, приветствие клиента (1):
* TLSv1.3 (IN), рукопожатие TLS, приветствие сервера (2):
* TLSv1.2 (IN), рукопожатие TLS, сертификат (11):
* TLSv1.2 (OUT), оповещение TLS, неизвестный ЦС (560):
* Проблема с сертификатом SSL: самоподписанный сертификат
* Закрытие соединения 0
curl: (60) Проблема с SSL-сертификатом: самозаверяющий сертификат
Подробнее здесь: https://curl.se/docs/sslcerts.html

curl не смог проверить легитимность сервера и поэтому не смог
установить с ним безопасное соединение. Чтобы узнать больше об этой ситуации и
как это исправить, пожалуйста, посетите веб-страницу, указанную выше.

Мой CApath буквально имеет все сертификаты из пакета ca-certificates. И мои внешние сайты используют мой сертификат, но у моего сервера проблемы, и я не знаю, почему.

Когда я запускаю эту команду curl -v --insecure https://gotify.mydomain.com Я получаю еще более странные результаты: Вывод:

* ALPN, предлагая h2
* ALPN, предлагающий http/1.1
* успешно установить места проверки сертификата:
* CA-файл: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), рукопожатие TLS, приветствие клиента (1):
* TLSv1.3 (IN), рукопожатие TLS, приветствие сервера (2):
* TLSv1.2 (IN), рукопожатие TLS, сертификат (11):
* TLSv1.2 (IN), рукопожатие TLS, обмен ключами сервера (12):
* TLSv1.2 (IN), рукопожатие TLS, сервер готов (14):
* TLSv1.2 (OUT), рукопожатие TLS, обмен ключами клиента (16):
* TLSv1.2 (OUT), изменение шифрования TLS, изменение спецификации шифрования (1):
* TLSv1.2 (OUT), рукопожатие TLS, Готово (20):
* TLSv1.2 (IN), рукопожатие TLS, Готово (20):
* SSL-соединение с использованием TLSv1.2/ECDHE-RSA-AES128-GCM-SHA256
* ALPN, сервер не согласен с протоколом
*Сертификат сервера:
* Тема: C=CN; СТ=ТВ; Л=ТБ; О=АККЕЙ; НУ=МАРШРУТИЗАТОР; CN=askey.com; адрес электронной почты[email protected]
* дата начала: 8 января 18:43:23 2022 по Гринвичу
* срок действия: 7 января 18:43:23 2025 GMT
* эмитент: C=CN; СТ=ТВ; Л=ТБ; О=АККЕЙ; НУ=МАРШРУТИЗАТОР; CN=askey.com; адрес электронной почты[email protected]
* Результат проверки SSL-сертификата: самоподписанный сертификат (18), продолжение в любом случае.
> ПОЛУЧИТЬ/HTTP/1.1
> Хост: gotify.mydomain.com
> Пользовательский агент: curl/7.74.0
> Принять: */*
>
* Отметить комплект как не поддерживающий многоразовое использование
< HTTP/1.1 302 Найдено
< Местоположение: /1.2.4/login.html
< Длина содержимого: 0
< Дата: воскресенье, 24 апреля 2022 г., 13:51:04 по Гринвичу
< Сервер: lighttpd/1.4.38
<
* Соединение №0 с хостом gotify.mydomain.com осталось нетронутым

Совершенно не знаю, откуда взялся этот сертификат «аски». Он нигде не находится на моем сервере AFAIK. Я в замешательстве. Я нахожусь на Тайване, поэтому код TW может иметь небольшой смысл. У меня даже не было удаленного доступа к моему серверу 8 января, поэтому я не знаю, что произошло.

когда я вижу это Расположение: /1.2.4/login.html это заставляет меня думать, что что-то происходит с моим маршрутизатором. Потому что это путь к моей странице входа администратора маршрутизатора.

anx avatar
флаг fr
anx
Довольно часто беспроводные точки доступа [вынуждают вас выполнить какое-либо действие] (https://en.wikipedia.org/wiki/Captive_portal), вмешиваясь во все без исключения ваши соединения, пока вы не подчинитесь. Ваш [браузер может знать](http://detectportal.firefox.com/canonical.html), как с этим справиться автоматически.
Steffen Ullrich avatar
флаг se
Askey — тайваньский производитель маршрутизаторов. То, что вы показываете, указывает на [портал захвата] (https://en.wikipedia.org/wiki/Captive_portal) такого маршрутизатора, который вам нужно пройти, прежде чем вы сможете получить доступ к Интернету.
Alex Zoller avatar
флаг in
Но я в замешательстве, мой исходный сервер находится в США. Ошибка не должна иметь ничего общего с моими клиентскими подключениями, верно? Я просто подключаюсь к своей машине по SSH и запускаю эти команды. Я загляну в пленный портал, я полагаю
Alex Zoller avatar
флаг in
Я понимаю, что сейчас происходит. По сути, я пытаюсь получить доступ к своему внешнему/общедоступному IP-адресу (через мой домен, который указывает на мой внешний IP-адрес/маршрут) внутри той же сети, где находится мой сервер, что не сработает. Мне нужно будет настроить dnsmasq или что-то еще, чтобы переписать.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.