Как создать ЦС с помощью openssl *с минимальными затратами*

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

В этом вопросе три части.

Во-первых, как «аутентифицировать и шифровать [вещи]». Это обрабатывается использованием ключа и расширенным использованием ключа. В частности, такие биты, как digitalSignature (обмен ключами подписи, например Диффи-Хеллмана), keyEncipherment (передача ключей, например RSA), serverAuth и т. д.

Во-вторых, как не чеканить сертификаты. Для сертификатов конечного объекта (т. е. сертификатов сервера) вы удаляете базовое ограничение CA=true и удаляете биты keyCertSign. Вам по-прежнему потребуется промежуточный ЦС с возможностью подписывать сертификаты конечных объектов, потому что именно здесь применяется политика «этот ЦС может выдавать только эти имена».

В-третьих, как применить политику типа «этот ЦС может выдавать только эти имена». Согласно правилам IETF для PKIX в RFC 5280, вы можете сделать это в сертификате ЦС с помощью расширение ограничений имен. Подробнее см. в разделе 4.2.1.10.

Вы можете сделать это в соответствии с правилами CA/Browser Forum, потому что у них есть объекты политики. Но я не знаю, как это сделать под CA/B (это может быть то же самое, что и IETF).

Вы должны быть осторожны с оборудованием IETF. У них есть расширения, но нет правил. Поэтому вам нужно убедиться, что вы работаете в рамках существующего расширения, а не создаете новую политику. См. OID для сертификатов, выпущенных в соответствии с политикой IETF? на Список рассылки PKIX для получения более подробной информации.

Форум CA/B важен, потому что браузеры следуют правилам форума CA/B, а не IETF. У CA/B Forum и IETF разные требования в нескольких ключевых областях. Вот почему сертификат, созданный с помощью OpenSSL (который следует рекомендациям IETF), не проходит проверку в браузерах (которые следуют рекомендациям форума CA/B).

Сертификат, сгенерированный следующей командой: openssl req ...

Это раньше было способом сделать это, но не как это сделать сегодня. Сегодня он создает неверный сертификат (который может вызвать или не вызвать проблемы, в зависимости от вашего пользовательского агента). На указанный вами вопрос один ответ, в частности, говорит вам, почему это неправильно и как это сделать.

.. злоумышленник, который крадет мой закрытый ключ ..

Итак, вопрос в том, как свести к минимуму силу этого сертификата, чтобы он не мог подписывать дополнительные ключи, подписывать коды, шифровать электронные письма или делать что-либо, кроме как защищать https-соединение с определенным веб-сайтом?

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

С этой настройкой злоумышленник все еще может украсть удостоверение сертификата, если он получит свой закрытый ключ. Но поскольку этот сертификат сам по себе не является ЦС (в отличие от обычных самозаверяющих сертификатов), его нельзя использовать для подписи новых сертификатов.