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

[@schors]

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

[@Newcss]

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

[@Bessnov]

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

[@schors]

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

[@Detuner]

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

[@schors]

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

[@Detuner]

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

[@AleksGRV]

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

[@Detuner]

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

[@AleksGRV]

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

[@schors]

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

[@AleksGRV]

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

[@schors]

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

[@AleksGRV]

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

-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]

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

[@AleksGRV]

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

[@schors]

Хм. Спасибо

[@mrandrewer]

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

[@AleksGRV]

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

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

[@Kealon]

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

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