Ssl: различия между версиями
Материал из noname.com.ua
Перейти к навигацииПерейти к поискуSirmax (обсуждение | вклад) |
Sirmax (обсуждение | вклад) |
||
(не показано 9 промежуточных версий этого же участника) | |||
Строка 5: | Строка 5: | ||
=OpenSSL= |
=OpenSSL= |
||
− | Заметки на полях что б каждый раз не читать мануал |
+ | Заметки на полях что б каждый раз не читать мануал (ssl, openssl) |
==Получить сертефикат== |
==Получить сертефикат== |
||
Строка 169: | Строка 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