Здесь неприятная проблема ... надеюсь, кто-то еще видел это раньше, поэтому здесь:
Проблема: Я не могу открывать сайты https: // (SSL) из любых продуктов, работающих под управлением Server 2016. Все сайты без SSL открываются нормально.
Пытался: Перезагрузка.
Несколько браузеров: Chrome демонстрирует идентичные симптомы, поэтому это НЕ исключительная проблема IE.
Программное обеспечение, использующее SSL для связи (например, «Настройки Windows» -> «Обновления»), не работает. Просто запускается какое-то время, затем истекает время ожидания с сообщением «... не удалось подключиться к службе обновления ...».
Разрешение DNS в порядке (опять же, сайты без SSL открываются нормально). Пинг тех же SSL-сайтов разрешает / отвечает просто отлично.
sfc / scannow не вернул никаких проблем
Брандмауэр Windows отключен для всех профилей.
Очистка состояния SSL в IE (IE -> Параметры -> Контент -> [Очистить состояние SSL])
Сброс IE (IE -> Параметры -> Дополнительно -> [Сброс ...])
Пробовал с нескольких учетных записей пользователей, как администраторов, так и не администраторов. Все пользовательские профили демонстрируют одинаковые симптомы.
(Добавлено 16.01.18): ВСЕ другие физические системы и виртуальные машины на этом оборудовании / подсети получают доступ ко всем сайтам, как и ожидалось. ТОЛЬКО у этой ОДНОЙ виртуальной машины есть проблемы с SSL. Так что это не проблема брандмауэра / маршрутизатора (аппаратный брандмауэр настроен на разрешение ВСЕХ исходящих подключений).
Сценарий: Это рабочая виртуальная машина Server 2016, которая используется для размещения служб RemoteApps, поэтому другие мои пользователи могут запускать такие программы, как QuickBooks, за пределами предприятия. Здесь также находится наша корпоративная Wiki, на которой работает Atlassian Confluence. И хостинг RemoteApps, и хостинг Wiki работают нормально; оба работают через SSL, который, похоже, отлично работает для размещения служб.
Никакие прокси не настроены.
SQL Server 2016 установлен (и, похоже, работает нормально)
Любые идеи? Я занимаюсь этим уже более 30 лет ... но иногда я натыкаюсь на проблему, когда начинаю сомневаться в своих жизненных направлениях, и это один из таких случаев;)
-Дэн
РАЗРЕШЕНО !!!
Комментарий Аарона о «брандмауэре сетевого устройства» по поводу этого вопроса заставил меня задуматься - я сразу же отклонил его, так как все остальное работало отлично за тем же брандмауэром. Все во мне кричало, что это были корневые сертификаты, или SSL, или какая-то проблема, связанная с SSL. На самом деле ничего подобного.
Мы используем брандмауэр Sonicwall, который - без проблем, на мой взгляд, отличный. ОДНАКО, всякий раз, когда настраивается «общедоступный сервер» (определяемый как узел с некоторыми открытыми портами, так что к нему можно получить доступ извне, например, порт SMTP 25 или HTTPS 443), он создает три отдельных правила NAT, которые регулируют такие ситуации, как петли. (когда машина в локальной сети пытается получить доступ к службе, доступной через глобальную сеть, например apps.mycompany.com - петля преобразует общедоступный IP-адрес во внутренний IP-адрес локальной сети).
Проблема: я запускал службы хостинга RemoteApps на порту 443, а также Atlassian Confluence на порту по умолчанию 8433. Но поскольку я запускаю его непосредственно на fqdn (wiki.companyname.com), мне не хотелось добавляйте: 8433 к каждому запросу браузера. Таким образом, я переношу через таблицу NAT входящие запросы для 443 на общедоступном IP-адресе Wiki (у нас есть блок из 5) на 8433. Таким образом, 443 external = 433 internal на IP RemoteApps, но 443 = 8433 на общедоступном IP-адресе Wiki.
Причина: Sonicwall транслировал OUTBOUND запросы ИЗ LAN (частного) IP-адреса сервера с 443 на 8433. Таким образом, в основном каждый запрос https: // отправлялся 8433.
ОДНА МАЛЕНЬКАЯ КОРОБКА!
Все хорошо. Реквизит Аарону (верхний комментарий) не обязательно за то, что он был на месте, но вся эта штука с «брандмауэром сетевого устройства» просто не ускользнула от меня, и я начал думать о таблице NAT ...
Я смог найти решение, изменив IP-адрес сервера в локальной сети. Внезапно это сработало (в любом случае исходящий, очевидно, он полностью сломал все входящие соединения, но я задумал это только как краткий тест). Когда поведение изменилось с новым IP-адресом LAN, это немедленно исключило Certs / RootCerts / SSL из уравнения и заставило меня сосредоточиться на особенностях «сломанного» IP-адреса - что привело меня к взорванному списку NAT.