Comments 16
Таски в оутлуке...
Они позволяют шифровать трафик либо ставить цифровую подпись, которая равнозначна рукописной подписи. Так как это дело обычное и частое, то в компаниях, которые так или иначе связаны с онлайном, таких сертификатов великое множество.
Эти сертификаты имеют срок годности, они выпускаются не на 100 лет (технически это возможно, но по понятным причинам вариант не пользуется популярностью), а обычно на год. И частенько они просрочиваются — срок сертификата подходит к концу, об этом забывают и пропускают его смену, что приводит к потере денег или времени.
Зачем бороться с последствиями, а не с причиной? Почему не добиваться того, чтобы, например, сертификаты проверки подписи были на 15 лет? Не понятно это "по понятным причинам вариант не пользуется популярностью" - что мешает выдавать сертификат проверки подписи более, чем на 15 мес.? Приказ ФСБ № 796 пункт 36? Или требование в формуляре криптоПро (те же 15 лет)?
Не помню где точно читал.
Чем больше собирается данных с итоговых хешей созданных с помощью pki тем больше шанс получить закрытый ключ путем анализа полученных данных.
По этому есть корневые сертификаты с большим сроком, промежуточные с меньшим и конечные с совсем небольшим.
Например всем известный бесплатный летскнскрипт, рекомендует менять сертификаты каждые 2 месяца и не выпускает их больше чем на 3. Как раз с целью уменьшить шанс извлечения закрытого ключа на основе публичной информации.
Сертификат проверки подписи у УЦ Банка России 12 лет, всякие TSP/OCSP на 15 лет. Если бы было бы "так страшно", то и в ФСБ № 796 пункт 36 и в самом криптопро формуляре стояли бы другие сроки. Сроки действия закрытых пусть остаются короткими, но сертификаты проверки должны быть длинными. Никто толком объяснить не может почему УЦ не дают длинные.
Закрытый ключ один, а его открытых ключей может быть много.
Ещё раз. Закрытый ключ первичный, а открытый делается на основе закрытого.
Что мешает использовать просроченный публичный ключ для проверки ? Ничего. ПО просто выдаст предупреждение, что на текущий момент подпись просрочена, но с точки зрения математики все целое.
Стоп! На сколько я помню из курса университета, открытый и закрытый ключ генерируются одновременно и они соответствуют друг другу 1 к 1. Не может быть несколько открытых ключей к закрытому.
Точнее так: есть ключ шифрования и ключ расшифровки. При шифровании 1-й делается открытым, 2-й закрытым (расшифровать может только владелец закрытого ключа). Для цифровой подписи наоборот: шифрует владелец закрытого ключа, а расшифровать может любой открытым ключом.
Есть ли процедура плавного перехода с одного корневого сертификата на другой?
Как не допустить ситуации, когда придётся перевыпускать кучу сертификатов из-за того что корневой "протух"?
но с точки зрения математики все целое.
Написанную перед этой фразой ахинею комментировать не стану, но по этой фразе:
Если при проверке подписи выдается сообщение, что «математически» ЭП верна, но нет доверия к сертификату проверки подписи (например, истек срок его действия), то делается общий вывод: проверка выполнена с отрицательным результатом, юридически документ не может считаться значимым (в рамках этой проверки). Проверка ЭП может начинается с проверки сертификата и если она отрицательная, то вообще нет смысла проверять математику.
Специально для толпы минусующих (кстати - это объективный показатель уровня грамотности по ЭП читателей Хабр), про одну из ахиней в части ЭП:
Что мешает использовать просроченный публичный ключ для проверки ? Ничего. ПО просто выдаст предупреждение, что на текущий момент подпись просрочена, но с точки зрения математики все целое.
По просроченному сертификату УЦ не ведет (не обязан) учет его статуса и не включает в CRL (см. X.509). Поэтому статус просроченного сертификата будет лишь "просрочен" и был ли он отозван ранее (в том числе до подписания документа) - знаний нет. Если формат поставленной подписи не выше CADES-T (т.е. в составе подписи нет необходимых доказательств, что сертификат действовал на момент подписания), то просроченный сертификат фактически означает, что подпись на документе недействительна. Смысла далее проверять математику - нет.
Для понимания ЭП можно почитать:
Массовая незаконная электронная подпись или мина замедленного действия: Формат МинЦифры №472
Открытый проект Электронного подписания внутренних документов компании на примере кадровых
Не браузером единым. Дохрена софта при любой заминке с сертификатами просто обрывают соединение и пишут в лог "Can not establish connection." А почему - сами разбирайтесь, можете картишки раскидать.
Мне на работе приходится на сервер, стоящий на этой же самой машине, лезть через интернет. Потому что там сертификат, выдан на домен, и при подключении по IP он не соответствует. А клиент не умеет это игнорировать. (Прописать домен в hosts нельзя по другой причине. Если кто-то знает как в винде прописать в hosts для одного приложения - расскажите).
Требования здравого смысла. 15-летний сертификат слишком долгий.
Задача обновления и контроля сроков сертификатов достаточно сильно похожа на задачу обновления и пролонгирования договоров с контрагентами (как приходных так и расходных)...нормального ПО так и не встретил...все как-то не то
А в вашей системе нет абстрагирования сертификатов? Чтобы под одним псевдонимом выдавался разный файл/строка сертификата в зависимости от окружения и сроков? Соответственно, через REST чтобы это было.
Например, есть такой юзкейс:
Вам пришло уведомление, вы заменили сертификат;
По факту вы его не заменили, а добавили под псевдонимом. За день-два до истечения срока система сама подсунет новый сертификат сервису;
Сервис, обращающийся именно к псевдониму, не заметит подмены серта и всё также будет работать. Ещё и в зависимости от query в HTTP GET (
https://url?env=development) или HTTP-заголовков будет получать разные серты.
Менеджмент сертификатов – как застраховаться от просрочки