Comments 98
В военное время значение синуса может достигать четырёх
Но дело в том, что этим сертификатам соответствуют сами ключи ЭП, которые тоже имеют собственные сроки действия
Чего? Где это для пары приватный-публичный ключ указывается срок действия?
Это скорее из серии навязанных услуг УЦ «а у вас USB-токен протух, купите новый», как и «вот вам и ключ и сертификат, какой такой CSR, ничего не знаем»
Где это для пары приватный-публичный ключ указывается срок действия?
Учите матчасть, читайте документы ТК-26!
Поля с датами есть только в сертификате.
Понимаете время действия ключа придумали не от хорошей жизни. Закрытый ключ это в принципе случайное определенной длины (для ГОСТ-ов 256 и 512 бит).
Следовательно их можно подобрать простым перебором, так как открытый ключ получается из закрытого ключа.
Следовательно, имея достаточно времени, злоумышленник может получить закрытый ключ для нужного сертификата. Дальше дело техники.
А продлевая срок действия сертификаа мы даем злоумышленникам дополнительный шанс.
Возникает вопрос, кто будет нести ответственность, если случится компроментация ключа?
Все зависит от того где и как хранится ключевая пара. При чем открытый и закрыты ключи могут хранится и отдельно. Открытый ключ может вообще нигде (кроме сертификата) не хранится, он вычисляется. А если вы посмотрите с какими параметрами (CKA_ ) ключи могут хранится на токенах PKCS#11, то много интересного увидите. Вопрос в том, все ли приложения их обрабатывают и проверяют.
А вопрос то в том, насколько я понимаю, продлить-то сертификаты можно, а вот о последствиях кто подумает. Или хотели как лучше, а вышло как всегда.
Т.е. субъекту всего-то надо выпустить CSR с тем же открытым ключом, подписать его, и передать в УЦ, который подпишет CSR, выпустив (sic!) новый сертификат той же ключепары с другим сроком действия.
Всё.
Сама ключепара протухнуть не может. И такой финт ушами можно повторять неограниченно долго.
Сама ключепара протухнуть не может.
Еще как протухает! И ваш способ это именно финт, направленный против вас же. Самое страшное то, что запрос остается в УЦ и недобросовестный сотрудник УЦ может им воспользоваться и выпустить фактически поддельный сертификат. А если еще и закрытый ключ "протух", то жди беды!
Еще как протухает!
Нет. Ключепара — это просто числа большой разрядности. Причем выведение закрытого ключа из открытого — задача вычислительно сложная. Даже для 128-разрядных эллиптических ключей, а ГОСТ-34.10 оперирует 256- и 512-разрядными. Прикинуть к носу вероятность компрометации закрытого ключа можете самостоятельно, для меня достаточно, что она стремится к нулю.
Самое страшное то, что запрос остается в УЦ и недобросовестный сотрудник УЦ может им воспользоваться и выпустить фактически поддельный сертификат.
Баюс-баюс. Ну выпустит. И что? Мы же говорим о генерации ключепары локально, и передаче в УЦ только CSR. Ну выпустит он еще один сертификат к моему ключу — закрытый то ключ у меня. И дальше что?
Надо читать внимательней, владелец закрытого ключа!
Сертификат имеет срок действия, ключ никак со сроком не связан. Давайте еще скажите, что число 1234 имеет срок действия?
Три месяца, по сравнению со сроками действия сертификата ничтожно малы, а особенно по сравнению с теоретическим брутфорсом ключа.
Вам стоит изучить криптографию для начала! Ключ и сертификат — АБСОЛЮТНО разные вещи!
Правильно, почитайте! Что такое сертификат, как он связан с ключами и вообще зачем нужен!
Три месяца, по сравнению со сроками действия сертификата ничтожно малы
Это с каких пор 3 по сравнению с 12 или даже 15 стало ничтожно малым. Изучаем математику, что такое ничтожно малое. Далее дикуссия бессмысленна.
Во-первых, есть как минимум рутовые сертификаты, сроки службы которых 20-30 лет. Это уже разница 2 порядка с 3 месяцами!
НО, во-вторых, вы даже невнимательно читаете! Криптостойкость зависит конечно же не от срока действия сертификата и в современных алгоритмах понадобятся сотни-тысячи лет для брутфорса!
А где ключ от рутовых сертификатов хранится?
И вообще вы о каких сертификатах говорите? Если об SSL-ых то бог с вами, а если о тех, с помощью которых у людей все отбирают, то это две большие разницы!!!
А кто вам сказал, что криптостойкость зависит от срока действия сертификата!!! Это исходя из криптостойкости в том числе и определяется срок действия сертификата.
А где ключ от рутовых сертификатов хранится?
Обычно в HSM-е.
И вообще вы о каких сертификатах говорите? Если об SSL-ых то бог с вами, а если о тех, с помощью которых у людей все отбирают, то это две большие разницы!!!
Я вас расстрою — разницы никакой. Что RSA, что ГОСТ-34, который суть цельнотянутый ECDSA с немного другими параметрами.
А отбирают не с помощью сертификатов, а с помощью мошенничества и раздолбайства прокладок между стулом и монитором, которых в УЦ набирают за мелкий прайс по объявлению, и которым до звезды принадлежность ключа реальному владельцу.
Это исходя из криптостойкости в том числе и определяется срок действия сертификата.
Конечно-конечно, ведь за год ключ в 256 бит обязательно подберут злые враги в враждебных УЦ. А за 20 лет — обязательно скомпрометируют ключи корневых сертификатов. Хотя корневики те же 256 бит.
6.1. Удостоверяющий центр аннулирует сертификат ключа проверки электронной подписи в следующих случаях:
…
2) установлено, что содержащийся в таком сертификате ключ проверки электронной подписи уже содержится в ином ранее созданном сертификате ключа проверки электронной подписи;
Т.е. выпуск нового сертификата не аннулирует старый, а считается недействительным.
Что вдвойне странно…
Во-первых, когда переводили все юрлица на усиленную квалифицированную подпись, то УЦ «Такском» просто выпустил дополнительные сертификаты и мы скачали их.
Во-вторых, несколько лет назад, когда происходил переход с ГОСТ 34.10-2001 на ГОСТ 34.10-2012, УЦ «СКБ Контур» выпускал сертификаты парами — по обоим ГОСТам. Можно было пользоваться некоторое время старым, а потом купить новую версию «Крипто Про» с поддержкой ГОСТ 34.10-2012 и перейти на новый.
Получается, они нарушали этот пункт закона? Или воспринимали его как рекомендацию?
Так что, быть может, это не нарушение рекомендаций, а маркетинговый ход: «два сертификата ключей подписи по цене одного»?
… подобрать простым перебором ...Простой перебор?! Если немного ближе к теме, то оценки различных методов дискретного логарифмирования на эллиптических кривых, скажем, начиная с Шанкса и более изощрённых, а так же с учётом оценок предполагаемого прогресса вычислительной техники и т.п., обещают сроки криптографической защиты десятки лет. (Имеется ввиду, что если начать логарифмировать прямо сейчас открытый ключ рекомендованной размерности, то в течении пары десятилетий вероятность успешного подбора не превысит разумно малой границы.)
Типичные же сроки действия сертификатов пользователей порядка одного года больше вызваны организационными аспектами. Например, если организация доверяет человеку ключ, то, как бы, разумно иметь с этим человеком трудовой договор не короче срока действия сертификата (ключа), что б не отзывать сертификат лишний раз.
Кроме того, оценки более сложных атак (физических, по побочным каналам, и т.п.), а так же оценки влияния отказов оборудования, как бы, намекают, что сохранить закрытый ключ в тайне с разумной вероятность больше пары-тройки лет достаточно непросто. Лучше бы его надёжно стереть, по окончании разумно небольшого срока действия, что б врагу не достался.
… кто будет нести ответственность, если случится компроментация ключа?За всё отвечает владелец сертификата ключа подписи. Это его риски.
И, таки да. Лучше покупать дешевый сертификат на год, чем дорогой на 20 лет.
Все правильно. Так и надо у него спросить согласен ли он с продлением своего сертификата.
«Координация профанации»…Хм. На мой непросвещённый взгляд, «внешние» электронные подписи (подписи других пользователей) проверяются не с помощью своего сертификата, а с помощью «внешних» сертификатов (сертификатов других пользователей).
… пользователей сертификаты открытых ключей могут протухнуть при нахождении пользователей в режиме самоизоляции и они не смогут проверять с их помощью внешние электронные подписи...
… привязанный к этому сертификату, у которого (ключа) срок уже тоже истек и по приказу министерства продлить его невозможно технически...Обычно, привязка сертификата с закрытым/открытым ключом пользователя изменяется легко, или очень легко:
- Если сертификат пользователя передаётся в подписанном сообщении, достаточно легко установить «продлённый сертификат» в «личное хранилище сертификатов» и/или в соответствующий атрибут ключевого контейнера/токена (технически легко, другой вопрос как обучить этому пользователя);
- Если сертификат пользователя не передаётся в подписанном сообщении, а в сообщении передаётся ссылка на сертификат по keyed, то достаточно легко изменить централизованный каталог сертификатов;
- И т.д. и т.п.
P.S.
Там есть правовая коллизия, вроде в требованиях ФСБ на УЦ есть пожелание контролировать уникальность сертификатов на открытые ключи, а здесь законодатели предлагают выпустить второй. Кто главнее ФСБ или законодатели?
В хранилище то вы поставите и свяжете сертификат и ключом. Но если будет проверяться подпись, например, то может проверяться и срок действия сертификата и срок действия ключа. А если это так, то ...
Однако, в тех системах, в которых этот атрибут используется, при выпуске продлённого сертификата можно и нужно расширить, как срок действия сертификата, так и срок действия закрытого ключа.
Если пара ключей не скомпроментирована, то 3 месяца не сделают никакой погоды в принципе.
Хотя, я не юрист и могу чего-то не знать…
… не позволит мне использовать пару ключей повторно для подписи нового сертификатаВ вопросе, наверное, небольшая путаница. Вероятно, имелось ввиду "… для подписи нового запроса на сертификат к УЦ".
Есть, как минимум, два момента, которые могут мешать Вам в деле повторного использования пары ключей:
- Контроль со стороны УЦ по реестру сертификатов;
- Реализация СКЗИ, которое ограничивает срок действия закрытого ключа.
Человеке, конечо, за всегда преодолеет железяку чёртову, но зачем?
Если таков регламент, значит «секурно», его ж проверяли и утверждали умные и ответственные товарищи.
и ответственные
Это шутка такая?
У меня к ответственным товарищам вопрос: доколе пару ключей будут генерить сами уц, и любезно предоставлять всё скопом на флешке (и по большим праздникам галактического масштаба на токене)?
Тензор мне сам генерил (а вот продление — на следующий год — было удаленным и соответственно генерация уже мной).
Контур — генерация мной была (еще и инструкцию дали, понятную даже полной блондинке, да, win-only все было).
Используйте вменяемые УЦ.
А такие точно есть?
Тензор мне сам генерил (а вот продление — на следующий год — было удаленным и соответственно генерация уже мной).
Не вижу такого соответствия. Перевыпуск сертификата возможен без перегенерации ключевой пары.
Контур — генерация мной была (еще и инструкцию дали, понятную даже полной блондинке, да, win-only все было).
Да ладно? Прям можно было сгенерить пару самостоятельно (лучше вообще непосредственно в защищенном хранилище аппаратного токена в неизвлекаемом виде), отправить им CSR и в ответ получить сертификат? Или генерация выполнялась закрытым непонятно как работающим, что делающим и что кому расссылающим софтом, который предоставил сам УЦ? И да, различным вариациям криптопро я не сильно доверяю, особенно учитывая их специфическое лицензирование для организации, предоставляющих услуги криптографии, а не конечных клиентов.
Что до инструкций — я считаю, что раз ЭЦП является полным аналогом собственноручной подписи, то УЦ надо обязывать на законодательном уровне объяснять «блондинкам» как работает непосредственно технология, и как и чем им угрожает. А простые «инструкции для блондинок» в этой сфере — первейший инструмент обмана.
но этот УЦ только для Гос организаций, с физ. лицами не работают
Давно там ключи получали?
Это раньше, при использовании АРМ ГК генерилось на компе пользователя.
А сейчас, при работе через портал — та же самая схема с "мутным софтом" и "мутным плагином".
Хотя это не отменяет нынешнего удобства (особенно по сравнению с запросами и выпуском ЭП на FDD как раньше).
Плагины на то и плагины, чтобы выполняться на стороне пользователя. Отправляются в УЦ открытый ключ и регистрационные данные владельца сертификата. Если бы были намеренные утечки из плагина, их бы давно обнаружили.
а возможность использовать АРМ ГК до сих пор имеется, рекомендуется через портал, но если вдруг не работает, или нет интернета — то можно и по-старинке запрос на флешке принести, по регламенту обязаны и такой обработать. Например, запросы на сертификаты для КонтинентАП я до сих пор на флешке отношу
При изготовлении ключа под контролем УЦ, эта выполнение этого пожелания заметно упрощается.
Мне, как гражданину, для которого вся система электронных подписей, существующая в стране, представляет угрозу, которую я ни контролировать, ни избегать толком не могу, абсолютно наплевать на пожелания фсб. Хотя пожелание-то, в общем то, резонное, т.к. тоже направлено на безопасность конечного пользователя, но если оно ведёт к таким последствиям — "хотели как лучше, а получилось как всегда".
...«хотели как лучше, а получилось как всегда».Ну, дык, практика Вам не теория. На мой непросвещённый взгляд, только медленной эволюцией можно контролируемо подправить «как всегда» в нужную сторону.
Как бы, в данном случае:
- УЦ создаёт ключ — плохо, по 33 причинам;
- Пользователь предоставляет запрос на сертификат — очень хреново по 33 причинам, например, у некоторых карточек/токенов ДСЧ — мама не горюй. И не говоря уж об тех или иных финтах: https://habr.com/ru/news/t/503424/#comment_21651088 ;
- Пользователь создаёт ключ безопасным контролируемым образом используя как свой ДСЧ, так и ДСЧ от УЦ — такой протокол, да, возможен (аналогично созданию разделённого между несколькими HSM/токенами/карточками ключа таким образом, что вообще нигде нет информации для получения закрытого ключа «в сборе», но только в завершении УЦ отдаёт свою часть пользователю), но… Сложно, непонятно и профессиональные параноики с обеих сторон ходят по потолку;
- Пользовать создаёт ключ на СКЗИ той системы, которая удовлетворяет УЦ, и заверяет запрос предыдущим ключом подписи — компромиссный паллиативный вариант, но многие используют.
Для решения этих проблем существуют стандарты, которые по всему миру работают нормально и универсально, и только в РФ с "финтами".
Всё, что нужно — чётко и ясно разделить ответсвенность, а дальше пусть каждый сам о себе заботится в рамках своей ответсвенности. Это не вопрос технологии, технология позволяет это сделать гарантированно и без проблем — это вопрос административного решения.
В нынешней ситуации ответсвенность за храниние закрытого ключа целиком и полностью возлагается на пользователя непосредственно по закону, но на практике пользователь никак не может свой закрытый ключ проконтролировать непосредственно с момента его создания! Фарс и абсурд.
Мало того, один из буржуйских УЦ мне, лет 7-8 назад, вообще закрытый ключ по почте присылал. ;)
И подход с заверенным предыдущим ключом подписи запросами, тоже используют, и в мире, и в РФ.
чётко и ясно разделить ответсвенность,Хм-хм. Но, строго говоря, с УЦ нельзя разделить ответственность! Он Бог и царь, по-любому! Скажем, регулярно ж, какие надо, спецслужбы с помощью различных УЦ выпускают сертификаты и подписывают то, что им надо от имени Microsoft, Google и т.п.
существуют стандартыМогу ошибаться, но мне кажется, что просто избранные в некоторых конкретных российских УЦ наборы стандартов Вас не удовлетворяют. Как там в Талмуде? Говорят: «Ему нравится тыква, а жене его огурцы»?
Закрытый ключ записывается на флешку или в реестр, а сертификат выпускается УЦ и отсылается Вам. затем Вы его можете внедрить в контейнер закрытого ключа (это даже может автоматически делаться при скачивании) и установить в системе.
Разумеется, все это секурно, т.к. закрытым ключом Вы нигде не светите, а открытый ключ на то и открытый, чтобы его можно было пересылать и выкладывать.
Точно так же на открытый ключ технически возможен выпуск нескольких сертификатов. Ведь сертификат открытого ключа не является частью открытого ключа. Это просто электронный документ, удостоверяющий легитимность этого ключа.
Думаю что обяжут УЦ перевыпустить бесплатно ключи со сроком действия на 3 месяца тем, кто попросит, и этим дело кончится. Если конечно это всё примут.
Госдуме бы стоило просто постановить считать 2020 год 2019ым.
1. Пара закрытого и открытого ключей формируется одновременно.
2. Открытый ключ передается в УЦ для выпуска сертификата.
3. После улаживания формальностей (предоставления документов, оплата услуги УЦ) происходит выпуск сертификата открытого ключа.
4. При этом между п.1 и п.3 может пройти значительное время.
5. Обычно это значительное время для организаций, работающих по ФЗ-44 и ФЗ-223 около 2-х недель (необходимо подготовить кучу бумажек, внести изменения в план закупок, утвердить их, дать отмашку бухгалтерии на оплату счета и т.д), но однажды у меня эта канитель растянулась на без малого два месяца.
6. Сертификат имеет срок начала действия на момент выпуска, а не на момент формирования пары ключей.
7. Т.е. в закрытом ключе не может и не должна содержаться информация о сроках действия.
8. Собственно говоря, она и в открытом ключе не содержится. Для этого и нужен сертификат.
Так что, утверждение о необходимости продления закрытого ключа не верно.
Другое дело, что в контейнере закрытого ключа для удобства переноса часто записывается сразу и сертификат открытого (если это не запрещено). Кроме того, т.к. в закрытом ключе нет информации о владельце, выпускающей организации и сроках действия (хотя это может быть неявно присутствовать в названии контейнера), то осуществляется привязка закрытого ключа и сертификата для удобства пользования.
Таким образом, для обеспечения работы необходимо не просто продлить срок действия сертификата, но перевыпустить его и обязать пользователя скачать его и произвести необходимые манипуляции, как минимум, по привязке нового сертификата и старого закрытого ключа.
Технически в этом ничего невозможного нет. Несколько лет назад, когда юрлица массово переводили то ли с простой ЭЦП на квалифицированную, то ли с квалифицированной на усиленную квалифицированную, как раз ровно это и происходило. Были выпущены новые сертификаты и разосланы оповещения с требованиями скачать их и установить.
Вот только с физлицами может быть все не так просто. Многие из них могут не обладать достаточной квалификацией для выполнения этих действий. А для многих даже оповещение не дойдет.
Во-первых, «голым» открытым ключом пользоваться реально неудобно. Это же просто набор больших чисел. Поэтому сертификат, помимо прочего, представляет собой удобную «обертку» для открытого ключа. Т.е. сертификат по-любому придется скачивать. Хотя бы потому, что ПО (в т.ч. и браузерные плагины) не умеет работать с голыми ключами. Зато с сертификатами работают за милую душу. Например, не отображают в списках просроченные сертификаты.
Во-вторых, при подписании документа в его ЭЦП входит как сам зашифрованный закрытым ключом хеш, так и сертификат, содержащий открытый ключ. Так что, сертификат так и так придется скачивать.
В-третьих, контейнер закрытого ключа может храниться не на криптотокене, а на простой флешке или даже в реестре. Конечно, это не по фен-шую и не
В четвертых, асимметричное шифрование-дешифрование — достаточно ресурсозатратная штука. Поэтому даже на десктопах и серверах оно применяется для работы с небольшими порциями информации — хешами или ключами симметричного шифрования. Заставлять убогий процессор криптотокена перебором выявлять, какой закрытый ключ соответствует открытому — дело безнадежное.
Т.е. теоретически возможно автоматизировать подписание нужным закрытым ключом по заданному открытому. Практически — лучше даже не пытаться это делать.
Во всяком случае, новый сертификат всё равно нужно будет скачивать.
Т.е., в принципе, наверное, все равно каким ключом в таком случае шифровать… но могут быть нюансы.
Заметим, что для большинства систем и алгоритмов это должно звучать как:«несколько контейнеров с одинаковыми закрытыми и открытыми ключами». Если же не ограничивать божественную милость, то: «несколько контейнеров с функционально эквивалентными закрытыми ключами и одинаковыми открытыми».
Так что открытых ключей там может и не быть. Иначе искать соответствующий закрытый было бы проще. Но все равно накладно.
1. — да, так и есть.
2. в УЦ передается запрос, содержащий открытый ключ, сведения о владельце ключа, информацию об алгоритме и т.д., а не просто открытый ключ.
3-5 не буду комментировать, зависит от многих факторов.
6. так и есть.
7. сам закрытый ключ — это всего лишь массив, вычисляемый по определенным алгоритмам. Контейнер ключа не есть закрытый ключ, контейнер ключа кроме ЗК содержит достаточно большое количество информации, в т.ч. сроки действия. (можете в криптопро нажать кнопку «протестировать»)
8. вы опять упрощаете. Сертификат кроме открытого ключа содержит массу информации.
далее вы пишете дичь. контейнер — это не то же самое, что ЗК. и я не знаю каким образом можно запретить записывать серт в контейнер. ограничение по перевыпуску связано не с техническими ограничениями. один запрос теоретически можно обработать сколько угодно раз и даже в разных УЦ, при этом срок действия можно указать любой. Все ограничения связаны с приказами ФСБ, МКС и иных органов.
Ситуация с перевыпуском неквалов для ФЭТП на квалы — это другой случай, там перевыпускались ЭП в рамках активных контрактов, а тут хотят чтобы истекающие подписи продлили, причем на 3 месяца. Разумеется УЦ этого не будут делать, и никакими распоряжениями их не получится заставить это сделать.
Контейнер ключа не есть закрытый ключ, контейнер ключа кроме ЗК содержит достаточно большое количество информации, в т.ч. сроки действия. (можете в криптопро нажать кнопку «протестировать»)
А я где-то утверждал обратное? Как раз я на этом и делал акцент.
Только если провести тестирование контейнера ЗК средствами Крипто Про, то можно увидеть, что информация о сроках действия берется не просто из него, а из записанного в него сертификата ОК.
я не знаю каким образом можно запретить записывать серт в контейнер.
Я тоже не знаком с подробностями, но мне один раз попался аппаратный криптотокен, на который нельзя не только записать сертификат ОК, но и посмотреть уже записанный. Во всяком случае, извлечь его при помощи Крипто Про не получилось — ругался, что это запрещено. Наверное, для этого было нужно специализированное для этого криптотокена ПО.
Для чего так было сделано — не знаю. Ведь сертификат, по идее, можно извлечь из подписанного документа. Наверное, чтобы УЦ брал еще денежку за обслуживание токена.
Что касается п.п. 3-5, то бывало и за пол дня сертификат выпускали, когда приспичило. Но обычно это затягивается. То секретарь шибко занят, то директор на совещании (объезде, сексуальном часе в горадминистрации), то человек, на которого сертификат оформляется, неделю забывает паспорт принести, то в ОК не могут найти приказ о назначении на должность, то в УЦ документы не принимают, потому что закорючка подписи в заявлении отличается от закорючки в паспорте… или дату заверения копии не проставили… или еще что, то съездить в представительство УЦ не на чем — машину другой отдел одолжил.
Так что, если особо задницу не рвать, то от момента формирования криптопары до момента получения и установки сертификата как раз дней 11-12 проходит. Может быть больше, реже — меньше. Проверено веками…
Во всяком случае, извлечь его при помощи Крипто Про не получилось — ругался, что это запрещено.
Не показатель. Особенно с каким-нибудь относительно стареньким eToken.
Что такое открытый и закрытый ключи и из чего они состоят?
Из чего состоит контейнер закрытого ключа?
В чем отличие открытого ключа от сертификата и из чего состоит сертификат?
Что такое цепочка доверия и что такое самоподписанные сертификаты?
И т.д.
Кстати, я вот действительно не знаю, что представляет собой ключевая пара на эллиптических кривых?
Вот в RSA каждый ключ из пары — это 2 числа: d и n для закрытого ключа, e и n для открытого. А для ГОСТ 34.10-2012 как обстоит?
Пойду почитаю… Где-то я тут статью видел.
habr.com/ru/post/188958
habr.com/ru/post/191240
Ничего не понимаю… Может быть по Вашей ссылке попроще будет?
d — число, которое должно быть известно только владельцу ключа. Вычислить d по Q и G, и зная параметры кривой — сложная задача. При подписи используется d, при проверке подписи используется Q, G и кривая.
Скорее всего в итоге будет: заплати за год, получи подпись на 1 год 3 месяца.
Или если хочешь получить только 3 месяца бесплатно — заплати за работы.
Подпись бесплатна, но ее изготовление стоит денег (работа сотрудников УЦ). Ни кто же не запрещает брать за это деньги, даже закон.
Некоторые УЦ в сертификатах прописывают срок действия закрытого ключа. И опять же в формулярах на СКЗИ указано, что срок действия закрытого ключа не более 1 год и 3 месяца. Поэтому выпуская сертификат по старому запросу, т.е. в той же связке открытый закрытый ключ можно подвести пользователя под нарушение требований ФСБ к СКЗИ
Первый же вопрос человеку, связанному с IT — и будет ответ, что это невозможно
Почему невозможно то? Вот же, положил.
У сертификата открытого ключа есть атрибуты момента вступления в действие и момента истечения срока действия. Пока сертификат действует (согласно атрибутам) — можно с тем же открытым ключом сделать новый CSR и запросить у УЦ подписание.
А оне ж хотят, чтобы пользователи ничего не делали (ибо не умеют в массе своей). Чтобы старый сертификат просто продолжал действовать и после окончания срока действия. Я так понимаю.
Госдума постановила продлить криптографические сертификаты на три месяца