Как сертифицировать локальный сервер?SSL / TLS HTTPS - PullRequest
0 голосов
/ 18 октября 2018

Приквел: Я создал веб-приложение, которое должно взаимодействовать с веб-сайтом нашей компании.Я работаю удаленно от другого разработчика (другой филиал компании), который заботится о сайте.Я совершенно новичок в веб-разработке и не имею опыта работы.

Мое приложение работает на локальном сервере компании с использованием tomcat 8.5.На веб-сайте компании есть HTML-страница, которая загружает различные файлы JavaScript (& css) с моего Сервера.Там происходит взаимодействие с моим приложением.Раньше я делал это по HTTP, и все работало нормально.Например:

<script src="http://172.17.123.123/MyProject/js/script.js"></script>

Проблема: Теперь разработчик сказал мне, что я должен получить сертификат и использовать HTTPS, чтобы сделать связь между моим сервером и веб-сервером компании более безопасной.Это то, что он делает, так как веб-сайт, которым он управляет, доступен в Интернете, и он может легко создать сертификат из доверенного центра сертификации.Он не знал, как это сделать для локального сервера.

Мне удалось включить HTTPS и использовать самозаверяющий сертификат.Сейчас я использую

<script src="https://172.17.123.123:8443/MyProject/js/script.js"></script>

, но получаю эту ошибку:

Не удалось загрузить ресурс: net :: ERR_CERT_AUTHORITY_INVALID

Я хочу использоватьсертификат для моего сервера из ЦС, но читайте о том, что получить его для localhost невозможно.Но я ничего не нашел о локальном сервере.Я предполагаю, что применяется тот же принцип.

Вопрос: Выгодно ли использовать HTTPS для связи между веб-сервером и сервером локальной компании?Если да, как я могу создать доверенный сертификат?Будет ли достаточно самоподписанного сертификата?

1 Ответ

0 голосов
/ 18 октября 2018

Вы говорите об обмене данными между вашим сервером и веб-сервером, но их нет;веб-сервер передает страницу в браузер , которая содержит ссылки на ресурсы на вашем сервере, поэтому браузер связывается с вашим сервером, и именно браузер не доверяет вашейподписанный сертификат.

HTTPS для связи между браузером и вашим сервером выгоден , если сеть между браузером и вашим сервером либо фактически небезопасна (например, включает в себя DMZ или другую ненадежную зону, либо небезопасную ссылку)или должны рассматриваться как ненадежные (например, обработка данных платежной карты в соответствии с PCI DSS).Невозможно оценить это по информации, которую вы предоставили, и ваша компания почти наверняка не должна позволять вам публиковать информацию, которая сделает это возможным - плюс она не будет никому полезна, что противоречит StackExchangeфилософии.Вам следует проконсультироваться с людьми, отвечающими за безопасность в сети вашей компании, относительно того, требуется ли HTTPS, и, возможно, какие варианты возможны, и что они могут поддержать или помочь.

Это правда, что вы не можете получитьпублично доверенный сертификат для localhost, но это не имеет значения, потому что вы не используете localhost.Вы используете частный (rfc1918) адрес, называемый «интранет», который сильно отличается, но вы также не можете получить публично доверенный сертификат для них.

Возможные технические варианты:

  • использовать самоподписанный сертификат (для адреса) и настроить каждый браузер, который будет использовать это приложение, для доверия этому сертификату.Это может варьироваться в зависимости от того, какими будут ваши пользователи и сколько их.Если все они находятся в присоединенной к домену Windows и используют IE / Edge или Chrome, но не Firefox, центральные администраторы могут просто создать объект групповой политики, который «выдвигает» сертификат, и все готово.Если на десятках платформ и по всему миру их тысячи, вам, возможно, придется потратить месяцы усилий на то, чтобы обучить и помочь всем им импортировать сертификат, возможно, в том числе заставить людей переводить на иностранные языки.

    В случае, если вы еще не знаете, если кто-то из ваших пользователей использует Chrome, сертификат должен иметь имя авторизации, здесь адрес, в альтернативном имени субъекта (SAN) , а также CommonName субъекта.Другие браузеры в настоящее время не требуют этого, но могут сделать это в будущем, потому что это уже давно является политикой CABforum.Многие инструменты, обычно используемые для создания самоподписанных сертификатов, такие как командная строка OpenSSL и Java keytool, не делают этого автоматически.(Публичные центры сертификации делают это.) На этот счет уже есть много вопросов, их можно искать, если это применимо.

    Также для этого подхода, если вы еще не знаете, следует убедиться, что назначенный адрес останется стабильным.Некоторым сетям компаний необходимо время от времени перераспределять свои адреса адресов, по причинам, таким как открытие, расширение или закрытие офисов, перенос крупных проектов и т. Д. Если тысячи людей вынуждены повторять импорт незнакомых и непонятных сертификатов несколько раз в год,вы станете довольно непопулярным.

  • получите (суб) доменное имя для вашей системы в домене компании, которое разрешает во внутренней сети компании только в адрес вашего компьютера- эта резолюция не должна быть и не должна быть публичной.Затем получите публично доверенный сертификат для этого имени субдомена.LetsEncrypt с использованием DNS-01 может выдать вам сертификат для доменного имени, даже если ни одна система, использующая это доменное имя, недоступна из общедоступного Интернета, если вы контролируете DNS для него.OTOH, если ваша компания уже имеет веб-сайт и имеет сертификаты, у нее должен быть уже установлен процесс для их получения;об этом должны знать сотрудники службы безопасности сети, о которых я упоминал выше.

...