SagePtr

Набор шифров не поддерживается. Сервер для TLS 1.2 поддерживает только эти:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)   ECDH secp256r1 (eq. 3072 bits RSA)   FS	256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   ECDH secp256r1 (eq. 3072 bits RSA)   FS	128
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)   ECDH secp256r1 (eq. 3072 bits RSA)   FS	256

А IE поддерживает ECDHE только в паре с ECDSA-сертификатом (а там на сервере RSA).
https://www.ssllabs.com/ssltest/analyze.html?d=aut...
В техподдержку обращаться не стоит, вряд ли для вашего IE сделают исключение и разрешат заведомо более слабое шифрование.

Назначить себя владельцем этой папки и файлов в ней, затем удалять.
Ещё как вариант, загрузиться в Linux и удалить, Linux игнорирует права доступа NTFS.

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

Самый простой способ - поменять группу на www-data, а права выдать 750. Тогда владелец и рут сможет делать что угодно, группа - читать, а левые - ничего не смогут. Но помнить, что через символьные ссылки злоумышленник на другом аккаунте при помощи веб-сервера сможет повыдёргивать чужие файлы, если у сервера есть к ним доступ, потому нужно дополнительно настроить защиту на этот случай.

Разве что зашифровать так, чтобы ключ хранился где-то за пределами сервера и не попадал на него. Как в том же mega.nz, где файлы хранятся в зашифрованном виде, а ключи расшифровки добавляются в ссылки, которыми обмениваются пользователи.

Это всё равно, что жрать в темноте, надеясь, что тело не будет видеть еду и не будет от этого толстеть

Поднять веб-сервер на 80-м порту, а там перекидывать через HTTP-заголовок Location всех на http://1.1.1.1:10/
Либо веб-сервер использовать как обратный прокси, проксировать в нём на тот самый http://1.1.1.1:10/

Выкинуть VestaCP, более стрёмную и бесполезную панель управления сервером не встречал.
Ещё и решето, как разработчики могли налажать в полторах функциях - непонятно.

Из удобных консольных инструментов - ncdu (псевдографическая обёртка над du), а там смотрите где у вас скопился хлам и удаляйте

Если подключили недавно, то не у всех успели DNS-записи обновиться. Если злоумышленник знает ваш IP за Cloudflare, он может задудосить вас напрямую в любом случае, потому если поставили Cloudflare перед вами ради защиты от DDoS - рекомендуется поменять IP'шник вашего сервера на тот, о котором злоумышленник ничего не знает. Ну и дополнительно - запретить к веб-серверу доступ напрямую, разрешить только с IP-адресов Cloudflare.
Ну и напоследок, настроить nginx так, чтобы он доверял Cloudflare и подставлял IP-адрес в remote_addr: nginx.org/ru/docs/http/ngx_http_realip_module.html

Видимо, у вас настроен mod_rewrite так, чтобы все запросы скармливать вашему роутеру на сайте, а не только запросы к несуществующим файлам, как обычно и делается. В итоге на запросы в папке .well-known сервер ваш выдаёт совершенно не то, что ожидает увидеть проверяющий робот Let's Encrypt.

P.S. Хотя погодите, вы говорите, что у вас IIS, а в логах путь /home/nwww - получается, что запрашивается совершенно не тот сайт, который на IIS висит у вас.

А что в этом тексте не так? Или проблема в том, что он появился раньше, чем splash отобразил "индикатор" из четырёх оранжевых точек?