AI: better safe than sorry (или как DeepSeek чуть не сломал мне PKI)
На днях сработал годовой триггер на обновление TLS-сертификата одного из сервисов. Моя PKI развернута на HashiCorp Vault, поэтому процедура рутинная: одна команда — и новый сертификат готов.
Однако в этот раз Vault выдал ошибку: срок действия запрашиваемого сертификата превышает срок действия intermediate CA.
Вскрылась проблема: корневую инфраструктуру я поднимал в апреле 2022, выпустив промежуточный сертификат на стандартные 5 лет. Следовательно, при годовом цикле перевыпуска свежий сертификат «упирается» в апрель 2027, а не в планируемый август.
Решил делегировать рутину DeepSeek, запросив бесшовную процедуру ротации intermediate CA. Модель выдала логичную схему:
- Сгенерировать CSR на базе существующего закрытого ключа intermediate (ключ остается прежним).
- Подписать CSR корневым CA.
- Импортировать новый сертификат как default intermediate, сохранив старый до истечения его TTL.
К каждому шагу DeepSeek приложил пример команды для Vault с подробным пояснением. Бегло пробежался взглядом по командам и привычка проверять за DeepSeek’ом не подвела:
Проблема в том, что команда list pki_int/issues возвращает список идентификаторов издателей, а вовсе не идентификаторов их ключей. Прошу DeepSeek перепроверить команду и получаю классический ответ:
“Ваше сомнение абсолютно обоснованно, и оно указывает на очень важный нюанс в работе с PKI в Vault. Использовать issuer_id в параметре key_ref команды vault write неправильно. Этот параметр требует именно key_id (идентификатор ключа). Спасибо, что обратили на это внимание, это критично для успешного выполнения процедуры.”
Мораль истории – связный пайплайн получить от LLM, конечно, можно. И выглядеть он будет, как настоящий. Но проверка всех команд остаётся на совести выполняющего команды инженера.
