Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Запрос функции: CloudKey2 должен по умолчанию поддерживать HTTPS с использованием Let's Encrypt и ACME, feature-request
 
Понимаю, что из оболочки можно установить ACME-клиент и настроить Cloud Key на работу с Let's Encrypt или другим ACME-сертификатным центром, чтобы получить HTTPS-сертификат. Вот-вот наступит 2020 год, и было бы здорово, если бы всё это работало по умолчанию. Тогда пользователи могли бы с лёгкостью использовать собственный домен и получать HTTPS, а Ubiquiti могла бы даже предложить сервис динамического DNS с выдачей кастомных имён внутри общего домена — и всё это с HTTPS.
 
На самом деле я настроил S2S VPN с другим сайтом, потому что так немного быстрее происходит вход и обмен данными, чем через облако. Не сильно, но чуточку шустрее. Кроме того, теперь я могу быстро и легко подключаться к устройствам по SSH, если нужно.
 
@Dubz согласен... и именно поэтому меня пока не трогают, и я пользуюсь unifi.ui.com и protect.ui.com.
 
Проблема ручной установки в том, что нужно действительно пройти весь процесс через SSH и выполнить несколько команд. Остановить контроллер, удалить старый ключ из Java keystore, импортировать новый ключ в Java keystore, перезапустить UniFi. Если хотите защитить Protect и основные страницы управления/настроек самого CK, просто заменяете поверх текущих файлов, которые использует nginx. Это не так сложно, но единственный способ заставить Protect использовать обновлённый ключ — это полный перезапуск CK (перезапуск служб у меня не сработал). Главная мысль — это не то, чем хочется заниматься вручную, особенно если управляешь десятками сайтов. Поэтому и используют LetsEncrypt с certbot/certbot через DNS API (например, Cloudflare), так как обычно всё это за файрволом (офлайн). Это такой «костыльный» метод, который нужно настраивать и запускать на отдельном устройстве или машине. Ещё более удивительно, что в новые продукты UDM(P), которые объединяют несколько устройств в одном, это не встроили.
 
@Dubz спасибо за разъяснение (я в кибербезопасности уже больше 20 лет)... просто хотел убедиться, что правильно понял, в чём проблема. Я знаю, что могу установить сертификаты для своего домена, но как-то не доходили до этого руки. Хотя их можно добавить вручную, это совсем не так просто, как использовать Let's Encrypt (хотя сам лично никогда им не пользовался). Хорошее замечание про гостевой портал... но, повторюсь, ручная установка решает этот вопрос. Хотелось бы увидеть это в деле... но, наверное, пока это не в приоритете, пока больше людей не потребует.
 
Это для прямого подключения к вашему контроллеру. То есть, когда вы на месте, вводя домен, который указывает на IP-адрес вашего контроллера, соединение будет происходить через HTTPS. Это в основном нужно, чтобы предотвратить перехват данных для входа или отправки форм, а также позволит гостевому порталу работать по HTTPS. Это обязательно? Не совсем. Просто лучшая практика — использовать это в любой среде, где вы можете делать что-то конфиденциальное, например, входить в сетевой контроллер для его управления. Для справки, это касается и Protect.
 
@rmhrisk Это указано как «предлагаемый» стандарт, а не как «Интернет»-стандарт. Насколько я понимаю, предлагаемый стандарт может быть ещё не до конца зрелым... хотя, возможно, теперь это уже не так... наверное, я выдаю свой возраст. Лол. Не поймите неправильно — я полностью поддерживаю идею внедрения Let's Encrypt и ACME. Возможно, из-за этого продукция Unifi может отставать от других (хотя я не знаю, кто из конкурентов это поддерживает... похоже, pfsense — да). Просто мысль такая... Когда я захожу на свой Cloud Key через unifi.ui.com, соединение идет по HTTPS (с сертификатом UI). Хотелось бы понять, в чем именно ценность Let's Encrypt и ACME. Это про связь между UI и моим Cloud Key? Там по умолчанию передаются данные в открытом виде? Или это касается только тех, кто хочет получать доступ к Cloud Key напрямую, а не через unifi.ui.com?
 
Я прекрасно понимаю, что это возможно. Раздражает то, что этого не добавили и даже не сделали заявление, что рассматривают этот вопрос. Я не про «спасибо за предложение, мы добавим это в список», а про настоящее «мы над этим работаем». Кажется, им совершенно всё равно. И ещё, правильно Ubiquiti*, а не «Ubiquity».
 
Да, это возможно, и многие продукты интегрируют это по умолчанию, так что и Ubiquity должен.
 
RFC 8555 (ACME) был готов уже давно, и номер RFC ему присвоили в марте 2019 года.
Страницы: 1
Читают тему (гостей: 1)