Комментарии 20
Имхо, такой подход неверен. Для локальной разработки лучше выпустить самоподписанный сертификат и добавить его в исключения браузера. Следующий этап - не выставление Томката в интернет, а добавление к приложению веб-сервера, который и будет заниматься терминированием шифрования, помимо прочего.
Самый просто способ для меня был Cloudflare, бэкенд на субдомен с https, фронт на домен с https. Бесплатно, красиво имеем защиту, кэш фильтры.
Можно конечно и все selfhosted.
Зачем? Пусть прокси сервер слушает https с настроенными сертами. А спирнг в котейнере крутиться.
Без привязанного к вашему серверу домена вы не сгенерируете сертификат.
Это не обязательно, есть режим генерации сертификата с использованием DNS. Всё что нужно, это иметь возможность управлять DNS записями вручную или с помощью API, если DNS хостинг предоставляет такую возможность. Для генерации сертификата через DNS даже не надо привязывать домен к IP. И еще большой плюс такой генерации - можно создать wildcard сертификат, например, для *.vashdomen.ru
можно создать wildcard сертификат, например, для *.vashdomen.ru
Который скормить например haproxy, через который и кидать на нужный бэкенд в зависимости от запрашиваемого домена. И это более правильное решение.
А вот wildcard на стороне запросов DNS (чтобы не прописывать адреса для всех поддоменов) не все серверы поддерживают.
А вот wildcard на стороне запросов DNS (чтобы не прописывать адреса для всех поддоменов) не все серверы поддерживают.
Вот если честно, то это должен быть совсем дешманский DNS хостинг, чтобы не мог поддерживать wildcard записи
А вот wildcard на стороне запросов DNS (чтобы не прописывать адреса для всех поддоменов) не все серверы поддерживают.
Вообще я затупил. Причем тут wildcard DNS записи к генерации wildcard сертификата? При генерации сертификата через DNS нужно добавить у провайдера TXT запись, которую попросит certbot. А A-записей может вообще не быть у провайдера, их хоть в /etc/hosts добавляй вручную
Причем тут wildcard DNS записи к генерации wildcard сертификата?
Ну, то что не нужно на DNS создавать записи типа site1.domain site2.domain site3.domain указывающие на один и тот же IP, а можно создать *.domain и при запросе любого поддомена будет указывать на один и тот же IP.
Для генерации wildcard сертификата не нужно создавать A-записи вида *.example.com, либо любую другую для отдельных доменов. certbot просит создать TXT и вставить содержимое, которое он даст. Например,
# certbot certonly --manual --preferred-challenges dns -d *.nekij-domen.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for *.nekij-domen.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name:
_acme-challenge.nekij-domen.com.
with the following value:
5pt0CXrH_icMfYXLae-jmGZV6SxZohQVWrrZ3pyYKyk
Обратите внимание, что домен на текущий момент даже не зарегистрирован, но certbot предлагает создать TXT запись _acme-challenge.nekij-domen.com с содержимым 5pt0CXrH_icMfYXLae-jmGZV6SxZohQVWrrZ3pyYKyk
Т.е. можно сгенерить wildcard сертификат, а домены создавать одиночные, не обязательно создавать wildcard DNS запись. Например, site1.example.com на одном сервере размещается, site2.example.com на другом с соответствующими A-записями, а сертификат можно один и тот же забросить на эти два сервере
а при чем тут Spring ?!
Ходить на бекенд по хттпс это все же извращение. Хттпс это трата допресурсов, на хайлоаде это стрелять себе дуплетом в обе ноги сразу. Бекенд должен работать внутри периметра, а там хттпс как бы не особо нужен.
Все истории про бекенд через хттпс которые я слышал, были связаны с вынужденным (внезапным) переносом бекенда куда то в другой ДЦ и это скорее исключение, чем норма.
Сразу три антипаттерна. Терминирование TLS (Level 6) сервисом (Level 7), отсутствие автообновления сертификата, выставление сервиса в публичный Интернет без базовой защиты от атак.
Перевод Spring Boot приложения с HTTP на HTTPS без ругани браузера