schors Sep 13 2018 at 16:19

Корневые и промежуточные сертификаты уполномоченных Удостоверяющих Центров России

2 min

22K

Information Security*Open source*

+63

Comments 22

UFO just landed and posted this here

schors Sep 13 2018 at 23:00

Это кстати отдельная интересная мысль. Например, полный ад с банк-клиентами. Но это отдельная тема с реализацией ГОСТ. Там всё на самом деле так себе. Хорошие реализации там только на языке (человечьем в смысле, все говорят «а вот мы, а вот у нас»), но в реалии даже openssl реализацию бы переработать. Есть и python, и golang, и даже java, но всё скорее акадимическое, чем продакшн реди

UFO just landed and posted this here

Newcss Sep 14 2018 at 09:43

К казначейству с этими ключами подключались 3 месяца).

Bessnov Sep 14 2018 at 09:43

Молодец! Интересное накопал.
Только, для кого написаны Ридми на английском языке по ссылкам на гитхабе?
Англоязычным оно не сильно интересно будет. У них своя доверенная криптография.

schors Sep 14 2018 at 09:47

Ответа три:
1. Тренируюсь. У меня очень плохой английский.
2. Вырабатываю привычку не халявить, а писать сразу для всех.
3. Субъективно считаю, что в IT как в науке — выстрелит только то, что не огораживается. И это беда тех же ГОСТов (неплохих в теории). Это реверанс в сторону популяризации.

Detuner Sep 14 2018 at 12:19

Спасибо, весьма полезная статья.
Мне постоянно приходится иметь дело с этим списком по роду деятельности. Там настоящий бардак: часть сертификатов промежуточные от корневого серта ПАК «ГУЦ», часть от ПАК «Минкомсвязь», а часть — вообще самоподписанные кросс-сертификаты. И поддерживать актуальный список сертов — это ещё полбеды. Так как не всегда и не у всех УЦ сервисы работают стабильно и быстро, нельзя полагаться на онлайн-проверку CRL. Приходится поддерживать локальное хранилище актуальных CRL — и вот это настоящая боль.

schors Sep 14 2018 at 12:33

Хм… Это интересно. Там в XML и crl есть. Т.е. я могу в принципе буквально за вечер сделать и актуальные crl. Я только сходу не понимаю как их смотрит тот же openssl, если их отдельно делать. Не сталкивался просто

Detuner Sep 14 2018 at 15:05

Вот тут не знаю. Хоть и пробовал OpenSSL с ГОСТовыми алгоритмами, но эту задачу не ковырял. На проде всё завязано на криптопро, поэтому серты и CRL держу в криптопрошном хранилище. Скрипт на bash периодически качает свежие CRL, поштучно сравнивает каждый с тем, что есть в хранилище с помощью certmgr и обновляет, если скачанный CRL новее. Если по ссылкам для одного серта качаются разные CRL, выбирается самый новый. Кстати, в последнее время стали появляться УЦ, у которых списки отозванных имеют вид «base CRL + delta CRL», с ними вообще отдельная песня.
В целом всё это работает удовлетворительно (самое узкое место — не очень быстрая работа из консоли с криптопрошным хранилищем), но есть большое желание переписать это всё на чём-то посерьёзнее bash'а и с использованием БД для хранения информации о сертах и CRL.

AleksGRV Sep 19 2018 at 00:20

В КриптоПро CSP присутствует механизм, при котором недостающие промежуточные сертификаты и CRL автоматически выкачиваются при построении цепочки, для квалифицированных сертификатов потребуется установить только сертификат ГУЦ. Так например отработает вызов – CertGetCertificateChain. Флаги этой функции позволяют управлять кэшированием при её вызове, например: CERT_CHAIN_REVOCATION_CHECK_CACHE_ONLY.

Detuner Sep 19 2018 at 09:48

Я как раз чуть выше писал об этом, механизм-то есть, но на него не всегда можно положиться. В моём случае подписание связано с критичной по времени операцией — подачей заявки на торговую площадку, а CRLы могут быть недоступны, выкачиваться медленно и т.п. Если из-за этого участник торгов не сможет вовремя подать заявку, объясняться придётся на разборе полётов в ФАС, а там практически нереально доказать, что виноват УЦ или провайдер. Поэтому всё должно храниться локально, постоянно обновляться и превентивно проверяться на предмет истечения срока действия.
PS: Мне нередко приходится звонить в различные УЦ и радовать их сообщениями о том, что у них по ссылкам просроченные CRL. Некоторые не сразу верят, приходится убеждать.

AleksGRV Sep 19 2018 at 00:02

Для проверки сертификатов по СОС в verify достаточно указать -crl_check, -crl_check_all. CRL следует поместить в один бандл с сертификатами

schors Sep 19 2018 at 00:03

Это если брать «колбаску». А если сертификаты по отдельности?

AleksGRV Sep 19 2018 at 00:11

Тогда полагаю следует использовать CApath, только придется с именами файлов повозиться (mod_ssl в Apache настраивается аналогично, директива SSLCARevocationPath)

schors Sep 19 2018 at 00:28

А куда копать на тему «повозиться»?

AleksGRV Sep 19 2018 at 00:32

Там ничего сверхсложного нет, но потребуется хеши считать

-CApath dir
a directory containing trusted CA certificates, only used with -verify. This directory must be a standard certificate directory: that is a hash of each subject name (using x509 -hash) should be linked to each certificate.

schors Sep 19 2018 at 00:46

Это я и так упомянул в статье. А с CRL что делать?

AleksGRV Sep 19 2018 at 01:07

Да то же самое что и для сертификатов (https://github.com/openssl/openssl/issues/1701)

schors Sep 19 2018 at 01:17

Хм. Спасибо

mrandrewer Sep 14 2018 at 13:55

Вот кстати да.
Столкнулись с тем, что в самом сертификате могут быть ссылки на внутренние и недействительные адреса CRL (Это УЦ Минобороны так шутит). Но зато в XML публикуется корректный адрес. Тем и спасаемся.

AleksGRV Sep 19 2018 at 01:15

Хотелось бы предупредить, что выкачивание всех промежуточных сертификатов не подходит для использования в openssl s_server. Упремся в лимит TLS 65535 bytes

Подробнее: https://github.com/openssl/openssl/issues/4819

Kealon Dec 29 2022 at 19:00

Бедовая тема. Все программы подписи требуют установки сертификатов, причём в корень и с правами на всё. И эти действия, только для того что бы подписать - явно излишни.

Хотелось бы статейку как ограничить это безобразие.

Show the best of all time