Як правильно налаштувати 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 Helper", вони зазвичай зарезервовані для сертифікатів CA або сертифікатів, спеціально виданих для підписання списків відкликання сертифікатів (CRL, список сертифікатів, які є недійсне) або запуск OCSP-сервера (подібний до CRL, але онлайн-сервіс, який надає статус дійсних сертифікатів).

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

authorityKeyIdentifierзазвичай хеш SHA-1 публічного ключа CA, що видає (хоча це можуть бути й інші значення). Якщо ви включите це розширення, значення повинно відповідати значенню subjectKeyIdentifierсертифіката CA, що видає .

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

З усього , що ви тільки дійсно потрібноbasicConstraints і extendedKeyUsage; Основні обмеження дійсно, дійсно повинні бути критичними (або ви щойно видали сертифікати ЦА!), а розширене використання ключів взагалі не є.