Перечитав две самые известные статьи по теме (1 и 2) осталось впечатление некой темной магии, как правило возникающее при недостаточно подробных описаниях происходящего с OpenSSL
Например вот такой вопрос:
На моем контроллере есть файл /etc/ssl/certs/device_bundle.crt.pem в котором живут 2 сертификата:
А как работать/где искать ключ кеонтроллера по данному сертификату?
Да и промежуточный сертификат подписан “Issuer: C=RU, L=Moscow, O=Contactless Devices LLC, OU=Device Certificate Authority, CN=Contactless Devices LLC Root Certificate/emailAddress=info@contactless.ru”, которого в бандле нет, то есть проверку врядли удатся пройти, если импортировать данный сертификат в свои системы
И вот еще вопрос:
В первой статье рекомендуется применить следующий шаманизм:
Как я понимаю, мы создаем Certificate Signature Request а частный ключь генерим на ATECCx08. Но какие значения мжоет принимать KeyID (08:00:04:C0:00)? Сколько слотов на крипточипе для собственных ключей есть у конечного пользователя и сколько их всего? Как посмотреть статус крипточипа?
А опишите задачу пожалуйста, так проще будет ответить
Задача №1 – застравить nginx и mosquitto работать с авторизацией и по https если обращение идет не с localhost и, возможно, местной локалки (2022-й год на дворе всетаки).
Для этого нужен набор сертификатов и ключ. Могу сгенерить свои но, как мне кажется, использовать встроенные в железку более правильно, если сценарии использования конечного сертификата поддерживают TLS Server
Задача №2 – авторизовывать устройство на системах сбора телеметрии и автоматизации более высокого уровня. Опять-же, могу сгенерить свои но, как мне кажется, использовать встроенные в железку более правильно, если сценарии использования конечного сертификата поддерживают TLS Client
Если сертификаты по каким-то причинам не подходят, хочется знать сколько слотов для своих ключей у меня есть (делать 2 сертификата один для клиента другой для сервера или один) и как ими манипулировать
он же аппаратный, в этом и смысл. Его не надо искать, он в чипе.
Как к нему обратится, чтобы использовать для авторизации? В каком слоте он прописан и какой у него KeyID?
Это наш рут сертификат, он есть в debian-репозитории и публичный.
В /etc/ssl/certs его нет. Где его можно найти и как проверить цепочку сертификатов?
# openvpn --config /etc/openvpn/tm.conf --key engine:ateccx08:ATECCx08:00:02:C0:00
Wed Nov 16 15:15:15 2022 WARNING: cannot stat file 'engine:ateccx08:ATECCx08:00:02:C0:00': No such file or directory (errno=2)
Options error: --key fails with 'engine:ateccx08:ATECCx08:00:02:C0:00': No such file or directory
Options error: Please correct these errors.
Use --help for more information.
# openvpn --config /etc/openvpn/tm.conf --ca /etc/openvpn/tm/ca.crt --cert /etc/openvpn/tm/device.crt --key engine:ateccx08:ATECCx08:00:02:C0:00
Thu Nov 17 18:04:41 2022 WARNING: cannot stat file 'engine:ateccx08:ATECCx08:00:02:C0:00': No such file or directory (errno=2)
Options error: --key fails with 'engine:ateccx08:ATECCx08:00:02:C0:00': No such file or directory
Options error: Please correct these errors.
Use --help for more information.
А в чем разница? Вывод результата команды ведь явно говорит о том, что openvpn неверно парсит аргумент --key, интерпритируя его как файл, не обращаясь к движку ateccx08.
Попробовал. Вывод абсолютно такой же.
Повторюсь о чем писал выше. По-умолчанию APT WirenBoard ставит пакет openvpn из основного репозитория, который не пропатчен Вашим патчем, поддерживающим парсинг ключевого слова engine в параметре --key.
Если Ваша команда добавит пропатченную версию, как и openssl, в Ваш репозиторий, то это станет решением вопроса. Правда как будет решаться проблема обновлений безопасности пакетов неясно.
Лучшим вариантом было бы конечно согласование внесения изменений с разработчиками и мейнтейнерами openssl и openvpn в основной код проектов, либо нахождение альтернативы в виде использования параметров engine (что лучше), например. А так получается околополовинчатое решение. Вами проделана огромная работа, но до логического конца так и не доведена.
Если делать все исключительно по документации, то работать вообще ничего не будет. Например, в конфигурации openvpn содержится параметр, заключенный в тройные кавычки. Процесс openvpn запускается от root, зачем ему группа i2c?
Повторюсь, проблема в том, что версия openvpn, которая устанавливается не пропатчена. Поэтому и не парсится параметр в командной строке. Иначе сообщение об ошибке было бы совсем другое, а не то, что файл отсутствет.
