Коллеги, приветствую! Появилась не совсем тривиальная задача реализовать в nginx

редирект HTTPS —> HTTP. Да, именно так, а не наоборот. Мы разрабатываем embedded устройство, на которое пользователь заходит по IP-адресу (как на какой-нибудь роутер), а не по доменному имени. Из-за тотального внедрения HTTPS во всех браузерах, зачастую они используют именно его по умолчанию, что, естественно, выливается в ERR_CONNECTION_REFUSED, т.к. listen 443 сейчас не прописано в конфиге nginx, только 80. Многих пользователей устройства это сбивает с толку.

Беглый поиск по интернетам дал два варианта решения проблемы, через rewrite и return:

server {
listen 443;
server_name _;
rewrite ^(.*) http://$host$1 permanent;
}

server {
listen 443;
return 301 http://$host$request_uri;
}

но ни один из них не заработал, в Chrome ошибка ERR_SSL_PROTOCOL_ERROR, curl пишет чуть подробнее:

nikita@MBP:~% curl -vv https://192.168.100.103/
* Trying 192.168.100.103:443...
* Connected to 192.168.100.103 (192.168.100.103) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* LibreSSL/3.3.6: error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version
* Closing connection 0
curl: (35) LibreSSL/3.3.6: error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version

Как я понимаю, трабла в том, что для установки SSL-коннекта нужны серт и ключ в конфиге... Но в нашем случае этих сертов нет! В инете предлагается либо сделать самоподписанный серт (что выльется в warning в браузере, не хочется такого), либо заюзать условный Let's Encrypt, что тоже не вариант, т.к. они не делают сертификаты для IP-адресов, да и IP у нас по факту может быть любой...

Одним словом, мне не нужен этот ваш хттпс, а если юзер и заходит по нему, надо его как-то перекинуть на HTTP. Как по вашему правильнее решить эту проблему?

Так в чем проблема сделать пропатчить так сказать nginx сертботом, и https запрос перенаправлять на http в nginx?)

Выдать юзеру ссылку с хттп://

В общем случае - никак, особенно если у вас embedded устройство с адресом в приватной сети. Вы имеете шанс поймать ситуацию, когда пользователь уже заходил ранее на этот ip по https, ему отдали там HSTS с таймаутом в полгода - и без очистки кэша браузера пользователь на http не попадет никак.

Понятно, печально( И раз у юзера будет включен HSTS, то даже с самоподписанным сертом зайти не удастся?

Удастся, но с руганью на сертификат. Но это краевой случай, на самом деле

Устройство вообще не умеет в https, или вы не хотите?

Как оно сможет уметь, если я его ещё не настроил) Вот как раз и пытаюсь понять, можно это вообще сделать или нет. А настроить проблема, т.к. мы не знаем точные SAN, для которых генерить сертификат, IP-адрес может быть любой. Мне интересно, как это на тех же роутерах реализовано (я сам хз, потому что почти везде микротики на которые я захожу через SSH), судя по всему, никак...

Группа пользователей у устройства определена или нет?

Посмотрите, как это сделано на всяких ipmi / oob железках. В 99% случаев там просто фуфлыжный сертификат, да еще и просроченный.

А так ли надо HTTPS в серых сетях? Если прям надо то пусть клиент сам сможет подсунуть свой серт, ключ и CA

Мол по дефолту HTTP, скормишь свои серты и ключ - будет и HTTPS и возможность отрубить http

если есть свой доверенный уц, то проблем особых нет

аккуратнее с портянками, есть pastebin.com

УЦ допустим есть, но он наш офисный, снаружи доступа к нему нет. Но даже если и вынести его в инет — устройство в 95 % случаев стоит в закрытой сети, у которой нет доступа в инет и соответственно к нашему УЦ.

Даже 10 строк уже портянка?)

а тогда в чём проблема-то, раз "во внутренней сети" ?

Возможно, возникло недопонимание... УЦ есть в нашей офисной сети, но устройства в продакшене стоят не у нас, а у клиентов по всей россии, и зачастую в закрытых контурах, не имеющих доступа в инет. Поэтому подключиться к нашему УЦ они не смогут.

а зачем им подключаться к уц?

Но иначе пользователям придётся явно добавлять наш CA root себе в систему?

не "иначе", а определённо

Тогда это не вариант и придётся видимо оставить всё как есть( Я всю эту тему завёл только ради того, чтобы юзерам удобнее было, а на секурити тут пофигу... Добавлять свои серты, это уже гемор. Кстати, а разве нет какой-то технологии, чтобы получать эти кастомные корневые сертификаты УЦ удалённо? Т.е. не закидывать руками в систему и прописывать как доверенный. Вроде же был какой-то протокол, но тут я уже сто проц в теме плаваю, так что просьба тряпками сразу не закидывать)) OSCP чё-та-там, или это не для этого?

Ocsp скорее всего вы слышали, он нужен для проверки сертификата, что он валидный. Он не получает рутовые сертификаты, не тянет их из уц, рутовые серты устанавливает производитель ОС системы, плюс вы зарукожопить можете и поставить шляпу какую-нибудь и доверять ей, ну либо кто-то за вас решит этот вопрос, получив рута(админа) от вашей системы. Без знания дела лучше не трогать. Лучше читать про PKI много и нужно, пока все не будет кристально понятно.

добавляется _один сертификат. уц-шный. в любом случае, у меня есть подозрение, что ты сам не очень понимаешь, что хочешь

Нет, я всё прекрасно понимаю, чего хочу, и это было описано в моём первом сообщении: просто сделать девайс более user friendly и избежать ошибки connection refused. Просто дальше уже обсуждение скатилось к собственным УЦ и корневым сертам, это я скорее для интереса и самообразования продолжил)) А ответ на свой вопрос я получил, что без костылей никак не реализовать то, что я хотел. Я ж поначалу гуглил и ничё внятного не нашёл, везде классика банальная http > https, а наоборот мало кому надо было, поэтому решил обратиться к комьюнити.