Как правильно отправлять ssl сертификаты?

Question

[Sergey Ilichev]

Всем привет)

Есть пару вопросов по сертификатам ssl, может кто поможет разобраться?

От предыдущего разработчика достался код, где идет подключение к одному сервису. Обращение к тому сервису происходит curl запросом с отправкой ssl сертификата. Сертификат истек. Посмотрел инструкцию для подключения к сервису. Там написано, что нужно с помощью OpenSSL сгенерировать новый сертификат и отправить им на подпись.

Вот команда openssl req -new -newkey rsa:2048 -nodes -keyout cert.key -sha1 -out cert.csr

Но не успел я им ничего отправить, как они прислали мне новый сертификат.

1) Как они его сгенерили без реквеста? Типа по старому реквесту? То есть реквест не имеет срока годности?

2) Сертификат который они мне прислали, если посмотреть через специальную программу, на макбуке это keychain access, то видно что в качестве домена указан наш домен develop среды. Но запросы при этом по этому сертификату отправляются с любого другого домена. Зачем тогда в сертификате вообще указывать домен, если можно отправлять запросы с любого? Или они это как-то настраивают, когда подписывают сертификат на своей стороне? Я просто думал, что если сертификат создан для определенного домена (указан common name), то запросы по этому сертификату будут работать только с этого домена.

3) Среди сертификатов на этом проекте лежало два ключа. Один с объявлением

-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----

Второй

-----BEGIN RSA PRIVATE KEY-----
----END RSA PRIVATE KEY-----

Я проверил оба этих ключа на принадлежность сертификату с помощью команд для вычисления хэша модуля сертификата:

openssl x509 -noout -modulus -in <имя_файла>.crt | openssl md5
openssl rsa -noout -modulus -in <имя_файла>.key | openssl md5

Оказалось, что хоть эти ключи и выглядят по разному, но оба подходят к сертификату. Почитал про разницу этих ключей. Оказалось что это один ключ, но в разных форматах, первый в новом формате PKCS8, а второй в старом формате PKCS1. Разница только в том, что в новом формате в ключе зашифрован его тип, если я правильно понимаю.

3.1 Я попробовал отправлять запросы с обоими ключами, но вышло только с ключом в новом формате PKCS8, почему, они же одинаковые?

3.2 Отправить запрос получается только в том случае, если ключ указан в самом файле сертификата, то есть я их объединил в один файл и тогда запрос заработал. Почему по отдельности не работает?

3.3 Правильно ли я понимаю, что формат ключа PKCS1 и PKCS8 не имеют ничего общего с форматом pem? То есть файл формата pem может быть в формате PKCS8, типа как какой-то подформат? Или все такие это вообще разные форматы и если файл в формате PKCS8, то это значит что он не формата pem?

3.4 Форматы PKCS1 и PKCS8 это форматы только для ключей или для сертификата тоже?

3.5 Если это форматы и для сертификата, то может быть так, что старый ключ хоть и принадлежит сертификату, но с ним запросы не отправляются потому что он в формате PKCS1, а сам сертификат допустим в формате PKCS8? То есть сертификат и ключ должны быть в одном формате?

3.6 Можно ли как-то определять форматы ключа и сертификата? Я так понимаю что расширение файла вообще ни о чем не говорит? То есть может быть сертификат с расширением .pem, но при этом формат ключа может быть PKCS8?

Буду благодарен, если кто-то сможет ответить хотя бы на часть этих вопросов.

Answer 1

[CityCat4]

То есть реквест не имеет срока годности?

Нет. CSR - это просто набор информации

Но запросы при этом по этому сертификату отправляются с любого другого домена. Зачем тогда в сертификате вообще указывать домен, если можно отправлять запросы с любого?

Зачем в паспорте стоит адрес регистрации, если при покупке бухла его не смотрят? Затем, что могут посмотреть в другом случае. Валидация по клиентскому сертификату в самом простом случае может проходить просто по самому факту выдачи сертификата определенным CA. В этом случае совершенно неважно, какое там CN вписано. Также валидация может проходить и по CN, и по дополнительным полям сертификата.

Отправить запрос получается только в том случае, если ключ указан в самом файле сертификата, то есть я их объединил в один файл и тогда запрос заработал. Почему по отдельности не работает?

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

Правильно ли я понимаю, что формат ключа PKCS1 и PKCS8 не имеют ничего общего с форматом pem?

PEM - вид хранения информации. Неявно подразумевает формат BASE64-хранения. Есть еще формат DER - хранение в двоичном виде. PEM можно передавать по почте, вставлять в документы - это текст. DER нельзя.

Answer 2

[ky0]

Универсальное правило - не использовать в продуктиве любые сертификаты, приватный ключ которых генерировали не вы и который куда-то отправлялся. Если нужно обновить/перевыпустить - сами генерируете ключ, из него CSR и отправляете куда надо, а уж там пусть делают, что хотят.

В целом - если речь идёт об общедоступных доменных именах (под вашим контролем), то все пляски с удостоверяющими центрами решаются однократной настройкой Let`s Encrypt.

Answer 3

[Saboteur]

3.4 Форматы PKCS1 и PKCS8 это форматы только для ключей или для сертификата тоже?

https://en.wikipedia.org/wiki/PKCS

3.2 Отправить запрос получается только в том случае, если ключ указан в самом файле сертификата, то есть я их объединил в один файл и тогда запрос заработал. Почему по отдельности не работает?

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

Но не успел я им ничего отправить, как они прислали мне новый сертификат. Как они его сгенерили без реквеста? Типа по старому реквесту? То есть реквест не имеет срока годности?

Генерация сертификатов для общения двух сервисов договаривается между разработчиками этих сервисов. Если вы используете самоподписанные сертификаты, то любой может сгенерить. Если вы используете один и тот же CA, доступный обеим командам, любая команда может запросить новый сертификат. Если вы работаете в разных компаниях, у каждой есть свой внутренний CA и процедура получения сертификатов, тогда они бы не могли сгенерировать новый сертификат, но раз смогли то у час не этот случай.

Но запросы при этом по этому сертификату отправляются с любого другого домена. Зачем тогда в сертификате вообще указывать домен, если можно отправлять запросы с любого?

Обычно сертификат лежит на сервере, который соответствует домену, а не на клиенте.
Вы же когда на google.com ходите по HTTPS, то можете это делать с любого компа, а не только с сервера гугла?

Вам нужно просто разобраться зачем у вас используются сертификаты - для TLS, для двухстороннего TLS или для авторизации.
Нужно разобраться как у вас проверяется валидация - может у вас просто стоит ignoreinvalidcert и все
Никто кроме вас в вашем приложении не разберется. Поднимите кого-то из тех, кто принимал архитектурное решение и выясните как у вас надо делать, и так и делайте. А то вполне возможно что у вас даже так как планировали сейчас не работает.