Инфраструктура PKI

Конечно

По моему опыту, если видишь что-то странное, дорогое и связанное с безопасностью, в 100% случаев оно нужно для сертификации. Типа с этим EJBCA проверяющий просто кивнёт, поставит галочку и пойдёт дальше по чек-листу, а с твоими подходом выкатит дополнительный счёт на $10k за попытку сертификации твоего велосипеда (с негарантированным результатом).

Если делаешь в нетребовательной сфере, то скорее всего и вообще готовые бесплатные решения есть (например, просто хранить секреты можно в Vault, про генерацию не знаю).

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

Короче, есть причины. Почитай описание продукта, который критикуешь. Там наверняка не только список фич, но и список сертификаций. И вот цена такая какая есть именно из-за них.

Там не только распределение ответственности, но ещё и возня с развёртыванием и поддержкой этой PKI и бесконечным обучением всех причастных, бесконечными аудитами и проверками, бесконечными юридическими тяжбами и разбирательствами кто выпустил Васе сертификат. Технически сама PKI конечно же ничего не стоит, все затраты на людей вокруг неё.

Да я особо и не критикую ничего.

Как и в любой другой сфере и любом другом ПО, платят за сертификацию, соответствие требованиям по внедрению, и поддержку.

OpenSSL это библиотека для работы с криптографией и набор программ вокруг нее. Она ничего не знает про требования к составу сертификатов, про политику их хранения и обращения с ними, это просто техническая утилиза, а не решение для PKI.

Чтобы вам сделать свой сервис PKI на основе OpenSSL, нужно изучить технические требования к сертификатам и сопоставить их со своими сценариями использования, подумать о безопасности хранения всех данных, придумать иерархию и время жизни сертификатов. Если речь идёт о серьёзном внедрении, нужно также развернуть публичные сервисы OCSP и CLR, изучить лучшие практики, возможно изучить сертификационные требования, чтобы хотя бы подумать, почему они такие.
А другие люди уже изучили это за вас и сделали продукт, готовый к использованию и внедрению.

Публичная инфраструктура PKI (те сертификаты, что в браузерах) должны соответствовать требованиям Certification Authority/Browser, который одним из пунктов требует хранение CA в аппаратном модуле в неизвлекаемом виде, а также логировать все выпускаемые сертификаты в несколько публичных сервисов.

И за примером дикого несоответствия далеко ходить не нужно: CA Минцифры, который не соответствует даже техническим правилам по наличию необходимых X509-полей Certification Authority/Browser, и его нельзя включить в состав браузера сугубо по техническим причинам уже даже на этом этапе.

OpenSSL это библиотека для работы с криптографией и набор программ вокруг нее. Она ничего не знает про требования к составу сертификатов

Ну как минимум OpenSSL понимает формат x509 и отвечает требованиям FIPS 140. А большего от неё никто и не требует.

который одним из пунктов требует хранение CA в аппаратном модуле в неизвлекаемом виде

на практике, если сертификатов дохрена, никто не будет покупать кучу HSM, в нём будут, возможно, храниться наиболее часто используемые ключи, а остальные выгружаются в шифрованную внешнюю БД. Этим требованием подтираются.

По-моему ЦС не хранит приватные ключи выпущенных сертификатов. Вообще-то запрос сертификата CSR не содержит приватного ключа. ЦС должен хранить в HSM только один приватный ключ — приватный ключ ЦС. HSM подписывает выпускаемые сертификаты этим приватным ключом. Если поток запросов большой, то требуется HSM высокой производительности.

База данных нужна наверное только для учета выпущенных сертификатов.

Это первое. А ещё с велосипедом есть вероятность рукожопства того, кто этот велосипед собирал, что может чисто гипотетически вылиться потом в гораздо больше затраты, чем просто купить готовое решение, которое уже проверено и с гарантией от поставщика.

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

А там даже без сертификации будет весело с велосипедом. Как только до ИБ дойдёшь, где потребуют обосновать каждый эндпоинт апихи, например, сразу подумаешь, что проще и дешевле было заплатить один раз за готовое и сертфицированное. Последнее, кстати, не исключает общения с ИБ, но может сильно упростить.

Какое ещё ИБ? ФСБ что ли? Общаться я буду только с клиентом.

Какое ещё ИБ? ФСБ что ли?

Отдел информационной безопасности.

Общаться я буду только с клиентом.

Ну да. А у него есть отдел ИБ. И вот ставишь ты ему велосипед, а клиентские безопасники говорят «А обоснуй-ка, почему вот тут…». А ты и не знаешь, и обосновать не можешь, и сделать с этим ничего не можешь. Тогда как с готовым решением ты можешь просто переадресовать вопрос поставщику, и этот вопрос он скорее всего порешает.

Безопасники очень лютуют в некоторых местах. В банке, например, могут не пропустить установку ОС на ВМ, если там выделенное место на раздел больше, чем согласованное, или открытый порт не соответствует таблице, которую они согласовали.

Вообще-то нормальный клиент сначала смотрит, что покупает. Я ему сразу все апи покажу.

Я ему сразу все апи покажу.

А если они не пройдут проверку ИБ? В случае с готовым решением ты можешь просто показать бумажку сертификата, а в случае с велосипедом? Ну просто потеряешь денежку и клиента, в принципе ничего страшного.

Ну как минимум OpenSSL понимает формат x509 и отвечает требованиям FIPS 140. А большего от неё никто и не требует.

Давайте так: клиенту нужен кипятильник, вы берёте два лезвия, спичку, два провода, соединяете, и отдаёте клиенту.

Технически это MVP кипятильника, да, и выполняет его функции. Но клиент имел в виду законченное изделие, которым пользоваться безопасно и удобно.

OpenSSL — это библиотека, низкоуровневая составляющая, работающая с техническим форматом. В нёй нет даже концепции PKI — формально все необходимые операции поддерживаются, но вам их нужно будет программировать самостоятельно.

Вы уверены, что обладаете необходимой квалификацией и навыками, чтобы написать и валидировать ваш код для PKI-инфраструктуры?

на практике, если сертификатов дохрена, никто не будет покупать кучу HSM

На практике ВСЕ хранят сертификаты в HSM. До недавнего времени Microsoft для code signing certificates позволяла их хранить в виде файлов, но после их систематической кражи и подписывания malware, теперь и code signing в HSM хранятся.

Что-то тут всё смешлось, кони, люди, сертификаты, HSM, микрософт.

HSM нужны для хранения закрытых ключей, начнём с этого, сертификаты там хранятся, но их можно и на лоре хранить, это публичные данные.

Все НЕ хранят сертификаты в HSM. code signing certificates для микрософта это такое крохотное подмножество всех сертификатов. 99% сертификатов это веб-серверы, и в 99.99% веб-серверов сертификаты хранятся в файлах. Для андроида не нужно HSM. Для Apple не нужно HSM. То, что микрософт выдумала какую-то ерунду, чтобы усложнить жизнь своим разработчикам, не делает их всеми. Там, кстати, смешно. Как я понял, очень многие разработчики теперь тупо хранят сертификаты в облаке (например AWS CloudHSM), увеличило ли это безопасность - вопрос, конечно, открытый.

Реально HSM нужен для ключей самого УЦ, как самых ценных и самых геморройных для перевыпуска. Для остального - сомнительно.

Ну я имел в виду клиентские сертификаты+ключ, которые пользователи хранят в том или ином HSM (в TPM-смарт-карте или аппаратном ключе), про веб-серверы забыл совсем.

Это только подтверждает обширность PKI-инфраструктуры.