Ssl: различия между версиями

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
 
(не показано 11 промежуточных версий этого же участника)
Строка 1: Строка 1:
  +
[[Категория:Linux]]
  +
[[Категория:OpenSSL]]
  +
[[Категория:SSL]]
  +
  +
 
=OpenSSL=
  
=OpenSSL=
−
Заметки на полях что б каждый раз не читать мануал
 +
Заметки на полях что б каждый раз не читать мануал (ssl, openssl)
   
 
==Получить сертефикат==
  
==Получить сертефикат==
Строка 8: Строка 13:
 
<PRE>
  
<PRE>
 
echo -n | openssl s_client -showcerts -connect api.diffbot.com:443 -servername api.diffbot.com
  
echo -n | openssl s_client -showcerts -connect api.diffbot.com:443 -servername api.diffbot.com
−
<PRE>
 +
</PRE>
 
<PRE>
  
<PRE>
 
CONNECTED(00000003)
  
CONNECTED(00000003)
Строка 164: Строка 169:
 
</PRE>
  
</PRE>
   
  +
==Валидация==
  +
<PRE>
  +
openssl verify -verbose -CAfile rootCA.pem intermediateCA.cert.pem
  +
intermediateCA.cert.pem: OK
  +
</PRE>
  +
Валидация с подробностями когда в gd_bundle-g2-g1.crt содержится цепочка сертефикатов
  +
<PRE>
  +
openssl verify -verbose -no-CAfile -no-CApath -show_chain -CAfile gd_bundle-g2-g1.crt c97444e03355f98c.crt
  +
  +
c97444e03355f98c.crt: OK
  +
Chain:
  +
depth=0: CN = container-cloud-auth.int.mirantis.com (untrusted)
  +
depth=1: C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
  +
depth=2: C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2
  +
depth=3: C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
  +
</PRE>
  +
  +
  +
<PRE>
  +
openssl verify -verbose -no-CAfile -no-CApath -no-CAstore -show_chain -partial_chain -CAfile root intermidiate
  +
intermidiate: OK
  +
Chain:
  +
depth=0: C = NL, O = Booking.com, CN = Booking.com Services Authority (untrusted)
  +
depth=1: C = NL, O = Booking.com, CN = Booking.com Authority X1
  +
</PRE>
  +
  +
==Проверка ключа==
  +
<PRE>
  +
openssl x509 -noout -modulus -in cert.crt | openssl md5
  +
openssl rsa -noout -modulus -in privkey.txt | openssl md5
  +
</PRE>
  +
Должно совпадать
  +
  +
==Удаление пароля из ключа==
  +
Для RSA
  +
<PRE>
  +
openssl rsa -in [original.key] -out [new.key]
  +
</PRE>
  +
Для другого типа - EC
  +
  +
<PRE>
  +
openssl ec -in /root/easy-rsa/pki/private/ca.key -out /root/easy-rsa/pki/private/ca.key.nopasswd
  +
</PRE>
  +
Ключ выглядит примерно вот так:
  +
<PRE>
  +
-----BEGIN EC PRIVATE KEY-----
  +
Proc-Type: 4,ENCRYPTED
  +
DEK-Info: AES-256-CBC,82C9FA9B7FB1DCBBA5B5C8CE1A41BD76
  +
  +
6hJIO09pwVe2JQLckx4rjtzTZwijik86c5sJamLTT1X/VptM4qclJ3JaQLyDA6Ln
  +
yAmSVanWu9JXuO+4cmNB/Q1BIs4kWZ8Y20zzvcNEAdKR35z5Pf4qF2N/V5g/IJyl
  +
JmLimB4lJERWsiNZ6WjVFJGQvWU0QlMDI7opypksHwB1Vid+hnnqFkOsLoiBW3mR
  +
kQlfjcY1+mDxHC6/q9AQ8OpFiboZ/GPidrpXFn5C608=
  +
-----END EC PRIVATE KEY-----
  +
</PRE>
  +
  +
=1=
  +
<PRE>
  +
Verifying the certificate subject and issuer
  +
  +
This section describes how to get the subject and issuer of the certificates and verify that you have a valid certificate chain.
  +
  +
Run the following OpenSSL command to get the Subject and Issuer for each certificate in the chain from entity to root and verify that they form a proper certificate chain:
  +
  +
openssl x509 -text -in certificate | grep -E '(Subject|Issuer):'
  +
  +
Where certificate is the name of the certificate.
  +
Verify that the certificates in the chain adhere to the following guidelines:
  +
Subject of each certificate matches the Issuer of the preceding certificate in the chain (except for the Entity certificate).
  +
Subject and Issuer are the same for the root certificate.
  +
If the certificates in the chain adhere to these guidelines, then the certificate chain is considered to be complete and valid.
  +
  +
Sample certificate chain validation
  +
  +
The following example is the output of the OpenSSL commands for a sample certificate chain containing three certificates:
  +
  +
Entity certificate
  +
  +
  +
openssl x509 -text -in entity.pem | grep -E '(Subject|Issuer):'
  +
  +
Issuer: C = US, O = Google Trust Services, CN = GTS CA 1O1
  +
Subject: C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.enterprise.apigee.com
  +
  +
Intermediate certificate
  +
  +
  +
openssl x509 -text -in intermediate.pem | grep -E '(Subject|Issuer):'
  +
  +
Issuer: OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
  +
Subject: C = US, O = Google Trust Services, CN = GTS CA 1O1
  +
  +
Root certificate
  +
  +
  +
openssl x509 -text -in root.pem | grep -E '(Subject|Issuer):'
  +
  +
Issuer: OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
  +
Subject: OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
  +
  +
In the example shown above, notice the following:
  +
  +
The Subject of the intermediate certificate matches the Issuer of the entity certificate.
  +
The Subject of the root certificate matches the Issuer of the intermediate certificate.
  +
The Subject and Issuer are the same in the root certificate.
  +
From the example above, you can confirm that the sample certificate chain is valid.
  +
Verifying the certificate subject and issuer hash
  +
  +
This section explains how to get the hash of the subject and issuer of the certificates and verify that you have a valid certificate chain.
  +
  +
It is always a good practice to verify the hash sequence of certificates as it can help in identifying issues such as the Common Name (CN) of the certificate having unwanted space or special characters.
  +
  +
Run the following OpenSSL command to get the hash sequence for each certificate in the chain from entity to root and verify that they form a proper certificate chain.
  +
  +
openssl x509 -hash -issuer_hash -noout -in certificate
  +
  +
Where certificate is the name of the certificate.
  +
  +
Verify that the certificates in the chain adhere to the following guidelines:
  +
Subject of each certificate matches the Issuer of the preceding certificate in the chain (except for the Entity certificate).
  +
Subject and Issuer are the same for the root certificate.
  +
If the certificates in the chain adhere to these guidelines, then the certificate chain is considered to be complete and valid.
  +
  +
Sample certificate chain validation through hash sequence
  +
  +
The following example is the output of the OpenSSL commands for a sample certificate chain containing three certificates:
  +
  +
  +
openssl x509 -in entity.pem -hash -issuer_hash -noout
  +
c54c66ba #this is subject hash
  +
99bdd351 #this is issuer hash
  +
  +
  +
openssl x509 -in intermediate.pem -hash -issuer_hash -noout
  +
99bdd351
  +
4a6481c9
  +
  +
  +
openssl x509 -in root.pem -hash -issuer_hash -noout
  +
4a6481c9
  +
4a6481c9
  +
  +
In the example shown above, notice the following:
  +
  +
The subject hash of the intermediate certificate matches the issuer hash of the entity certificate.
  +
The subject hash of the root certificate matches the issuer hash of the issuer certificate.
  +
The subject and issuer hash are the same in the root certificate.
  +
From the example above, you can confirm that the sample certificate chain is valid.
  +
  +
Verifying the certificate expiry
  +
  +
This section explains how to verify whether or not all the certificates in the chain are expired using of the following methods:
  +
  +
Get the start and end date of the certificate.
  +
Get the expiry status.
  +
START AND END DATE
  +
EXPIRY STATUS
  +
Run the following OpenSSL command to get the start and end date for each certificate in the chain from entity to root and verify that all the certificates in the chain are in force (start date is before today) and are not expired.
  +
  +
Sample certificate expiry validation through start and end dates
  +
  +
  +
openssl x509 -startdate -enddate -noout -in entity.pem
  +
notBefore=Feb 6 21:57:21 2020 GMT
  +
notAfter=Feb 4 21:57:21 2021 GMT
  +
  +
openssl x509 -startdate -enddate -noout -in intermediate.pem
  +
notBefore=Jun 15 00:00:42 2017 GMT
  +
notAfter=Dec 15 00:00:42 2021 GMT
  +
  +
openssl x509 -startdate -enddate -noout -in root.pem
  +
notBefore=Apr 13 10:00:00 2011 GMT
  +
notAfter=Apr 13 10:00:00 2022 GMT
  +
</PRE>
   
 
=Ссылки=
  
=Ссылки=

Текущая версия на 13:43, 18 октября 2024


OpenSSL

Заметки на полях что б каждый раз не читать мануал (ssl, openssl)

Получить сертефикат

openssl s_client -connect example.com:443 

echo -n | openssl s_client -showcerts -connect api.diffbot.com:443 -servername api.diffbot.com

CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/CN=api.diffbot.com
   i:/C=US/O=Let's Encrypt/CN=R3
-----BEGIN CERTIFICATE-----
MIIFJDCCBAygAwIBAgISBFLfLeNzhyHJCOLtTTFsrh7gMA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMTA4MTIwNzI4NDRaFw0yMTExMTAwNzI4NDJaMBoxGDAWBgNVBAMT
D2FwaS5kaWZmYm90LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AKyP5dzpbQO2yXzpc0eC3t8iRbFdGVn0TG5lTQVbBDchcZ0MLrvBtdv7L+4xqc5A
rg8nn+83De9wF/JVQL0qIMJnfdx3BZmuWc3HMRPBCIBTt4vHL6hxd1wHJecR0b+B
tnAJ+Te/ADL3kyLbKUdXNWUkWaO+k+6Cunz7DRx+zMx2BzBfkcd5ypf0NcRPy6VC
N9N6oIwGHTQGxf/dTnq1hwN1JuXzGsCCIe0ownbHF/sDzWulA+3hCzNQmI2+ukL7
BCENjTt8NW5LD7e7cDrtWzbd5LrzAY5iFRSDvvchuiwHD+HR99XRgpuS/tNG6iA2
zVpcSRlbRY2DqbrlpdlnKI0CAwEAAaOCAkowggJGMA4GA1UdDwEB/wQEAwIFoDAd
BgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNV
HQ4EFgQUPWDfcOnHKf8rBeP12YqMbz2RI1UwHwYDVR0jBBgwFoAUFC6zF7dYVsuu
UAlA5h+vnYsUwsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVodHRwOi8v
cjMuby5sZW5jci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxlbmNyLm9y
Zy8wGgYDVR0RBBMwEYIPYXBpLmRpZmZib3QuY29tMEwGA1UdIARFMEMwCAYGZ4EM
AQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0dHA6Ly9jcHMubGV0
c2VuY3J5cHQub3JnMIIBBAYKKwYBBAHWeQIEAgSB9QSB8gDwAHYARJRlLrDuzq/E
QAfYqP4owNrmgr7YyzG1P9MzlrW2gagAAAF7OXpX4QAABAMARzBFAiAVsfnYo6fv
8qaUwrhZizSiZmM7ZlBN0oIeiERCqyXeHwIhAJiH2DUFuYahKMb/OlFlr2oKrfma
Pn5kzu7VR87GbpnXAHYAfT7y+I//iFVoJMLAyp5SiXkrxQ54CX8uapdomX4i8NcA
AAF7OXpX/AAABAMARzBFAiEAm5P2UOS0sRX4LqlzXTe7saP82TfKtjFXrvt6Jfzw
RAcCIGhLBkhXnL/nkQoc2cosVHj0YinkdT4lPyfOJthggSaUMA0GCSqGSIb3DQEB
CwUAA4IBAQAr1MkfbXbGXLd0O8+w+JVGotlaJkwLUpBfL2jZ9ydPdBgTYm7sEnsa
w+OttVwgQwIDIONngL6fdgRDEm/XzoPEOQ6PxKuJCUHEAtPFt2ADL1upC7gbZbut
KlfQ15CkCF6EZJaVo612IsRVskVbkA8eTcNp/5LojhSW9eOhWV9lLeLnLo8ZA9n2
S5Y3Lhr01rXnYRcSELjEqtVHSGje6vICMt7F287SyawYSDtPsR9zKMwmhaQn7YP6
sikfWDCp+l33+csanvnNq6Jl/BqGVxR/k3zklm6XpsRP01/ix1nT5jf/h1FWlNF8
wbiXI+outWMvqpD0pIbDsRHu8Xs2BS5n
-----END CERTIFICATE-----
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
-----BEGIN CERTIFICATE-----
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-----END CERTIFICATE-----
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIQQAF3ITfU6UK47naqPGQKtzANBgkqhkiG9w0BAQsFADA/
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT
DkRTVCBSb290IENBIFgzMB4XDTIxMDEyMDE5MTQwM1oXDTI0MDkzMDE4MTQwM1ow
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwggIiMA0GCSqGSIb3DQEB
AQUAA4ICDwAwggIKAoICAQCt6CRz9BQ385ueK1coHIe+3LffOJCMbjzmV6B493XC
ov71am72AE8o295ohmxEk7axY/0UEmu/H9LqMZshftEzPLpI9d1537O4/xLxIZpL
wYqGcWlKZmZsj348cL+tKSIG8+TA5oCu4kuPt5l+lAOf00eXfJlII1PoOK5PCm+D
LtFJV4yAdLbaL9A4jXsDcCEbdfIwPPqPrt3aY6vrFk/CjhFLfs8L6P+1dy70sntK
4EwSJQxwjQMpoOFTJOwT2e4ZvxCzSow/iaNhUd6shweU9GNx7C7ib1uYgeGJXDR5
bHbvO5BieebbpJovJsXQEOEO3tkQjhb7t/eo98flAgeYjzYIlefiN5YNNnWe+w5y
sR2bvAP5SQXYgd0FtCrWQemsAXaVCg/Y39W9Eh81LygXbNKYwagJZHduRze6zqxZ
Xmidf3LWicUGQSk+WT7dJvUkyRGnWqNMQB9GoZm1pzpRboY7nn1ypxIFeFntPlF4
FQsDj43QLwWyPntKHEtzBRL8xurgUBN8Q5N0s8p0544fAQjQMNRbcTa0B7rBMDBc
SLeCO5imfWCKoqMpgsy6vYMEG6KDA0Gh1gXxG8K28Kh8hjtGqEgqiNx2mna/H2ql
PRmP6zjzZN7IKw0KKP/32+IVQtQi0Cdd4Xn+GOdwiK1O5tmLOsbdJ1Fu/7xk9TND
TwIDAQABo4IBRjCCAUIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw
SwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5pZGVudHJ1
c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTEp7Gkeyxx
+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEEAYLfEwEB
ATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2VuY3J5cHQu
b3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0LmNvbS9E
U1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFHm0WeZ7tuXkAXOACIjIGlj26Ztu
MA0GCSqGSIb3DQEBCwUAA4IBAQAKcwBslm7/DlLQrt2M51oGrS+o44+/yQoDFVDC
5WxCu2+b9LRPwkSICHXM6webFGJueN7sJ7o5XPWioW5WlHAQU7G75K/QosMrAdSW
9MUgNTP52GE24HGNtLi1qoJFlcDyqSMo59ahy2cI2qBDLKobkx/J3vWraV0T9VuG
WCLKTVXkcGdtwlfFRjlBz4pYg1htmf5X6DYO8A4jqv2Il9DjXA6USbW1FzXSLr9O
he8Y4IWS6wY7bCkjCWDcRQJMEhg76fsO3txE+FiYruq9RUWhiF1myv4Q6W+CyBFC
Dfvp7OOGAN6dEOM4+qR9sdjoSYKEBpsr6GtPAQw4dy753ec5
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=api.diffbot.com
issuer=/C=US/O=Let's Encrypt/CN=R3
---
No client certificate CA names sent
---
SSL handshake has read 4702 bytes and written 445 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 11834EAF003B0B311A756947F00C5FF07A14AEB57FE9374DBC2D2E51C805E1F0
    Session-ID-ctx:
    Master-Key: 261A38BACE36C1386B29F64D596D097AE428CAC303A377B9D6682ED304C1929336F96616405182D5B0E512D925B459EA
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - d5 bf f6 94 74 53 bb 5c-51 54 4e 62 fe dc af 7b   ....tS.\QTNb...{
    0010 - f2 45 52 46 d6 c1 84 cf-34 e1 b6 3b e1 3d b5 26   .ERF....4..;.=.&
    0020 - f8 4a b6 d6 1e ae bc 89-a8 7f d0 dc 84 83 a9 6b   .J.............k
    0030 - d9 f4 9b ef 9a 82 da f3-bd e8 8b 8f 25 43 eb 96   ............%C..
    0040 - 6b f6 b7 7f 16 ab 4e b0-11 b0 a9 0c f8 1f 13 15   k.....N.........
    0050 - 1d fe 68 3f 0c f8 83 f0-50 45 1c b7 2f f2 ea 31   ..h?....PE../..1
    0060 - 33 4a dc 35 63 46 cd a7-07 78 8f d1 40 f6 b2 ad   3J.5cF...x..@...
    0070 - c6 06 90 b3 76 2d 61 61-ca c4 92 46 a2 78 72 59   ....v-aa...F.xrY
    0080 - 53 dd eb cc f5 cb 91 a8-58 6c 64 58 4e 4d fd 5b   S.......XldXNM.[
    0090 - ef 98 89 0d 30 8a 57 18-1b c0 f6 c2 ea 2f 63 e4   ....0.W....../c.
    00a0 - 6a d2 da 6c 34 c8 b6 a3-f7 79 25 d2 07 d1 08 18   j..l4....y%.....
    00b0 - 0d 50 0f 9f e9 eb f6 16-ee c1 f9 dc 84 83 75 57   .P............uW

    Start Time: 1633343371
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
DONE

Перевести в текст

openssl x509 -in FileName.pem -text

Валидация

openssl verify -verbose -CAfile rootCA.pem intermediateCA.cert.pem
intermediateCA.cert.pem: OK

Валидация с подробностями когда в gd_bundle-g2-g1.crt содержится цепочка сертефикатов 

openssl verify -verbose -no-CAfile -no-CApath -show_chain -CAfile gd_bundle-g2-g1.crt c97444e03355f98c.crt

c97444e03355f98c.crt: OK
Chain:
depth=0: CN = container-cloud-auth.int.mirantis.com (untrusted)
depth=1: C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", OU = http://certs.godaddy.com/repository/, CN = Go Daddy Secure Certificate Authority - G2
depth=2: C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2
depth=3: C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority



openssl verify -verbose -no-CAfile -no-CApath -no-CAstore -show_chain -partial_chain -CAfile root intermidiate
intermidiate: OK
Chain:
depth=0: C = NL, O = Booking.com, CN = Booking.com Services Authority (untrusted)
depth=1: C = NL, O = Booking.com, CN = Booking.com Authority X1

Проверка ключа

openssl x509 -noout -modulus -in cert.crt | openssl md5
openssl rsa -noout -modulus -in privkey.txt | openssl md5

Должно совпадать

Удаление пароля из ключа

Для RSA 

openssl rsa -in [original.key] -out [new.key]

Для другого типа - EC 

openssl ec -in /root/easy-rsa/pki/private/ca.key  -out /root/easy-rsa/pki/private/ca.key.nopasswd

Ключ выглядит примерно вот так: 

-----BEGIN EC PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,82C9FA9B7FB1DCBBA5B5C8CE1A41BD76

6hJIO09pwVe2JQLckx4rjtzTZwijik86c5sJamLTT1X/VptM4qclJ3JaQLyDA6Ln
yAmSVanWu9JXuO+4cmNB/Q1BIs4kWZ8Y20zzvcNEAdKR35z5Pf4qF2N/V5g/IJyl
JmLimB4lJERWsiNZ6WjVFJGQvWU0QlMDI7opypksHwB1Vid+hnnqFkOsLoiBW3mR
kQlfjcY1+mDxHC6/q9AQ8OpFiboZ/GPidrpXFn5C608=
-----END EC PRIVATE KEY-----

1

Verifying the certificate subject and issuer

This section describes how to get the subject and issuer of the certificates and verify that you have a valid certificate chain.

Run the following OpenSSL command to get the Subject and Issuer for each certificate in the chain from entity to root and verify that they form a proper certificate chain:

openssl x509 -text -in certificate | grep -E '(Subject|Issuer):'
    
Where certificate is the name of the certificate.
Verify that the certificates in the chain adhere to the following guidelines:
Subject of each certificate matches the Issuer of the preceding certificate in the chain (except for the Entity certificate).
Subject and Issuer are the same for the root certificate.
If the certificates in the chain adhere to these guidelines, then the certificate chain is considered to be complete and valid.

Sample certificate chain validation

The following example is the output of the OpenSSL commands for a sample certificate chain containing three certificates:

Entity certificate


openssl x509 -text -in entity.pem | grep -E '(Subject|Issuer):'

Issuer: C = US, O = Google Trust Services, CN = GTS CA 1O1
Subject: C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.enterprise.apigee.com
        
Intermediate certificate


openssl x509 -text -in intermediate.pem  | grep -E '(Subject|Issuer):'

Issuer: OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
Subject: C = US, O = Google Trust Services, CN = GTS CA 1O1
        
Root certificate


openssl x509 -text -in root.pem | grep -E '(Subject|Issuer):'

Issuer: OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
Subject: OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
        
In the example shown above, notice the following:

The Subject of the intermediate certificate matches the Issuer of the entity certificate.
The Subject of the root certificate matches the Issuer of the intermediate certificate.
The Subject and Issuer are the same in the root certificate.
From the example above, you can confirm that the sample certificate chain is valid.
Verifying the certificate subject and issuer hash

This section explains how to get the hash of the subject and issuer of the certificates and verify that you have a valid certificate chain.

It is always a good practice to verify the hash sequence of certificates as it can help in identifying issues such as the Common Name (CN) of the certificate having unwanted space or special characters.

Run the following OpenSSL command to get the hash sequence for each certificate in the chain from entity to root and verify that they form a proper certificate chain.

openssl x509 -hash -issuer_hash -noout -in certificate
    
Where certificate is the name of the certificate.

Verify that the certificates in the chain adhere to the following guidelines:
Subject of each certificate matches the Issuer of the preceding certificate in the chain (except for the Entity certificate).
Subject and Issuer are the same for the root certificate.
If the certificates in the chain adhere to these guidelines, then the certificate chain is considered to be complete and valid.

Sample certificate chain validation through hash sequence

The following example is the output of the OpenSSL commands for a sample certificate chain containing three certificates:


openssl x509 -in entity.pem -hash -issuer_hash -noout
c54c66ba #this is subject hash
99bdd351 #this is issuer hash
    

openssl x509 -in intermediate.pem -hash -issuer_hash -noout
99bdd351
4a6481c9
    

openssl x509 -in root.pem -hash -issuer_hash -noout
4a6481c9
4a6481c9
    
In the example shown above, notice the following:

The subject hash of the intermediate certificate matches the issuer hash of the entity certificate.
The subject hash of the root certificate matches the issuer hash of the issuer certificate.
The subject and issuer hash are the same in the root certificate.
From the example above, you can confirm that the sample certificate chain is valid.

Verifying the certificate expiry

This section explains how to verify whether or not all the certificates in the chain are expired using of the following methods:

Get the start and end date of the certificate.
Get the expiry status.
START AND END DATE
EXPIRY STATUS
Run the following OpenSSL command to get the start and end date for each certificate in the chain from entity to root and verify that all the certificates in the chain are in force (start date is before today) and are not expired.

Sample certificate expiry validation through start and end dates


openssl x509 -startdate -enddate -noout -in entity.pem
notBefore=Feb  6 21:57:21 2020 GMT
notAfter=Feb  4 21:57:21 2021 GMT

openssl x509 -startdate -enddate -noout -in intermediate.pem
notBefore=Jun 15 00:00:42 2017 GMT
notAfter=Dec 15 00:00:42 2021 GMT

openssl x509 -startdate -enddate -noout -in root.pem
notBefore=Apr 13 10:00:00 2011 GMT
notAfter=Apr 13 10:00:00 2022 GMT

Ссылки

Источник — https://noname.com.ua/mediawiki/index.php?title=Ssl&oldid=13866