Скопилось довольно много внутренних http/https сервисов, которые необходимо публиковать наружу. Все сервисы разнообразные, на разных платформах. Сейчас все публикуется через MS TMG, частично через один публичный IP, с разделением по доменному имени. Но так как почти все сервисы насильно переводим на https, появляются сложности с генерацией и импортом сертификатов как на самом сервере, так и на TMG - этот же сертификат надо привязать к "прослушивателю". Отсюда практически отпадает воможность юзать lets encrypt, т.к. на сервере перевыпуск сертификата работает автоматом, а вот на TMG его надо руками импортировать и менять в прослушивателе.
Посему ищется бесплатное решение для публикации web сервисов, с возможностью заведения на нем всех поддоменов и получением для них сертификатов в lets encrypt или чтобы он не подставлял свой сертификат а перенаправлял сразу на конечный сервер. Ну и какими-нибудь дополнительными плюшками по защите, вроде ограничения количества сессий, блокировкой брутфорсов и тд.
Я пока с ним не сталкивался, как раз смотрел в его сторону, но пока не нашел ответа на некоторые моменты связанные с сертификатами. В частности, насколько сложно на нем реализовать мои хотелки.
Например у меня есть несколько внутренних серверов: OWA, RDWebAccess, веб-морда от 1С и тд. Соответственно наружу они опубликованы по именам mail.domain.ru, terminal.domain.ru и тд. Часть серверов сами/автоматом получают с lets encrypt сертификаты и ставят их себе. Можно ли перенести эту роль на nginx, чтобы они подставлял нужный сертификат? Нужно ли при этом на самих серверах получать сертификаты?
Внешних IP несколько, но не хватает на все внутренние сервисы, т.е. надо что бы несколько поддоменов висело на одном IP. Отсюда появляется проблема с сертификатами, надо их как-то объединять.
RazorBlade: из того, что я прочитал в вопросе, nginx может если не всё, то почти всё.
На нём можно поднять несколько SSL серверов (инстанций), на каждый из которых назначит свой ssl сертификат, клиент обращаясь к его порту, средствами расширения SNI к протоколу SSL сообщает серверу, с каким доменом он будет общатся, NGINX в этом случае отдаёт нужный сертификат сервера и процедура установления SSL сессии продолжается.
От NGINX до вашего внутреннего ресурса можно держать обычное HTTP соединение.
Этот режим работы называется обратный прокси и он очень подробно описан в тысячах документаций и работает отлично с дефолтными настройками. Требуется лишь, положить на NGINX сервер открытые и закрытые ключи и создать записи в конфигурационных файлах nginx где для каждого домена будут указаны сертификаты (и ключи) и адрес конечного сервера, на который осуществлять проксирование. Опционально можно сделать прозрачный http -> https редирект для тех пользователей, чьи браузеры идут небезопасно.
RazorBlade: ответил выше. Да, на одном IP можно держать сколько угодно SSL доменов, до конечных серверов будет идти HTTP без шифрования, с поддержкой балансировки и кеширования.
RazorBlade: все ваши вопросы - это какой-то каменный век, честное слово. Видны костлявые руки мелкомягких.
Все нормальные веб-серверы (и nginx, разумеется) уже не первый десяток лет умеет SNI. И для Let`s Encrypt давно написана масса врапперов, самостоятельно обновляющих сертификаты сайтов - вам остаётся только добавить задание в планировщик.
ky0: не ругайте, да обруганы не будете. И кто никогда не юзал софт от майкрософта - пусть первый кинет в меня камень (желательно i7 и с индексом "k").
Обычная ситуация в обычной конторе (скорее всего ГОС), закупили софт в прошлом веке, имеют большой контракт с MS, стоит TMG никого не беспокоит, но вот настало время перемен и прошлый ИТ директор ушёл (умер, на пенсии, спился, укажи свою причины).
Евгений Быченко: обычная контора и госконтора - это не синонимы, а совсем даже наоборот. В условиях нашей извращённой экономики использование заведомо менее выгодных решений (например, платных при наличии бесплатных той же функциональности) - это распространённое явление, но лично я этому потакать не собираюсь; отсюда и первый абзац моего предыдущего комментария. А ротацию директоров стоит ускорить, раз только после ухода кого-то на пенсию начинается внедрение актуальных технологий :)
ky0: ну блин, вы не по адресу, мой ответ на ваш коммент - это предположения. Если RazorBlade что-то скажет на этот счёт будет интересно, но к ответу отношение иметь не будет.
ky0: Ну уж извините, что не все разбираются в нормальных веб-серверах. Пинать тут на MS негоже.
Разводить флейм на тему opensource тоже не вижу смысла. Для каждого случая, свои решения.
Лучше бы кинули ссылку на один из многочисленных мануалов по моему вопросу.
RazorBlade: это всё что нужно прописать в конфиге и положить ключи. Бакенд меняете на что-то своё. Тестируете, выставляете nginx наружу, меняете DNS, добавляете новый сервер в конфиг, новые ключ, и так по кругу.
Достойная альтернатива Nginx в вашей ситуации - HAProxy.
А коли TMG всем устраивает - можете там и продолжать на нём сидеть, а геморрой с сертификатами решить переходом на wildcard-сертификат.
