Что делать если у меня CURL: Peer’s Certificate has expired?
Столкнулся с небольшой проблемой в процессе рядовой и будничной процедуры регистрации на одной из торговых площадок госсзакупок. Все обычно проходит без проблем, все привыкли к ключам, регистрациям и чаще всего пользователи сами способны по инструкции сделать все необходимое. Но тут возник затык и меня попросили помочь разобраться.
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти вступительный тест.
Речь пойдет конкретно про сайт zakupki.mos.ru, но ключ используют не только на этом сайте. Он универсальный и подходит для очень многих торговых площадок. А ошибка вообще не имеет прямого отношения к сайту, а относится к вопросу использования электронных цифровых подписей.
Использован не доверенный сертификат. Не удалось подписать: Не удается построить цепочку сертификатов для доверенного корневого центра. (0x800B010A)
Ошибка по большому счету понятная, но не ясно, как ее исправить, с учетом того, что все необходимые сертификаты, в том числе и корневого центра сертификации, были установлены. Идем их проверять. Для этого открываем оснастку CryptoPro:
Идем в раздел: Сертификаты — текущий пользователь — Личное — Реестр — Сертификаты. Открываем наш сертификат и смотрим его свойства. Конкретно нас интересует раздел Путь сертификации. К сожалению, у меня не осталось скриншотов до решения проблемы, поэтому придется описывать словами, в чем там дело. Потом покажу, как должно все выглядеть, чтобы нормально работало.
Цепочка сертификатов выглядела следующим образом: УЦ 1 ИС ГУЦ — АО «ЕЭТП» — Сертификат пользователя. При этом в корневом сертификате УЦ 1 ИС ГУЦ была ошибка в виде сообщения:
Невозможно обнаружить поставщика этого сертификата
А в его свойствах еще одна ошибка:
Недостаточно информации для проверки этого сертификата
При этом сертификат УЦ 1 ИС ГУЦ был на компьютере в списке доверенных корневых центров сертификации. Проверить это можно через ту же оснастку CryptoPro в соседней ветке: Доверенные корневые центры сертификации — Реестр — Сертификаты. Я был уверен, что УЦ 1 ИС ГУЦ это корневой центр сертификации самого первого уровня и не мог понять, кто еще должен подтверждать его доверие. При этом в прошлом сертификате корневым стоял вообще АО «ЕЭТП», и больше никого. И все нормально работало.
Некоторое время покопался в интернете на эту тему. Информации много, но в основном это всякие ошибки установки и т.д. Предлагают переставить сертификаты, переустановить крипто про и все в этом духе. Но у меня никаких ошибок не было. В итоге попал на страницу http://pravo.gov.ru/uc/resourses_uc/, установил оттуда Корневой сертификат ПАК «Головной удостоверяющий центр» и все встало на свои места. Оказывается, он является первым в цепочке сертификатов, которые я использовал. Чтобы все работало как надо, у вас должны быть следующие сертификаты в списке доверенных.
И вот так выглядеть полный путь сертификации для пользовательского сертификата.
У меня изначально самого первого Головной удостоверяющий центр не было, и я не знал, что он должен быть. Когда его установил, все стало нормально. Возможно люди что-то с установочного диска не так установили, или по ходу дела напортачили. Я разбирался удаленно и не видел, какой софт шел в комплекте с ключом. По факту проблема популярная, в интернете много отзывов и советов. Надеюсь, кому-то эта информация поможет сэкономить время.
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.
Проверьте себя на вступительном тесте и смотрите подробнее программу по ссылке.
Помогла статья? Подписывайся на telegram канал автора
Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.
GlobalSign Extended Validation CA — SHA256 — G3 Certificate — DDB3E76DA82EE8C54E6ECF74E6753C9415CEE81D
Subject: GlobalSign Extended Validation CA — SHA256 — G3
Issuer: GlobalSign
Expiration: 2026-09-21 00:00:00 UTC
Key Identifier: DD:B3:E7:6D:A8:2E:E8:C5:4E:6E:CF:74:E6:75:3C:94:15:CE:E8:1D
Download and Install
Certificate Detailed Information:
Name:
/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Extended Validation CA — SHA256 —
G3
Subject:
Common Name (CN): GlobalSign Extended Validation CA — SHA256 — G3
Organizational Unit Name (OU):
Organization Name (O): GlobalSign nv-sa
Locality Name (L):
State or Province Name (ST):
Country Name (C): BE
Email Address:
Issuer:
Common Name (CN): GlobalSign
Organizational Unit Name (OU): GlobalSign Root CA — R3
Organization Name (O): GlobalSign
Locality Name (L):
State or Province Name (ST):
Country Name (C):
Email Address:
Valid From: Wed, 21 Sep 2016 00:00:00 +0000
Valid To: Mon, 21 Sep 2026 00:00:00 +0000
Serial Number: 1473327796444751899236096917215611
Hash: 36d531a1
Version: 2
Signature Type: sha256WithRSAEncryption
Purposes:
SSL client
SSL server
Netscape SSL server
S/MIME signing
S/MIME encryption
CRL signing
Any Purpose
OCSP helper
Time Stamp signing
Extensions:
keyUsage:
Certificate Sign, CRL Sign
basicConstraints:
CA:TRUE, pathlen:0
subjectKeyIdentifier:
DD:B3:E7:6D:A8:2E:E8:C5:4E:6E:CF:74:E6:75:3C:94:15:CE:E8:1D
authorityKeyIdentifier:
keyid:8F:F0:4B:7F:A8:2E:45:24:AE:4D:50:FA:63:9A:8B:DE:E2:DD:1B:BC
authorityInfoAccess:
OCSP — URI:http://ocsp2.globalsign.com/rootr3
crlDistributionPoints:
Full Name:
URI:http://crl.globalsign.com/root-r3.crl
certificatePolicies:
Policy: X509v3 Any Policy
CPS: https://www.globalsign.com/repository/
Certificate in PEM Format:
——BEGIN CERTIFICATE——
MIIEYTCCA0mgAwIBAgIOSKQC3SeSDaIINJ3RmXswDQYJKoZIhvcNAQELBQAwTDEg
MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2Jh
bFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMTYwOTIxMDAwMDAwWhcNMjYw
OTIxMDAwMDAwWjBiMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBu
di1zYTE4MDYGA1UEAxMvR2xvYmFsU2lnbiBFeHRlbmRlZCBWYWxpZGF0aW9uIENB
IC0gU0hBMjU2IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr
awNnVNXcEfvFohPBjBkn3BB04mGDPfqO24+lD+SpvkY/Ar5EpAkcJjOfR0iBFYhW
N80HzpXYy2tIA7mbXpKu2JpmYdU1xcoQpQK0ujE/we+vEDyjyjmtf76LLqbOfuq3
xZbSqUqAY+MOvA67nnpdawvkHgJBFVPnxui45XH4BwTwbtDucx+Mo7EK4mS0Ti+P
1NzARxFNCUFM8Wxc32wxXKff6WU4TbqUx/UJm485ttkFqu0Ox4wTUUbn0uuzK7yV
3Y986EtGzhKBraMH36MekSYlE473GqHetRi9qbNG5pM++Sa+WjR9E1e0Yws16CGq
smVKwAqg4uc43eBTFUhVAgMBAAGjggEpMIIBJTAOBgNVHQ8BAf8EBAMCAQYwEgYD
VR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU3bPnbagu6MVObs905nU8lBXO6B0w
HwYDVR0jBBgwFoAUj/BLf6guRSSuTVD6Y5qL3uLdG7wwPgYIKwYBBQUHAQEEMjAw
MC4GCCsGAQUFBzABhiJodHRwOi8vb2NzcDIuZ2xvYmFsc2lnbi5jb20vcm9vdHIz
MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vcm9v
dC1yMy5jcmwwRwYDVR0gBEAwPjA8BgRVHSAAMDQwMgYIKwYBBQUHAgEWJmh0dHBz
Oi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMA0GCSqGSIb3DQEBCwUA
A4IBAQBVaJzl0J/i0zUV38iMXIQ+Q/yht+JZZ5DW1otGL5OYV0LZ6ZE6xh+WuvWJ
J4hrDbhfo6khUEaFtRUnurqzutvVyWgW8msnoP0gtMZO11cwPUMUuUV8iGyIOuIB
0flo6G+XbV74SZuR5v5RAgqgGXucYUPZWvv9AfzMMQhRQkr/MO/WR2XSdiBrXHoD
L2xk4DmjA4K6iPI+1+qMhyrkUM/2ZEdA8ldqwl8nQDkKS7vq6sUZ5LPVdfpxJZZu
5JBj4y7FNFTVW1OMlCUvwt5H8aFgBMLFik9xqK6JFHpYxYmf4t2sLLxN0LlCthJE
abvp10ZlOtfu8hL5gCXcxnwGxzSb
——END CERTIFICATE——
Public Key Detailed Information:
Key Details:
Type: RSA
Size (bits): 2048
Modulus (n):
ab6b036754d5dc11fbc5a213c18c1927dc1074e261833dfa8edb8fa50fe4a9be
463f02be44a4091c26339f47488115885637cd07ce95d8cb6b4803b99b5e92ae
d89a6661d535c5ca10a502b4ba313fc1efaf103ca3ca39ad7fbe8b2ea6ce7eea
b7c596d2a94a8063e30ebc0ebb9e7a5d6b0be41e02411553e7c6e8b8e571f807
04f06ed0ee731f8ca3b10ae264b44e2f8fd4dcc047114d09414cf16c5cdf6c31
5ca7dfe965384dba94c7f5099b8f39b6d905aaed0ec78c135146e7d2ebb32bbc
95dd8f7ce84b46ce1281ada307dfa31e912625138ef71aa1deb518bda9b346e6
933ef926be5a347d1357b4630b35e821aab2654ac00aa0e2e738dde053154855
Public Exponent (e): 65537 (0x010001)
Public Key in PEM Format:
——BEGIN PUBLIC KEY——
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAq2sDZ1TV3BH7xaITwYwZ
J9wQdOJhgz36jtuPpQ/kqb5GPwK+RKQJHCYzn0dIgRWIVjfNB86V2MtrSAO5m16S
rtiaZmHVNcXKEKUCtLoxP8HvrxA8o8o5rX++iy6mzn7qt8WW0qlKgGPjDrwOu556
XWsL5B4CQRVT58bouOVx+AcE8G7Q7nMfjKOxCuJktE4vj9TcwEcRTQlBTPFsXN9s
MVyn3+llOE26lMf1CZuPObbZBartDseME1FG59Lrsyu8ld2PfOhLRs4Sga2jB9+j
HpEmJROO9xqh3rUYvamzRuaTPvkmvlo0fRNXtGMLNeghqrJlSsAKoOLnON3gUxVI
VQIDAQAB
——END PUBLIC KEY——
Identical or Similar Keys: We found that the public key in this certificate matches key(s) recorded previously.
GlobalSign Organization Validation CA — SHA256 — G2 Certificate — 96DE61F1BD1C1629531CC0CC7D3B830040E61A7C
Subject: GlobalSign Organization Validation CA — SHA256 — G2
Issuer: GlobalSign Root CA
Expiration: 2024-02-20 10:00:00 UTC
Key Identifier: 96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
Name:
/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Organization Validation CA — SHA2
56 — G2
Subject:
Common Name (CN): GlobalSign Organization Validation CA — SHA256 — G2
Organizational Unit Name (OU):
Organization Name (O): GlobalSign nv-sa
Locality Name (L):
State or Province Name (ST):
Country Name (C): BE
Email Address:
Issuer:
Common Name (CN): GlobalSign Root CA
Organizational Unit Name (OU): Root CA
Organization Name (O): GlobalSign nv-sa
Locality Name (L):
State or Province Name (ST):
Country Name (C): BE
Email Address:
Valid From: Thu, 20 Feb 2014 10:00:00 +0000
Valid To: Tue, 20 Feb 2024 10:00:00 +0000
Serial Number: 4835703278459909592597063
Hash: b85455c4
Version: 2
Signature Type: sha256WithRSAEncryption
Purposes:
SSL client
SSL server
Netscape SSL server
S/MIME signing
S/MIME encryption
CRL signing
Any Purpose
OCSP helper
Time Stamp signing
Extensions:
keyUsage:
Certificate Sign, CRL Sign
basicConstraints:
CA:TRUE, pathlen:0
subjectKeyIdentifier:
96:DE:61:F1:BD:1C:16:29:53:1C:C0:CC:7D:3B:83:00:40:E6:1A:7C
certificatePolicies:
Policy: X509v3 Any Policy
CPS: https://www.globalsign.com/repository/
crlDistributionPoints:
Full Name:
URI:http://crl.globalsign.net/root.crl
authorityInfoAccess:
OCSP — URI:http://ocsp.globalsign.com/rootr1
authorityKeyIdentifier:
keyid:60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B
——BEGIN CERTIFICATE——
MIIEaTCCA1GgAwIBAgILBAAAAAABRE7wQkcwDQYJKoZIhvcNAQELBQAwVzELMAkG
A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xNDAyMjAxMDAw
MDBaFw0yNDAyMjAxMDAwMDBaMGYxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i
YWxTaWduIG52LXNhMTwwOgYDVQQDEzNHbG9iYWxTaWduIE9yZ2FuaXphdGlvbiBW
YWxpZGF0aW9uIENBIC0gU0hBMjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQDHDmw/I5N/zHClnSDDDlM/fsBOwphJykfVI+8DNIV0yKMCLkZc
C33JiJ1Pi/D4nGyMVTXbv/Kz6vvjVudKRtkTIso21ZvBqOOWQ5PyDLzm+ebomchj
SHh/VzZpGhkdWtHUfcKc1H/hgBKueuqI6lfYygoKOhJJomIZeg0k9zfrtHOSewUj
mxK1zusp36QUArkBpdSmnENkiN74fv7j9R7l/tyjqORmMdlMJekYuYlZCa7pnRxt
Nw9KHjUgKOKv1CGLAcRFrW4rY6uSa2EKTSDtc7p8zv4WtdufgPDWi2zZCHlKT3hl
2pK8vjX5s8T5J4BO/5ZS5gIg4Qdz6V0rvbLxAgMBAAGjggElMIIBITAOBgNVHQ8B
Af8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUlt5h8b0cFilT
HMDMfTuDAEDmGnwwRwYDVR0gBEAwPjA8BgRVHSAAMDQwMgYIKwYBBQUHAgEWJmh0
dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDMGA1UdHwQsMCow
KKAmoCSGImh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcm9vdC5jcmwwPQYIKwYB
BQUHAQEEMTAvMC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9iYWxzaWduLmNv
bS9yb290cjEwHwYDVR0jBBgwFoAUYHtmGkUNl8qJUC99BM00qP/8/UswDQYJKoZI
hvcNAQELBQADggEBAEYq7l69rgFgNzERhnF0tkZJyBAW/i9iIxerH4f4gu3K3w4s
32R1juUYcqeMOovJrKV3UPfvnqTgoI8UV6MqX+x+bRDmuo2wCId2Dkyy2VG7EQLy
XN0cvfNVlg/UBsD84iOKJHDTu/B5GqdhcIOKrwbFINihY9Bsrk8y1658GEV1BSl3
30JAZGSGvip2CTFvHST0mdCF/vIhCPnG9vHQWe3WVjwIKANnuvD58ZAWR65n5ryA
SOlCdjSXVWkkDoPWoC209fN5ikkodBpBocLTJIg1MGCUF7ThBCIxPTsvFwayuJ2G
K1pp74P1S8SqtCr4fKGxhZSM9AyHDPSsQPhZSZg=
——END CERTIFICATE——
Key Details:
Type: RSA
Size (bits): 2048
Modulus (n):
c70e6c3f23937fcc70a59d20c30e533f7ec04ec29849ca47d523ef03348574c8
a3022e465c0b7dc9889d4f8bf0f89c6c8c5535dbbff2b3eafbe356e74a46d913
22ca36d59bc1a8e3964393f20cbce6f9e6e899c86348787f5736691a191d5ad1
d47dc29cd47fe18012ae7aea88ea57d8ca0a0a3a1249a262197a0d24f737ebb4
73927b05239b12b5ceeb29dfa41402b901a5d4a69c436488def87efee3f51ee5
fedca3a8e46631d94c25e918b9895909aee99d1c6d370f4a1e352028e2afd421
8b01c445ad6e2b63ab926b610a4d20ed73ba7ccefe16b5db9f80f0d68b6cd908
794a4f7865da92bcbe35f9b3c4f927804eff9652e60220e10773e95d2bbdb2f1
Public Exponent (e): 65537 (0x010001)
——BEGIN PUBLIC KEY——
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxw5sPyOTf8xwpZ0gww5T
P37ATsKYScpH1SPvAzSFdMijAi5GXAt9yYidT4vw+JxsjFU127/ys+r741bnSkbZ
EyLKNtWbwajjlkOT8gy85vnm6JnIY0h4f1c2aRoZHVrR1H3CnNR/4YASrnrqiOpX
2MoKCjoSSaJiGXoNJPc367RzknsFI5sStc7rKd+kFAK5AaXUppxDZIje+H7+4/Ue
5f7co6jkZjHZTCXpGLmJWQmu6Z0cbTcPSh41ICjir9QhiwHERa1uK2OrkmthCk0g
7XO6fM7+FrXbn4Dw1ots2Qh5Sk94ZdqSvL41+bPE+SeATv+WUuYCIOEHc+ldK72y
8QIDAQAB
——END PUBLIC KEY——
Теория
Обычно SSL сертификат необходим, когда клиент-браузер обращается к серверу. Трафик между ними шифруется, чтобы никто третий не смог его прочесть. Происходит это примерно так, как показано на рисунке 1 из интернетов:
На рисунке хорошо показано, что алгоритм шифрует трафик с помощью public key который был передан в открытом виде внутри сертификата клиенту. Но вот назад этот трафик расшифровывается только с помощью privat key. Это позволяет любому передать серверу session key, который будет известен только клиенту и серверу. В дальнейшем клиент и сервер уже будут общаться шифруя трафик с помощью session key.
Отлично, но вот незадача. Сам факт этого обмена может быть скомпрометирован. Ведь если кто-то перехватит этот обмен, он сможет подменить сертификат, установив два безопасных соединения между клиентом и сервером.
Для решения этой проблемы нам необходимо точно знать, что сертификат, который мы получили от сервера, пренадлежит этому серверу.
Как вариант, мы можем заранее получить public key из доверенного источника. Например напрямую, приехав к владельцу сервера и скопировав public key на флешку. Если у владельца сервера никто не украдет privat key, мы почти точно будем знать, что на той стороне именно владелец privat key (потому что он сможет это подтвердить, см. картинку).
В свою очередь, CA проверяет подлинность владельца сертификата за вас, добавляя с подписью CN (Common Name). Вообще это поле может содержать просто имя. Но если это классический SSL сертификат, там будет содержаться доменное имя (доменные имена), в том числе wildcard, или IP адрес.
Обратите внимение, что на схеме сервер также проверяет сертификат клиента с помощью CA). На самом деле в типовых случаях достаточно проверки сервера, т.к. установленное в таком случае соединение в рамках сессии может быть защищено session key, который на рисунке 2 представлен как Symmetric Key, а в остальном поможет авторизация. Но верефицировать клиента тоже нормально. И тогда процедура верификации в обе стороны ничем не отличается. Можно прочесть эту статью чтобы прояснить детали.
Практика
Я буду использовать curl, чтобы немного прояснить, как с ним работать.
Простой запрос
По умолчанию curl будет использовать известные ему CA и запрос к серверу может выглядить очень просто.
curl -X GET -i https://ya.ru
Самоподписанный сертификат сервера
Допустим,
1) владлец сам подписал сертификат
3) CURL-у не известен CA которым подписан сертификат
4) база CA устарела
то, при запросе на такой сервер предыдущей командой вы получите такое сообщение
в данной ситуации можно установить сертификат
Например предварительно скачав его:
А после, его можно использовать в curl так, указав путь до этого сертификата в параметре —cacert:
curl —cacert ./CA/mycertfile.pem -X GET -i https://127.0.0.1/
или указав путь к папке с такими сертификатами
curl —capath CA/ -X GET -i https://127.0.0.1/
Иногда можно и вовсе проигнорировать сертификат сервера, например если он истёк, и вы получаете ошибку
curl: (60) Peer’s Certificate has expired.
Используйте ключ -k (со всей ответственностью)
curl -k -X GET -i https://127.0.0.1/
Установка CA сертификата в CentOS
Вы также можете установить CA сертификаты скачав их и разместив в директории /etc/pki/ca-trust/source/anchors.
Двухсторонняя верификация
Как упомянуто выше, сервер тоже может проверить сертификат клиента. Например, вы написали два сервиса, которые должны общаться друг с другом, но между ними нет аутентификации на уровне приложения. Это может быть реализовано на уровне SSL (https).
Поэтому curl как клиенту теперь необходимо передать собственный подписанный сертификат (который содержит также и публичный ключ), владеть приватным ключом, чтобы доаказать свою подлинность, ну и CA сертификат, чтобы доверять второй стороне.
Запросы curl теперь могут выглядеть так:
curl —capath ./CA —cert ./cert.pem —key ./key.pem -X GET -i 127.0.0.1:443
добавились параметры —key — приватный ключ клиента и —cert — сертификат клиента.
Стоит отметить, что curl по умолчанию будет работать с сертификатами так, будто они в формате PEM. Для изменения этого существуют ключи:
—cert-type TYPE Certificate file type (DER/PEM/ENG) (SSL)
—key-type TYPE Private key file type (DER/PEM/ENG) (SSL)
Пример на PHP
Давайте закрепим, сделав типовой запрос используя библиотеку CURL в PHP ( в коде всё будет прокомментировано ):
Проверка ключей на соответствие
Выведем значения модулей Приватного Ключа, SSL Сертификата и CSR, а затем преобразуем их в md5 хэши для удобного сравнения.
md5 хэш модуля SSL сертификата:
md5 хэш модуля Приватного Ключа:
md5 хэш модуля CSR:
Если полученные md5 хэши одинаковы — значит файлы (Сертификат, Приватный Ключ и CSR) соответствую друг другу.
Форматы SSL сертификатов
Примечание: имейте ввиду, что расширение файла может быть некорректным, поэтому 100% доверять ему нет смысла.
PEM – ASCII файл с Base64, который обособлен тегами —— BEGIN CERTIFICATE —— и —— END CERTIFICATE ——. Может иметь расшрения .pem, .crt, .cer, и .key, что порою может ввести в заблуждение, но сам по себе PEM человекоузнаваем. Может включать в себя промежуточные сертифкаты CA.
DER — бинарный файл, может иметь расширения .cet или .der. Легко открывается в Windows.
PKCS#7 и P7B — подобно PEM сертификатам это Base64 ASCII обособленый тегами —— BEGIN PKCS7 —— и —— END PKCS7 ——. Может включать в себя промежуточные сертифкаты CA. Обычно имеет расширения .p7b или .p7c.
PFX PKCS#12 — Файл в который укомплектованы сертифкат сервера, промежуточные сертификаты CA и приватный ключ. Таким файлом лучше не разбрасываться. Обычно он имеет расширениям .pfx или .p12.
Как убедиться, какой перед вами сертифкат (узнать формат сертификата)
Следует отметить, что это не такая явная вещь. Даже если вы на глаз определили формат сертификата, он может быть некорректным.
openssl x509 -in certificate.pem -text -noout
openssl x509 -inform der -in certificate.cer -text -noout
openssl pkcs7 -in certificate.p7b
PFX PKCS#12
Вообще такие сертификаты часто зашифрованы и нужно знать пароль, чтобы с ним нормально работать. Команда ниже выдаст ошибку если вы ей укажите не PKCS#12 сертификат.
openssl pkcs12 -info -in certificate.p12
Конвертация сертификатов
Конвертация сертификата (распространенные примеры).
Конвертировать PEM в DER
openssl x509 -outform der -in certificate.pem -out certificate.der
Конвертировать PEM в P7B
openssl crl2pkcs7 -nocrl -certfile certificate.cer -out certificate.p7b -certfile CACert.cer
Конвертировать PEM в PFX
openssl pkcs12 -export -out certificate.pfx -inkey privateKey.key -in certificate.crt -certfile CACert.crt
Конвертировать DER в PEM
openssl x509 -inform der -in certificate.cer -out certificate.pem
Конвертировать P7B в PEM
openssl pkcs7 -print_certs -in certificate.p7b -out certificate.cer
Конвертировать P7B в PFX
openssl pkcs7 -print_certs -in certificate.p7b -out certificate.ceropenssl pkcs12 -export -in certificate.cer -inkey privateKey.key -out certificate.pfx -certfile CACert.cer
Конвертировать PFX в PEM
openssl pkcs12 -in certificate.pfx -out certificate.cer -nodes
Узнать длину
1) Из секретного Ключа
Private-Key: (2048 bit)
2) Извлечь Длину Ключа из SSL Сертификата
RSA Public-Key: (2048 bit)
Узнать Длину Ключа Шифрования HTTPS Сайта
Ссылки:
https://www.php.net/manual/ru/function.curl-setopt.php
https://curl.haxx.se/libcurl/c/CURLOPT_CAPATH.html
https://curl.haxx.se/libcurl/c/CURLOPT_CAINFO.html
https://curl.haxx.se/libcurl/c/CURLOPT_SSLKEY.html
https://curl.haxx.se/libcurl/c/CURLOPT_SSLKEY.html
https://stuff-things.net/2015/09/28/configuring-apache-for-ssl-client-certificate-authentication/
https://www.shellhacks.com/ru/openssl-check-private-key-matches-ssl-certificate-csr/
https://www.shellhacks.com/ru/openssl-find-ssl-key-length-linux-command-line/
https://www.emaro-ssl.ru/blog/convert-ssl-certificate-formats/
https://www.sslshopper.com/article-most-common-openssl-commands.html