openssl в RHEL - подписать сертификат клиента с правами root без использования openssl.cnf? - PullRequest
Новая
       25

openssl в RHEL - подписать сертификат клиента с правами root без использования openssl.cnf?

0 голосов
/ 23 мая 2018

Попытка достичь своего рода самоподписанной установки PKI с использованием openssl на RHEL с несколькими оговорками.Я постараюсь предоставить здесь как можно больше информации.

Версии: RHEL 6.7 |OpenSSL 1.0.1e-fips 11 февраля 2013 г.

Предостережения / ограничения в сценарии: этот сценарий будет использоваться для создания нескольких наборов ключей - по умолчанию одна корневая пара ключей и сертификат и две клиентские пары ключей и сертификаты за цикл.Пользовательский ввод запрашивается для местоположения файла, имени файла и ключевой фразы на клиентских ключах.Все это было довольно просто, и у меня был скрипт, который запускал эти команды по запросу пользователя, и использовал файл openssl.cnf, чтобы указать на корневой ключ для подписи.Я использовал sed для изменения указателей местоположения в openssl.cnf на основе имени файла и успешно смог подписать сертификат клиента.

Однако есть два основных замечания:

  1. Меня попросили изменить сценарий, чтобы он не был динамически сценарием или другими файлами при каждом запуске,Значение openssl.cnf не должно редактироваться на лету, если это возможно.Однако если это необходимо для функционирования, то все должно быть в порядке.

  2. Пользователь должен иметь возможность запускать несколько наборов этого сценария ad hoc, особенно в отношении пар ключей клиента (У меня есть корневой сценарий и сценарий генерации клиента отдельно в пользовательском меню).То есть генерация пары ключей клиента необходима при наличии корневого ключа для сопоставления, но может выполняться несколько раз, и сценарий ключа клиента должен спрашивать пользователя, с каким корневым ключом следует связываться и подписываться?

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

Есть ли способ указать клиентский ключ на переменную, которую будет подписывать сертификат корневого ключа?(Вместо того, чтобы использовать openssl.cnf для записей 'certificate' и 'private_key'?)

На данный момент у меня есть:

корневой ключ и сертификат: 

openssl req -config $dir/openssl.cnf -new -x509 -days 3652 -nodes -sha384 -newkey ec:ec-secp384r1.pem -keyout $userdir/${rootName}_private.key -out $userdir/${rootName}.crt -subj "stuff_here"

...

export rootName

клиентские ключи и сертификаты: 

read -p "Which root key do you want to associate this client keypair with? Please type absolute filepath and filename (ending in .key); rkAssoc    #STILL NEED TO USE THIS VARIABLE

##KEY GENERATION
openssl req -newkey ec:ec-secp384rp1.pem -keyout $userdir/{$clientName}_privat.key -out $userdir/client/${clientName}.csr -subj "Stuff_here"

##SIGN CSR
openssl ca -config $dir/openssl.cnf -policy policy_anything -extensions usr_cert -days 730 -notext -md sha384 -in $userdir/client/${clientName}.csr -out $userdir/client/${clientName}_signedprivatekey.pem && echo "Client key created."

Итак, я думаю,

1) Правильно ли я подписал клиента (что-то не так в этом, но не уверен)

2) вместо ссылки -req openssl.cnf я полагаю, что, возможно, существует какой-то флаг, где вы могли бы сделать что-то более похожее на 

openssl ca ... -cert ${rkAssoc}

это удаленно правильно или я ухожу?

Спасибо заранее всем, кто протягивает руку.

1 Ответ

0 голосов
/ 23 мая 2018

OpenSSL имеет несколько способов сделать одно и то же.Вы нашли один из способов подписания CSR с openssl ca.openssl x509 может выступать в качестве мини-ЦС, поэтому, чтобы устранить необходимость в файле конфигурации, вы можете сделать что-то вроде: 

openssl x509 -req -in /tmp/mykey.csr.pem -CA /path/to/ca/mycacert.pem -CAkey /path/to/ca/cakey engine -CAserial /path/to/ca/myca.srl -days 3600 -out /tmp/mykeypub.cert.pem

Где -CA указывает на ваш сертификат корневого ЦС и -CAkeyна ваш корневой ключ CA.

...