Shelly TLS: Поддерживаемые сертификаты и конфигурация

В этой статье объясняется, какие TLS-сертификаты и закрытые ключи принимают устройства Shelly, как их подготовить и загрузить, а также где они используются (например, MQTT через TLS/mTLS и, начиная с версии 1.8.0, локальный веб-интерфейс через HTTPS для устройств Gen3 и более новых версий). Для получения общей информации о безопасности/RED см. нашу сопутствующую статью: Что вам нужно знать – Shelly и EU RED EN 18031-1

.

Краткое руководство

Файлы/контейнеры: PEM ✅, DER ✅, PKCS#12/PFX ⚠️ ( Пользовательский интерфейс устройства не импортирует PFX -> используйте PEM/DER вместо него .)
Закрытые ключи: PKCS#8 (незашифрованный) ✅, PKCS#1 (незашифрованный) ✅, зашифрованные ключи ❌ (нет ввода пароля в пользовательском интерфейсе)
Алгоритмы: RSA-2048 ✅, ECDSA P-256/P-384/P-521 ✅, Ed25519 ❌
Цепочки: Загрузка листовых + промежуточных (конкатенированных). Не включать корневой . Максимальная глубина промежуточных узлов: 8 .

Основные ограничения листового узла: Не должен быть центром сертификации (CA:TRUE отклоняется).

Проверка: При включенной расширенной безопасности -> SNI отправлен, имя хоста (SAN/CN) и время действия проверены.

Версии TLS: TLS 1.2 поддерживается; TLS 1.3 не включен.

Веб-интерфейс: Начиная с v1.8.0 (Gen3+), поддерживается HTTPS, включая пользовательские сертификаты HTTPS (самоподписанные или частные PKI).

Примечание по эксплуатации: Для применения новых TLS-материалов может потребоваться перезагрузка устройства.

Поддерживается и не поддерживается (матрица)

Область	Поддерживается	Не поддерживается / Примечания
Контейнеры сертификатов	PEM (.pem, .crt, .cer), DER (.der)	Загрузка PKCS#12/PFX не поддерживается пользовательским интерфейсом; сначала экспортируйте в PEM/DER
Закрытые ключи	PKCS#8 (незашифрованный), PKCS#1 (RSA, незашифрованный)	Любой зашифрованный ключ (без пароля пользовательского интерфейса)
Алгоритмы ключей	RSA-2048; ECDSA P-256, P-384, P-521	Ed25519 (EdDSA)
Цепочки	Лист + промежуточные узлы в одном файле; опустить корневой узел; до 8 промежуточных узлов	Лист помечен CA:TRUE
TLS	TLS 1.2	TLS 1.3
Проверки идентификации (на стороне клиента)	SNI + SAN/CN + время действия при включенной расширенной безопасности	Проверки KU/EKU для клиентских сертификатов (по умолчанию не применяются)
Веб-интерфейс	Поддержка HTTPS с версии 1.8.0+ (Gen3+); Пользовательские HTTPS-сертификаты (самоподписанные или частные PKI); Клиенты должны доверять выдающему центру сертификации (установить частный центр сертификации или доверять сертификату устройства).	-

Поддерживаемые форматы файлов и контейнеров

PEM (.pem, .crt, .cer) - Поддерживается и рекомендуется.

DER (.der) - Поддерживается (двоичное кодирование тех же данных).

PKCS#12/PFX (.p12, .pfx) - Пользовательский интерфейс устройства не импортирует PFX. Типичные загрузки PFX не удается. Даже незашифрованный .p12 не импортируется. Рекомендация: извлеките ключ и сертификаты в незашифрованный PEM-файл и загрузите их.

Форматы закрытых ключей

PKCS#8 (незашифрованный) - Поддерживается и является предпочтительным.

PKCS#1 (RSA, незашифрованный) - Поддерживается.

Зашифрованные ключи - Не поддерживаются (в пользовательском интерфейсе не запрашивается пароль).

Быстрые идентификаторы в формате PEM:

Незашифрованный PKCS#8 -> -----BEGIN PRIVATE KEY-----
Незашифрованный PKCS#1 (RSA) -> -----BEGIN RSA PRIVATE KEY-----
Зашифрованный ключ (не поддерживается) -> -----BEGIN ENCRYPTED PRIVATE KEY-----

Поддерживаемые алгоритмы ключей

RSA-2048 - Поддерживается .

ECDSA - secp256r1 (P-256) , secp384r1 (P-384) , secp521r1 (P-521) - Поддерживается .

Ed25519 (EdDSA) - Не поддерживается (Curve25519/X25519 может присутствовать для ECDH, но не для подписей).

Совет: Для новых развертываний ECDSA P-256 предлагает меньшие ключи и более быстрое рукопожатие на устройствах с ограниченными ресурсами.

Цепочки сертификатов и доверие

Представленная цепочка (идентификатор, который вы загружаете на устройство):

Загрузите один PEM-файл который содержит конечный сертификат первым , за которым следуют любые необходимые промежуточные сертификаты CA

(объединенный PEM).

Не включайте корневой центр сертификации. Применяется к:

идентификатору клиента для mTLS (сертификат клиента MQTT) и Серверу веб-интерфейса HTTPS сертификату.

Кто должен доверять чему (хранилища доверенных сертификатов)

Когда Shelly является TLS-клиентом

(например, подключается к вашему MQTT-брокеру) Загрузите ваш корневой центр сертификации (и любые промежуточные сертификаты, которым Shelly должен доверять) в Настройки -> Конфигурация TLS -> Пользовательский пакет PEM центра сертификации (CA) . Это хранилище доверенных сертификатов устройства,

используемое для проверки серверов.

(Здесь нет закрытых ключей.) Когда Shelly является TLS-сервером

(Веб-интерфейс по HTTPS, Gen3+, v1.8.0+) браузер/ОС

(клиент) должен доверять центру сертификации, выдавшему сертификат веб-интерфейса устройства.

Максимальная глубина цепочки: До 8 промежуточных узлов .

Основные ограничения (лист): Лист не должен быть центром сертификации . Лист с CA:TRUE отклоняется. Лист с CA:FALSE или без расширения BasicConstraints принимается.

Пользовательские HTTPS-сертификаты (веб-интерфейс, Gen3+, v1.8.0+):

Вы можете установить пользовательский HTTPS-сертификат сервера (самоподписанный или частный PKI). Убедитесь, что клиентские устройства доверяют выдающему центру сертификации , иначе браузер выдаст предупреждение. Если вы обращаетесь по DNS-имени , укажите это полное доменное имя (FQDN) в SAN . Если вы обращаетесь по IP-адресу, укажите IP-адрес в SAN в качестве записи IP-адреса.

Публичный центр сертификации: обычно уже является доверенным.

Частный PKI: установите ваш частный корневой/промежуточный центр сертификации только в хранилище доверенных сертификатов клиента(ов) или приложения, которые будут обращаться к веб-интерфейсу. Не включать корневой сертификат в цепочку, предоставляемую устройством.

Версия TLS и поведение проверки

Версии TLS: Поддерживается TLS 1.2. TLS 1.3 отсутствует в текущих сборках.

Проверка подлинности сервера и времени: Отправляет SNI (Server Name Indication) для конечных точек на основе имени хоста. Проверяет имя хоста по сертификату SAN/CN. Проверяет срок действия сертификата (дата/время).

Где используются сертификаты в Shelly

MQTT через TLS (аутентификация сервера) - Загружает сертификат CA, чтобы Shelly мог проверить сертификат брокера.

MQTT с клиентскими сертификатами (mTLS) - Дополнительно загрузите клиентский сертификат и соответствующий незашифрованный закрытый ключ; включите опцию клиентского сертификата в настройках MQTT.

Локальный веб-интерфейс по HTTPS (начиная с версии 1.8.0) - Веб-интерфейс устройства поддерживает HTTPS. Если вы будете получать доступ по DNS-имени (например, shelly-dev.example.lan), включите это FQDN в SAN сертификата веб-интерфейса, которому вы планируете доверять/использовать. Если вы получаете доступ по IP-адресу, IP должен присутствовать в SAN в качестве записи IP (одних только DNS-имен недостаточно для браузеров при доступе по IP). В управляемых средах рассмотрите возможность использования внутреннего центра сертификации (ЦС), которому доверяют ваши конечные устройства, или выдайте сертификат через ACME DNS-01 для частного имени. Пользовательский HTTPS-сертификат (самоподписанный или с использованием частной PKI): Загрузите сертификат сервера и соответствующий незашифрованный закрытый ключ для веб-интерфейса (метки могут различаться в зависимости от модели; см. «Настройки -> Конфигурация TLS»). Убедитесь, что клиентские устройства доверяют выдающему ЦС или сертификату устройства.

Подготовка файлов (шпаргалка по OpenSSL)

Сгенерировать ключ ECDSA P-256 и CSR (рекомендуется)

BASH

Закрытый ключ (PKCS#8, незашифрованный)

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out device.key

CSR (скорректировать тему)

openssl req -new -key device.key -out device.csr -subj "/CN=device.example.com"

Сгенерировать ключ RSA-2048 и CSR

BASH

openssl genrsa -out device.key 2048 openssl req -new -key device.key -out device.csr -subj "/CN=device.example.com"

Объединить листовой ключ + промежуточные соединения (PEM)

BASH

Сначала лист, затем промежуточные соединения; НЕ включайте root

cat device.crt intermediate1.crt intermediate2.crt > device-chain.pem

Удалите парольную фразу (если ваш ключ зашифрован)

BASH

Выводит незашифрованный PKCS#8

openssl pkey -in encrypted.key -out key-unencrypted.pem

Преобразовать DER <-> PEM

BASH

PEM -> DER

openssl x509 -in device.crt -outform der -out device.der

DER -> PEM

openssl x509 -in device.der -inform der -out device.crt

Извлечь PEM из PFX (избегайте загрузки .p12/.pfx)

BASH

Незашифрованный закрытый ключ

openssl pkcs12 -in bundle.p12 -nocerts -nodes -out key-unencrypted.pem

Лист + цепочка

openssl pkcs12 -in bundle.p12 -clcerts -nokeys -out device.crt openssl pkcs12 -in bundle.p12 -nodes -nokeys -cacerts -out intermediates.pem

Загружаемая цепочка

cat device.crt intermediates.pem > device-chain.pem

Загрузка сертификатов (веб-интерфейс)

Откройте Веб-интерфейс -> Настройки -> Конфигурация TLS .

Загрузите необходимые файлы: * Сертификат центра сертификации (ca.crt) для проверки сервером.

Сертификат клиента (только при использовании mTLS).

Закрытый ключ клиента (незашифрованный; соответствует сертификату клиента).

(Gen3+, v1.8.0+) Сертификат веб-сервера (необязательно): загрузите сертификат HTTPS-сервера и соответствующий ему незашифрованный закрытый ключ, если вам нужен пользовательский сертификат пользовательского интерфейса (самоподписанный или с закрытой инфраструктурой PKI).

Сохраняйте каждую загрузку.

Перезагрузите при появлении запроса, чтобы изменения вступили в силу.

После загрузки настройте конкретную службу (например, Настройки -> MQTT

) для использования TLS

и, при необходимости, клиентского сертификата .

Примечания по настройке и рекомендации

SAN имеет значение. Убедитесь, что точное имя хоста или IP-адрес, к которому вы подключаетесь, присутствует в SAN сертификате сервера; Одного CN недостаточно для современных клиентов.

Создавайте компактные PEM-файлы. Включайте только необходимые конечные узлы и промежуточные узлы. Большие пакеты могут превышать ограничения встроенной памяти.

Избегайте зашифрованных ключей. Нет пути в пользовательском интерфейсе для паролей;

Не помечайте конечный узел как CA. Повторите операцию, если BasicConstraints показывает CA:TRUE.

SNI требует имени хоста. По возможности используйте DNS-имя вместо необработанного IP-адреса для лучшей совместимости.

Устранение неполадок (быстрые решения)

«Не удалось разобрать ключ/сертификат.» Вероятно, это зашифрованный ключ или PFX. Преобразуйте в незашифрованный PEM и повторите попытку.

Несоответствие имени хоста Добавьте точное FQDN/IP, которое вы используете, в сертификат SAN.

Неполная цепочка Объедините листовой узел + все промежуточные в один PEM; опустите корневой узел.

Ошибки времени рукопожатия Убедитесь, что часы устройства установлены правильно (включите NTP).

Ограничения памяти Если загрузка периодически завершается с ошибкой, удалите комментарии/лишние сертификаты и сократите количество PEM-файлов.

Контрольный список перед загрузкой

Закрытый ключ не зашифрован (PKCS#8 или PKCS#1) в PEM.

Файл сертификата содержит "листовой + промежуточный" (объединенные), "корневой" отсутствует.

Тип ключа - RSA-2048 или ECDSA P-256/P-384/P-521 (не Ed25519).

Листовой ключ не является центром сертификации (CA:FALSE или без BasicConstraints).

SAN указывает на точное полное доменное имя/IP-адрес, который вы будете использовать.

Расширенная безопасность включена для исходящей проверки TLS.

В версии 1.8.0 и выше рекомендуется использовать веб-интерфейс по протоколу HTTPS.