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

Я настраиваю свой первый 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

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

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

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

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

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