to post messages and comments.

Нашёл вменяемого УЦП. Это такой, который, проведя проверки, и ЭЦП по ГОСТу может продать, и SSL для сайтов, а если не может SSL для сайтов выпустить сам, ТАК ХОТЯ БЫ НЕ БУДЕТ ТУПИТЬ и предложит перепродать от другого УЦ, который может. И одновременно это не простой спекулянт иностранным SSL, который всё никак не догадается российскими ЭЦП заняться из того же окна. Вот на токенах и смарт-картах ГОСТ и RSA уже давно вместе, а почему тогда записывать их в разных местах.

Итак, встречайте: АНК.

Издание сертификата ЭП
SSL-сертификаты для HTTPS и TLS
Я уж и не верил, что когда-нибудь такое увижу. Для продажи SSL сотрудничает с польским Certum. Ну хотя бы так.

Если таких УЦ будет побольше, глядишь, кто-нибудь догадается ещё какие-нибудь совмещённые варианты делать. В КриптоПро есть ГОСТ для Authenticode, но действует только внутри предприятия, где доверие внутреннему УЦ. Кто-нибудь из УЦ мог бы это решение догадаться наружу выставить. Если от ГУЦ Минкомсвязи цепочка идти будет, это бы сразу решило многие проблемы.

Ещё плюсы УЦ:
У них можно купить смарт-карты еСМАРТ ГОСТ с отечественным криптопроцессором от Микрона (Зеленоград). еСМАРТ редко, где можно встретить, а у них вот есть. еСМАРТ ГОСТ, Рутокен ЭЦП 2.0 и еТокен от Алладин — это на данный момент все варианты с ГОСТами 2012го года (Стрибог). Кузнечика (2015й год) нет нигде, но хотя бы так. У Рутокена обновились только токены, а на смарт-картах до сих пор прошлое тысячелетие. Алладин — не вполне российский и сертификацию проходил довольно интересным способом, сертифицируется не всё изделие, а только модуль в нём. Так и остаётся еСМАРТ как лучший (кмк) вариант.
Держат сервис трансграничного электронного документооборота.

Минусы:
Похоже, удалённо ЭЦП записать не получится. Один-то раз, может, и получишь по почте новую СК, а через год что, выкинуть? Или новую получать, на которой не будет ещё не истёкших других сертификатов со старой, если они неизвлекаемые. Вот это не очень здорово.

Cписок аккредитованных удостоверяющих центров Минкомсвязи
Мучил меня вопрос: вот, допустим, не пускают нас в какие–то корневые сертификаты, ну вот а взяли бы мы сами сделали браузер, который из коробки поддерживает ГОСТ и доверяет нужным сертификатам. Или дистрибутив OS. Или инсталлятор, который установит сертификаты в хранилище корневых сертификатов, и будем распространять вместе со своими программами вместо куда менее полезных Яндекс.Баров. И вопрос был: а каким именно корневым сертификатам? Где список?

Ну у нас же есть электронные подписи в принципе, если отбросить ПО и сайты. Нашёл. Сначала думал, есть один сертификат Минкомсвязи, а от него через одно–два звена подписываются сертификаты удостоверяющих центров, а они дальше — конечным пользователям. Нет. Скачал корневые сертификаты БТП, ковырнул, а они там — самоподписанные. Стало быть, такой браузер или OS должен будет импортировать штук 415 сертификатов, вот сколько есть в реестре аккредитованных УЦ, да ещё у каждого по несколько с разным периодом годности. И никакого CRL, только парсить .xls если. И архив с корневыми сертификатами сходу не обнаруживается, это у каждого из 415 надо с сайта скачать и периодически обновлять.

Но что ещё ожидаемо, вот так сходу у них сертификат для сайта или для подписи ПО я не вижу, как получить здесь, например, хотя вот здесь я читаю, как разработчик подписывает ПО по ГОСТу. Толку от добавления корневого сертификата в доверенные, если УЦ не даёт сертификаты для сайтов и подписи ПО.

Посмотрел, каким корневым сертификатам есть доверие в разных средах исполнения, в первую очередь, Windows, и заметил, что среди них нет российских. RU-CENTER, ЛидерТелеком, Инвеб (isplicense.ru) и т. п. просто перепродают их, ну, может быть, делая скидку за счёт того, что им как–то проще документы проверить, зная местную специфику. Вот бы здорово через ГосУслуги на шару получать. Ведь там и так уже проверили личность. Но для этого надо ещё потрудиться над суверенитетом.

В Remote Desktop Connection Manager 2.7 пропала несекурная возможность хранить пороли сессий в XML-конфиге в открытом виде, в связи с чем можно поиметь некоторое количество секеса, при импорте RDG-файлика версии 2.2.

В моем случае, пароли сохраненные плейнтекстом переехали нормально, а пароли, зашифрованные через учетные данные пользователя — нет.

Если есть желание хоронить пароли и далее, нужно использовать сертификат для их шифрования и хранить его вместе с RDG, который генерится тулзой из Windows SDK:

makecert -sky exchange -e 01/01/2101 -r -pe -a sha1 -len 2048 -ss my -n "CN=RDCManCert"
microsoft.com

Обнаружил тут, что при бакапе 2012R2 CA не происходит обрезания у транзакшн-логов базы, хотя, по-идее, должно бы. Оказывается, то не бага, а фича и если не хочется такого — нужно рестартовать сервис CA в скрипте бакапа. Век жыви, чо )

en-us.sysadmins.lv

ЗЫЖ Скрипт бакапа CA, слепленный на коленке из г-на и п-лок: pastebin.com

Установка стороннего корневого сертификата на ондроед, без обязательного включения секурити пин-кодов, поролей, скрин-локов и прочей подобной радости. Андроид без рута — неюзабелен, многократно убедился уже 100 раз как минимум )))

wiki.pcprobleemloos.nl

а подскажите плиз, есть такой контейнер в винде: Trusted Root Certification Authorities.
Еще есть Intermediate.
Консоль "Сертификаты" в винде можно открыть от имени юзера и имени компьютера.
Вопрос: для юзера и компьютера эти контейнеры одинаковы?
Исходя из ответа на первый вопрос, еще один вопрос, если они разные, то сертификаты, которые раздаются через GP куда ложаться? в юзерские или компьютерные?
А если я распространяю сертификат, а он уже у меня есть, то он задваивается. Это нормально?
А если я хочу через политики распространить корневой сертификт только для пользователя?

предположим, что я сделаю RootCA, без доступа к сети, не в домене, и вообще выключенный.
у меня еще парочка SubCA, которые в домене, заверены рутом, выдают сертификаты и все хорошо.
вопрос, где тогда должны храниться списки отозванных сертификатов?
вроде же они должны собираться на руте? если да, то как их публиковать без сети? вручную переносить на subca?

Вебмани совсем долбанулись на голову. Мало того, что процедура продления сертификата X.509 для доступа к кошельку из браузера у них может выполняться только в двухнедельный зазор накануне срока истечения действия и требует именно IE (но не работает в восьмой версии, тем не менее), так еще и новый сертификат мне выдали со сроком действия 2 (два) месяца вместо обычного года.
Мне что, отныне этот ритуальный танец — поиск где-нибудь более-менее доверенной XP с шестым ИЕ и в интернете, импорт туда истекающего серта и реэкспорт потом продленного — теперь раз в два месяца исполнять? А почему не ежедневно, для вящей безопасности?