14.4.6. Эксплуатация: ключи, истечение срока и устранение неполадок

Работа с сертификатами на каждом развёрнутом устройстве охватывает три аспекта: защиту приватного ключа после того, как он попал на камеру, планирование на день, когда срок действия сертификата истечёт, и короткий список ошибок, которые встречаются на практике.

14.4.6.1. Защита приватного ключа

Всякий раз, когда камера предъявляет сертификат – как TLS-сервер или как клиент в mTLS – её приватный ключ должен находиться на устройстве, в открытом виде DER, в файловой системе или в ROMFS. В таком виде он доступен для чтения любому коду, выполняющемуся на камере, и любому, у кого есть физический доступ к ней: через USB-накопитель, приглашение REPL или прямое чтение флеш-памяти. ROMFS и флаги «только для чтения» предотвращают изменение, но не извлечение. Считайте, что любой приватный ключ, поставляемый на устройстве, может быть восстановлен настойчивым злоумышленником, имеющим физический доступ или доступ к коду.

Это не делает TLS бессмысленным – это определяет то, как вы его развёртываете:

  • Используйте уникальный ключ и сертификат для каждого устройства. Никогда не прошивайте один общий ключ на весь парк устройств: тогда извлечение его из одного экземпляра позволит злоумышленнику выдать себя за каждую камеру. Ключи для каждого устройства ограничивают компрометацию этим единственным устройством, которое вы можете отозвать или отключить на стороне сервера.

  • Делайте сертификаты короткоживущими. Украденный ключ полезен лишь пока действителен его сертификат; короткий срок действия плюс регулярная ротация ограничивают ущерб (см. Истечение срока действия сертификата и ротация ниже).

  • По возможности вообще не размещайте секрет на устройстве. Если вам нужно лишь проверять сервер (аутентификация сервера, а не mTLS), камера в роли клиента хранит только сертификат CA – который является публичным – и не содержит приватного ключа, достойного кражи.

  • Никогда не поставляйте ключ в публичном образе прошивки. Ключ, встроенный в ROMFS в сборке прошивки, которую вы распространяете, не является секретом; он есть у каждого, кто скачал прошивку. Подготовка для каждого устройства означает программирование ключа после установки универсальной прошивки, а не внутри неё.

  • Ограничивайте радиус поражения. Ограничьте область действия того, что удостоверяет сертификат (принцип минимальных привилегий), и убедитесь, что единственная утёкшая идентичность устройства может быть отозвана или отключена без влияния на остальные.

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

14.4.6.2. Истечение срока действия сертификата и ротация

Каждый сертификат несёт окно действия. После его истечения узел с ssl.CERT_REQUIRED отклоняет соединение – так что истечение срока – это реальный, запланированный простой, а не теоретический риск. Часы камеры также должны быть корректными, чтобы проверка срока действия выполнялась честно.

  • Самоподписанный. Вы выбрали срок действия с помощью -days. Когда он истечёт, вы должны заново сгенерировать ключ/сертификат и повторно развернуть его: заново скопировать файлы DER или пересобрать и перепрошить образ ROMFS, если сертификат встроен в него. Выбирайте такое значение -days, на которое вы действительно вспомните среагировать.

  • Публичный CA. Они намеренно короткоживущие. Let’s Encrypt выпускает 90-дневные сертификаты и предполагает автоматическое обновление примерно каждые 60 дней; варианта «установить один раз и забыть» не существует.

Более широкая тенденция однонаправлена: максимальный срок действия публично доверенных TLS-сертификатов продолжает сокращаться. Он составлял 825 дней, в настоящее время ограничен 398 днями, и CA/Browser Forum принял план, постепенно снижающий его примерно до 47 дней к 2029 году. Вывод для проектирования устройства – предполагать, что сертификаты короткоживущие и что ротация должна быть автоматизированной или хотя бы регулярной – не выпускайте продукт, который зависит от того, что человек будет менять десятилетний сертификат.

На практике на камере: предпочитайте конструкции, где сертификат можно заменить без перепрошивки (записываемая файловая система плюс путь удалённого обновления, или работа камеры в роли клиента, доверяющего CA, который вы централизованно ротируете). Если сертификат должен находиться в ROMFS, планируйте обновления прошивки с учётом его срока действия.

14.4.6.3. Устранение неполадок

  • Часы должны быть установлены. Камера, которая не установила свои часы с момента включения, не проходит проверку срока действия сертификата – сначала вызовите ntptime.settime().

  • Имя хоста должно совпадать. Когда клиент передаёт server_hostname, оно должно совпадать с subjectAltName сертификата (или CN на более старых стеках), иначе проверка не пройдёт.

  • Неверный формат. Файл PEM, скопированный на камеру, не загрузится – сначала преобразуйте его в DER.

  • Сертификат просрочен. Соединение, которое раньше работало, а теперь завершается ошибкой OSError, может просто иметь просроченный сертификат – проверьте даты действия и при необходимости перегенерируйте/переразверните.

  • Ключи Ed25519 не работают. Используйте ECDSA P-256/P-384 или RSA, а не Ed25519.

  • Ошибки – это OSError. MicroPython не реализует ssl.SSLError; сбои TLS (неверный сертификат, истёкший срок, неизвестный CA, ошибка формата, сбой рукопожатия) возбуждаются как OSError.