☰

Шах и мат о сертификатах TLS в локальных сетях, самоподписанных сертификатах и ​​CA

tag-icon • tag-icon vpn ssl certificate https tls
Шах и мат о сертификатах TLS в локальных сетях, самоподписанных сертификатах и ​​CA

Я почти ничего не знаю о сертификатах SSL и TLS. Извините за это.

Вот о чем меня спросила моя компания:

  1. Им необходимо разместить сервер в локальной сети, к которому будут иметь доступ через VPN люди по всей стране.
  2. Они хотят, чтобы этот сервер взаимодействовал с использованием HTTPS.
  3. Они хотят, чтобы на сервере был сертификат TLS, созданный сертифицированным центром сертификации.
  4. Мне говорят, что это сервер Microsoft IIS.

Что я обнаружил на данный момент:

  1. невозможно иметь SSL-сертификат, созданный сертифицированным центром сертификации для интрасетевого сервера, адрес которого server.mydomain.localдоступен из Интернета.
  2. Единственным способом получить SSL-сертификат для этого сервера будет самоподписанный сертификат, но такие сертификаты, как iOS и т. д., не пользуются доверием. iOS ненавидит самоподписанные сертификаты, и их суть в том, что устройства iOS получают доступ к локальному серверу.

Мне нужно подтверждение моей правоты или, если нет, как решить эту проблему.

Спасибо

решение1

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

Центр сертификации занимается только проверкой права собственности на имя, которое будет указано в URL.НекоторыйТакие центры сертификации, как Let's Encrypt, обычно делают это, подключаясь к серверу через HTTP (хотя это уже не единственный вариант). Но многие другие центры сертификации позволят вам проверить только право собственности на весь домен (возможно, через записи Whois), а затем свободно выдавать сертификаты для любого поддомена, даже для поддоменов, у которых нет веб-сервера, или для тех, у которых нет ничего общедоступного, или даже для поддоменов, которые вообще не существуют.

Итак, я предполагаю, что у компании уже есть веб-сайт и, следовательно, публичное доменное имя. Есть несколько способов, которыми вы можете это сделать, в зависимости от того, что устраивает компанию:

  • Вы можете заставить сервер использовать обычный публичный IP-адрес и поместить его в DNS, как вы это обычно делаете... и просто заставить сервер отклонять все соединения, не осуществляемые через VPN, например, с помощью брандмауэра Windows или некоторых специфичных для IIS настроек.

    (Большинство систем VPN можно настроить на маршрутизацию любого диапазона IP-адресов через защищенный туннель, неважно, являются ли IP-адреса «публичными» или «частными». Маршрутизация диапазона публичных IP-адресов компании через корпоративный VPN — это обычная практика.)

  • Вы можете создать поддомен, указывающий на внутренний IP-адрес (например, это server.corp.mydomain.comможет быть публичный поддомен, указывающий на 192.168.7.1, частный IP-адрес, доступный только через VPN), и это все равно не помешает ему выдать общедоступный сертификат HTTPS.

    (Для этого не требуется ничего особенного с точки зрения настройки DNS, вы можете просто указать домен на любом желаемом вами адресе.)

  • Вы можете иметь фактический веб-сервер на частном IP-адресе, но использовать фронтенд-сервер "обратного прокси" на публичном IP-адресе. Обратный прокси может обрабатывать доступ на основе IP, а также SSO или аутентификацию по паролю. Он может даже обрабатывать выпуск сертификатов Let's Encrypt на основе HTTP от имени настоящего частного сервера.

    (Мы используем этот метод для предоставления безопасного HTTPS-доступа к некоторым устаревшим веб-приложениям — одно из них все еще работает на Server 2003 и вообще не может работать с современными браузерами; вместо этого обратный прокси-сервер обеспечивает необходимую поддержку TLS 1.2, а также аутентификацию SAML.)

(Есть и другие варианты. Помимо общедоступных центров сертификации, любой может создать свой собственный центр сертификации, и в большинстве корпоративных сетей, работающих с Microsoft AD, такой центр фактически будет. Единственная проблема — заставить устройства доверять этому центру сертификации, но для корпоративных iPhone это должно быть легко сделать через любую систему «управления мобильными устройствами», которую использует компания. Хотя не говорите людям устанавливать корпоративный центр сертификации на личных системах...)

Связанный контент