Неквалифицированный DNS с Nginx и SSL, зарегистрированный на полное доменное имя
У меня два сервера; один из них - «официальный» example.com сервер, на котором размещается мой общедоступный веб-сайт, а также почтовые серверы (bluehost.com). Второй - это мой частный LAN-сервер, на котором размещается мое приложение для торговой точки и общее приложение «менеджер».
На сервере example.com куплен и применен SSL с подстановочными знаками. Я хочу использовать этот сертификат для всех приложений, размещенных на частном сервере локальной сети, поскольку это доверенный сертификат, и все упомянутые приложения находятся в ведении одной компании. Я читал, что это просто вопрос копирования файлов закрытого и открытого ключей / сертификатов на мой сервер и настройки nginx для их использования. Я сделал это, но проблема заключается в том, что моя текущая схема URL ( http: // pos / и http: // manager / ) не соответствует домену подстановочного сертификата.
Непосредственным решением было бы заставить все серверы локальной сети nginx использовать более длинные URL-адреса (например, http: // pos. example.com ), однако я бы не хотел этого делать. Есть ли элегантное решение этой проблемы? Фактическое зарегистрированное доменное имя требует много времени для ввода на мобильных устройствах, и это только добавило бы путаницу моим сотрудникам, использующим приложения pos / manager.
Приведет к изменению суффикса подключения к моей локальной сети на , например. com чем-нибудь помочь?
Только одно из возможных решений. Настройте все так, чтобы внутренние устройства подключались к внутренним службам (pos, manager) через общедоступный IP-адрес (не 192.168.x.x) и общедоступное имя ( https://pos.example.com ). Разумеется, убедитесь, что общедоступный IP-адрес будет доступен только с ваших сайтов, а не из Интернета.
На вашем внутреннем nginx также добавьте постоянные перенаправления (HTTP 301) с http: // pos (внутренний IP-адрес ) на https://pos.example.com (общедоступный IP-адрес).
Недостатком этого решения является то, что трафик идет на один переход больше, чем это необходимо, и вам нужно быть осторожным с общедоступными IP-безопасность.
Преимущество состоит в том, что вам не нужно ничего менять на пользовательских устройствах (нет доверенных сертификатов вручную).
К сожалению, если вы это сделаете, вашим сотрудникам придется вводить полное доменное имя, как вы видели .
Возможно автоматическое перенаправление с http: // pos на https://pos.example.com , но не с https: // pos , поскольку согласование сертификата происходит до перенаправления. Альтернативой является добавление закладок и т. П.
Невозможно настроить систему для автоматического добавления имени домена к запросу браузера (хотя можно разрешить более короткое имя в полное имя, но это приведет к оставьте проблему с сертификатом).
Вы можете использовать внутреннююподписанный сертификат вместо этого, и, по моему опыту, большинство компаний справляются с этим. Поскольку вы создавали бы сертификат, он был бы бесплатным, и вы могли бы добавить как короткий домен, так и полностью определенный. Однако это будет означать, что вам нужно добавить эмитент сертификата во все ваши внутренние браузеры, что, в зависимости от вашей настройки, может быть нетривиальным. Особенно когда задействованы мобильные. В конечном счете, может быть проще просто приучить людей к полностью определенному доменному имени.
И я также согласен с тем, что лучше всего было бы не использовать видимый извне домен внутри компании. Может вызвать проблемы.