Снова пришлось упражняться с криптографией в исследовательских целях: надо было поднять свой (недоверенный в домене УЦ и проверить с ним некоторые штуки). Необходима была цепочка УЦ, т.е. что-то типа: Корневой УЦ --> Еще УЦ --> уже мой сертификат:
Инструмент - OpenSSL.
Пост пишу, главным образом для себя, чтобы в следующий раз не тратить время, а просто сделать по описанному порядку.
После того, как OpenSSL скачали и поставили.
1. Делаем корневой УЦ.
1.1. Делаем для него папку и подпапки:
Текстовый файл не содержит ничего (комментарий).
serial - содержит текущий сериальный номер сертификата.
serial.old - будет сделан после выпуска сертификата - там запишется предыдущий.
index.txt - надо сделать пустым. Все остальные index.txt.* сделаются после выпуска сертификата с этого УЦ.
openssl.cnf - копия дефолтного с незначительными изменениями, применительно к данному CA. Файл снабжен понятными комментариями.
1.2. Выпускаем корневой, самоподписанный сертификат:
openssl req -new -x509 -days 3650 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -config openssl.cnf
При этом секретный ключ будет положен cakey.pem, сертификат - в cacert.pem.
2. Делаем выпускающий УЦ, подчиненный нашему корневому.
2.1. Такую же структуру папок:
В папку clients будем складывать сертификаты и pfx-ы клиентов (вручную, само туда класться не будет - чтобы корневая папку УЦ не засорялась).
2.2. Делаем запрос на сертификат выпускающего УЦ (почему-то я его назвал Subordinate):
openssl req -new -days 3650 -keyout private/subcakey.pem -out subcareq.pem -config openssl.cnf
2.3. Идем на наш Корневой УЦ (== просто делаем туда CD) и выпускаем сертификат на только что сделанный запрос (подписываем запрос):
openssl ca -in ..\subca\subcareq.pem -extensions v3_ca -config openssl.cnf
3. Выпускаем сертификат для пользователя.
3.1. Идем на наш подчиненный УЦ (выпускающий УЦ) и делаем там запрос для пользовательского сертификата:
openssl req -new -days 365 -keyout key.pem -out req.pem
3.2. Подписываем запрос ключем УЦ:
openssl ca -in clients\req.pem -out clients\cer.cer -config openssl.cnf
3.3. Делаем из PKCS#12 (сшиваем ключ и сертификат в PFX):
openssl pkcs12 -export -out cer.pfx -inkey key.pem -in cer.cer
3.3* Иногда бывает нужно вытащить из PFX только секретный ключ, иногда хочется его вытащить и сохранить без шифрования, - команда ниже:
openssl pkcs12 -in ppp.pfx -out ppp.pem -nodes
Ключ будет сохранен в ppp.pem.
Ошибки.
1. Иногда, когда много раз упражняемся с выпуском сертификатов для одного пользователя, возможно возникновение ошибки при вызове команды п. 3.2
.....
Sign the certificate? [y/n]:y
failed to update database
TXT_DB error number 2
Здесь проблема связана с тем, что в одном CA OpenSSL не может быть более одного сертификата с одинаковыми параметрами. Для решения необходимо отозвать старый сертификат этого пользователя и повторить команду. Отозвать можно так:
openssl ca -revoke clients\certfilename.cer -config openssl.cnf
2. Для организации S/MIME в Outlook сертификат должен иметь определенные keyUsage и extendedKeyUsage:
Для указания этого OpenSSL проще отредактировать openssl.cnf:
[ usr_cert ]
....
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = critical, emailProtection
....
Инструмент - OpenSSL.
Пост пишу, главным образом для себя, чтобы в следующий раз не тратить время, а просто сделать по описанному порядку.
После того, как OpenSSL скачали и поставили.
1. Делаем корневой УЦ.
1.1. Делаем для него папку и подпапки:
Текстовый файл не содержит ничего (комментарий).
serial - содержит текущий сериальный номер сертификата.
serial.old - будет сделан после выпуска сертификата - там запишется предыдущий.
index.txt - надо сделать пустым. Все остальные index.txt.* сделаются после выпуска сертификата с этого УЦ.
openssl.cnf - копия дефолтного с незначительными изменениями, применительно к данному CA. Файл снабжен понятными комментариями.
1.2. Выпускаем корневой, самоподписанный сертификат:
openssl req -new -x509 -days 3650 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -config openssl.cnf
При этом секретный ключ будет положен cakey.pem, сертификат - в cacert.pem.
2. Делаем выпускающий УЦ, подчиненный нашему корневому.
2.1. Такую же структуру папок:
В папку clients будем складывать сертификаты и pfx-ы клиентов (вручную, само туда класться не будет - чтобы корневая папку УЦ не засорялась).
2.2. Делаем запрос на сертификат выпускающего УЦ (почему-то я его назвал Subordinate):
openssl req -new -days 3650 -keyout private/subcakey.pem -out subcareq.pem -config openssl.cnf
2.3. Идем на наш Корневой УЦ (== просто делаем туда CD) и выпускаем сертификат на только что сделанный запрос (подписываем запрос):
openssl ca -in ..\subca\subcareq.pem -extensions v3_ca -config openssl.cnf
3. Выпускаем сертификат для пользователя.
3.1. Идем на наш подчиненный УЦ (выпускающий УЦ) и делаем там запрос для пользовательского сертификата:
openssl req -new -days 365 -keyout key.pem -out req.pem
3.2. Подписываем запрос ключем УЦ:
openssl ca -in clients\req.pem -out clients\cer.cer -config openssl.cnf
3.3. Делаем из PKCS#12 (сшиваем ключ и сертификат в PFX):
openssl pkcs12 -export -out cer.pfx -inkey key.pem -in cer.cer
3.3* Иногда бывает нужно вытащить из PFX только секретный ключ, иногда хочется его вытащить и сохранить без шифрования, - команда ниже:
openssl pkcs12 -in ppp.pfx -out ppp.pem -nodes
Ключ будет сохранен в ppp.pem.
Ошибки.
1. Иногда, когда много раз упражняемся с выпуском сертификатов для одного пользователя, возможно возникновение ошибки при вызове команды п. 3.2
.....
Sign the certificate? [y/n]:y
failed to update database
TXT_DB error number 2
Здесь проблема связана с тем, что в одном CA OpenSSL не может быть более одного сертификата с одинаковыми параметрами. Для решения необходимо отозвать старый сертификат этого пользователя и повторить команду. Отозвать можно так:
openssl ca -revoke clients\certfilename.cer -config openssl.cnf
2. Для организации S/MIME в Outlook сертификат должен иметь определенные keyUsage и extendedKeyUsage:
Для указания этого OpenSSL проще отредактировать openssl.cnf:
[ usr_cert ]
....
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = critical, emailProtection
....
No comments:
Post a Comment