Search
Write a publication
Pull to refresh
0
0
Send message
Ну, по идее, УЦ это волновать не должно.
Если посмотреть на SSL-сертификаты, то там УЦ, как правило, всегда принимают сертификат на подпись без предоставления закрытого ключа. И цена компрометации закрытого ключа порой выше чем у ЭП :)
Было бы здорово если бы УЦ предоставляли оба варианта. Генерят сами или подписывают сертификат клиента.

В комментариях ниже увидел, что оказывается пары ключей должны создаваться только сертифицированным ПО. Это немного усложняет дело, однако проблема все равно остается.
То есть они принимают сертификат на подпись без предоставления закрытого ключа?
А теперь самый интересный вопрос. С какими полями надо сформировать сертификат для получения усиленной квалифицированной подписи физику?
К сожалению так и не смог найти нормальной инструкции. (я умею создавать сертификаты, просто непонятно какие поля в этом сертификате должны быть)

Сохранил в закладки, спасибо!
По хорошему мы сами должны генерить закрытый ключ и отдавать УЦ только сертификат на подпись. Дабы закрытый ключ знал только владелец сертификата.
Интересно, есть УЦ которые так умеют?
И как тогда правильно самому сгенерировать сертификат?)

Мы храним локальное зеркало репы debian (благодаря этому получаем профит по скорости локальной сборки пакетов). Само зеркало делаем утилитой ftpsync.
А для хранения своих пакетов используем aptly. Он предоставляет очень удобное API для загрузки и публикации пакетов в репе. И не надо делать кучу магических скриптов :)

Information

Rating
Does not participate
Location
Россия
Registered
Activity