Как правильно настроить openssl CA для генерации клиентских сертификатов ssl

Question

Я настраиваю свой первый CA. Его целью будет выпуск сертификатов для наших клиентов, которые будут использовать их для доступа к нашей услуге EDI через https. Поэтому мне нужно сгенерировать клиентские сертификаты ssl. Весь процесс подписания сертификатов уже работает, и сертификаты могут быть успешно использованы для доступа к нашему сервису, но меня беспокоит одна вещь:

Сгенерированные цели сертификата являются способом общего:

$ openssl x509 -purpose  -noout -in client.crt.pem
Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : Yes
S/MIME signing CA : No
S/MIME encryption : Yes
S/MIME encryption CA : No
CRL signing : Yes
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No

Я чувствую, что в моем случае не должно быть никаких других целей, кроме подписи клиента SSL и S/MIME. Я ошибаюсь, и это должно остаться так, как есть?

Если я прав, и мне нужно отключить другие цели, что я должен добавить в свой конфигурационный файл openssl.cnf?

Вот мой текущий конфиг (немного раздетый):

[ CA_edi ]
# here was directory setup and some other stuff, cut it for clarity
x509_extensions = usr_cert      # The extentions to add to the cert

name_opt    = ca_default        # Subject Name options
cert_opt    = ca_default        # Certificate field options
# Extension copying option: use with caution.
# copy_extensions = copy
# stripped rest of config about validity days and such

[ usr_cert ]

basicConstraints=CA:FALSE
nsCertType = client, email
keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement

Что я делаю не так, что сгенерированные сертификаты позволяют использовать сервер?

Answer 1

Вы вправе беспокоиться о "подписывании CRL", "CA любого назначения" и "помощнике OCSP", обычно они зарезервированы для сертификатов CA или сертификатов, специально выпущенных для подписи списков отзыва сертификатов (CRL, список сертификатов, которые недопустимый) или работает сервер OCSP (аналогично спискам отзыва сертификатов, но онлайн-сервису, который предоставляет статус достоверности сертификатов).

Соответствующая страница документации OpenSSL предназначена для команды x509 и x509v3_config

Вот конфигурация OpenSSL, которую я использую для генерации клиентских сертификатов:

[user]
basicConstraints = critical,CA:FALSE
extendedKeyUsage = clientAuth,emailProtection
subjectAltName=email:copy
crlDistributionPoints = URI:http://www.rgweb.org/ca/rgweb-ca.crl
authorityKeyIdentifier=keyid:always
authorityInfoAccess = caIssuers;URI:http://www.rgweb.org/ca/rgweb-ca.cer

Я проведу вас через это построчно:

basicConstraints установлена как критическая, что означает «отклонить этот сертификат, если вы не понимаете этот бит», и указывает, что сертификат не является центром сертификации. Даже если кто-то использует программное обеспечение для выдачи сертификата из этого сертификата, ему никогда не будут доверять.

Использование расширенного ключа не является обязательным, но для некоторых программ требуется, чтобы оно присутствовало и имело конкретные цели в списке. Здесь перечислены аутентификация клиента (о чем вы говорите), а также подпись и шифрование электронной почты S/MIME; Вы можете безопасно удалить цель S/MIME, если она вам не нужна.

subjectAltName позволяет вам включить информацию о предмете, которую вы не можете включить в поле subject . Он также используется в сертификатах веб-сервера для включения доменных имен, которые сертификат может использовать для домена, отличного от домена, указанного в атрибуте общего имени субъекта; эти сертификаты называются сертификатами SAN (альтернативное имя субъекта). Обычной практикой является включение адреса электронной почты в subjectAltName а не в тему; вам не нужно указывать адрес электронной почты вообще, и вы можете опустить расширение.

crlDistributionPoints перечисляет места, в которых доступен CRL для органа выдачи; он сообщает программному обеспечению, которое пытается проверить сертификат, «вот где можно проверить, действителен ли этот сертификат». Для использования в Интернете лучше использовать URL-адрес http:// (CRL имеют цифровую подпись, поэтому нет необходимости в https , и это может вызвать проблемы с циклом доверия).

authorityKeyIdentifier обычно является хешем SHA-1 открытого ключа выдающего ЦС (хотя это могут быть и другие значения). Если вы включите это расширение, значение должно соответствовать значению subjectKeyIdentifier в сертификате выдающего ЦС.

authorityInfoAccess немного напоминает crlDistributionPoints , но он определяет , где получить сертификат выдающего центра сертификации , а не CRL. Это полезно, если у вас длинная цепочка доверия: например, CA-1 выдает CA-2, который выдает CA-3, который выдает сертификат; программное обеспечение, пытающееся проверить сертификат, может использовать это расширение для получения сертификата CA-3, затем использовать значение в этом сертификате для получения сертификата CA-2 и т. д. Обычно цепочка сертификатов (в данном случае сертификат CA-2). и сертификат CA-3) связан с сертификатом субъекта (например, в транзакции SSL или электронной почте S/MIME). Я не знаю ни одного программного обеспечения, которое использует это расширение, но я не знаю, что оно также не используется. Это обычно включается в сертификаты.

Из всего этого вам действительно нужны только basicConstraints и extendedKeyUsage ; основные ограничения действительно, действительно должны быть критическими (или вы только что раздали сертификаты CA!), а расширенное использование ключа обычно не является.