Re: Question on "unsupported certificate purpose" error when trying to read the certificate on the web server
An EE certificate is an "end entity" certificate, which identifies an entity that isn't a certifier. On Wed, Jul 21, 2021, 18:23 Thejus Prabhu wrote: > Thanks for your reply Viktor. I would like to add that this is a self > signed certificate created on the server. What is EE certificate? > > > On Wed, Jul 21, 2021 at 6:55 PM Viktor Dukhovni < > openssl-us...@dukhovni.org> wrote: > >> On Wed, Jul 21, 2021 at 06:34:03PM -0400, Thejus Prabhu wrote: >> >> > verify error:num=26:unsupported certificate purpose >> >> The certificate in question is CA certificate, not an EE certificate. >> Specifically, the key usage and Netscape Cert Type signal that its >> purpose is exclusively to be a CA, not a TLS server. >> >> X509v3 Key Usage: critical >> Certificate Sign, CRL Sign >> Netscape Cert Type: >> SSL CA >> >> > Certificate: >> > Data: >> > Version: 3 (0x2) >> > Serial Number: 1 (0x1) >> > Signature Algorithm: sha1WithRSAEncryption >> > Issuer: O = Verint, C = US, CN = 192.168.1.200, L = Columbia, >> OU = Verint >> > Validity >> > Not Before: Jul 21 20:51:12 2021 GMT >> > Not After : Jul 21 20:51:12 2022 GMT >> > Subject: O = Verint, C = US, CN = 192.168.1.200, L = >> Columbia, OU = Verint >> > Subject Public Key Info: >> > Public Key Algorithm: rsaEncryption >> > RSA Public-Key: (2048 bit) >> > Modulus: >> > 00:b8:e8:bd:08:10:e4:d9:2d:77:52:33:8c:15:30: >> > cf:89:a0:d4:bd:95:85:15:ba:54:37:8d:5b:17:e4: >> > 4d:3f:a3:fb:0c:08:ee:7e:30:eb:5d:93:fd:db:f3: >> > 51:85:60:91:66:04:e1:b2:55:fd:5a:cf:c1:7c:3a: >> > 3b:4c:30:af:67:b8:2f:21:7c:42:a4:86:8e:d3:a8: >> > ea:b2:8e:22:f3:b7:08:90:ec:8f:7a:20:1a:ae:44: >> > 45:8c:db:2c:ee:20:d9:56:7a:8b:b9:d0:b9:0b:5b: >> > ac:7b:e0:f4:53:29:b4:06:cb:5e:fd:cf:87:b7:5d: >> > 9f:bb:e7:71:33:27:f8:b4:01:d5:78:75:5e:99:e1: >> > dc:7d:5b:12:78:12:d6:38:07:f5:73:3c:8e:9b:62: >> > d6:ae:30:f5:8f:31:7e:42:81:2d:10:b4:6a:2c:33: >> > 7c:48:db:95:9c:af:a9:ca:8b:92:c2:93:93:59:7a: >> > a0:a6:42:dd:72:e8:b8:21:d8:75:05:7a:8f:47:19: >> > ca:3d:ae:89:a6:d3:87:fc:2a:02:c4:49:58:28:05: >> > d5:d2:a9:fc:f5:06:40:1e:35:38:2e:33:f3:31:f2: >> > c9:a8:16:6e:b9:0a:42:95:6e:de:1f:f7:3e:2d:c8: >> > 34:64:00:77:d4:cf:5c:3d:28:78:ce:60:bd:e5:90: >> > 09:a9 >> > Exponent: 65537 (0x10001) >> > X509v3 extensions: >> > X509v3 Basic Constraints: critical >> > CA:TRUE >> > X509v3 Key Usage: critical >> > Certificate Sign, CRL Sign >> > X509v3 Subject Key Identifier: >> > >> A2:FF:95:62:C7:85:BC:1A:FE:D5:0B:F8:F7:A8:B1:B4:BF:29:8B:7D >> > Netscape Cert Type: >> > SSL CA >> > Netscape Comment: >> > example comment extension >> > Signature Algorithm: sha1WithRSAEncryption >> >73:f4:61:1c:f1:b7:d3:c4:e2:ae:b1:ea:1e:3f:b2:6b:bc:f3: >> >85:80:a1:0d:a8:06:7e:5a:bd:2b:fe:13:ce:4d:80:4d:c8:3d: >> >4a:95:f9:ee:9c:19:1d:6b:b4:57:79:72:d9:00:e7:d1:be:9c: >> >c3:4f:2d:77:93:71:45:87:8f:99:bd:35:43:95:1b:69:31:71: >> >f9:f4:ee:00:1f:cd:f7:f4:2e:b1:ae:e7:9c:8e:cb:ce:86:50: >> >d8:1b:4e:3c:11:77:63:55:09:74:4c:89:ce:34:ae:4e:75:80: >> >e8:9e:37:23:75:e2:eb:bf:27:f8:dc:07:9d:64:b3:96:01:84: >> >4a:62:23:c9:52:0f:92:e1:4a:3f:db:c7:b9:82:e9:8b:bb:89: >> >7f:6c:fc:90:da:e1:2b:e9:8f:a3:d2:8c:66:22:5a:4e:27:77: >> >f9:88:0e:7c:87:45:c4:56:4b:c8:fa:93:7c:18:3a:d5:cd:a3: >> >59:6e:e2:37:a6:45:57:e8:8f:1f:d6:65:b9:47:e4:5c:c0:83: >> >80:63:ac:2d:1d:6a:0f:95:62:00:18:b0:66:4f:b7:76:5a:1f: >> >f6:7c:27:f7:86:3e:8d:fc:1c:b0:d9:7c:60:44:61:e9:eb:ff: >> >95:b4:31:67:df:d1:ce:fc:91:3e:f3:64:fa:ca:c8:29:16:3b: >> >d4:ae:f4:0e >> > -BEGIN CERTIFICATE- >> > MIIDrjCCApagAwIBAgIBATANBgkqhkiG9w0BAQUFADBaMQ8wDQYDVQQKDAZWZXJp >> > bnQxCzAJBgNVBAYTAlVTMRYwFAYDVQQDDA0xOTIuMTY4LjEuMjAwMREwDwYDVQQH >> > DAhDb2x1bWJpYTEPMA0GA1UECwwGVmVyaW50MB4XDTIxMDcyMTIwNTExMloXDTIy >> > MDcyMTIwNTExMlowWjEPMA0GA1UECgwGVmVyaW50MQswCQYDVQQGEwJVUzEWMBQG >> > A1UEAwwNMTkyLjE2OC4xLjIwMDERMA8GA1UEBwwIQ29sdW1iaWExDzANBgNVBAsM >> > BlZlcmludDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALjovQgQ5Nkt >> > d1IzjBUwz4mg1L2VhRW6VDeNWxfkTT+j+wwI7n4w612T/dvzUYVgkWYE4bJV/VrP >> >
Re: Question on "unsupported certificate purpose" error when trying to read the certificate on the web server
Thanks for your reply Viktor. I would like to add that this is a self signed certificate created on the server. What is EE certificate? On Wed, Jul 21, 2021 at 6:55 PM Viktor Dukhovni wrote: > On Wed, Jul 21, 2021 at 06:34:03PM -0400, Thejus Prabhu wrote: > > > verify error:num=26:unsupported certificate purpose > > The certificate in question is CA certificate, not an EE certificate. > Specifically, the key usage and Netscape Cert Type signal that its > purpose is exclusively to be a CA, not a TLS server. > > X509v3 Key Usage: critical > Certificate Sign, CRL Sign > Netscape Cert Type: > SSL CA > > > Certificate: > > Data: > > Version: 3 (0x2) > > Serial Number: 1 (0x1) > > Signature Algorithm: sha1WithRSAEncryption > > Issuer: O = Verint, C = US, CN = 192.168.1.200, L = Columbia, > OU = Verint > > Validity > > Not Before: Jul 21 20:51:12 2021 GMT > > Not After : Jul 21 20:51:12 2022 GMT > > Subject: O = Verint, C = US, CN = 192.168.1.200, L = Columbia, > OU = Verint > > Subject Public Key Info: > > Public Key Algorithm: rsaEncryption > > RSA Public-Key: (2048 bit) > > Modulus: > > 00:b8:e8:bd:08:10:e4:d9:2d:77:52:33:8c:15:30: > > cf:89:a0:d4:bd:95:85:15:ba:54:37:8d:5b:17:e4: > > 4d:3f:a3:fb:0c:08:ee:7e:30:eb:5d:93:fd:db:f3: > > 51:85:60:91:66:04:e1:b2:55:fd:5a:cf:c1:7c:3a: > > 3b:4c:30:af:67:b8:2f:21:7c:42:a4:86:8e:d3:a8: > > ea:b2:8e:22:f3:b7:08:90:ec:8f:7a:20:1a:ae:44: > > 45:8c:db:2c:ee:20:d9:56:7a:8b:b9:d0:b9:0b:5b: > > ac:7b:e0:f4:53:29:b4:06:cb:5e:fd:cf:87:b7:5d: > > 9f:bb:e7:71:33:27:f8:b4:01:d5:78:75:5e:99:e1: > > dc:7d:5b:12:78:12:d6:38:07:f5:73:3c:8e:9b:62: > > d6:ae:30:f5:8f:31:7e:42:81:2d:10:b4:6a:2c:33: > > 7c:48:db:95:9c:af:a9:ca:8b:92:c2:93:93:59:7a: > > a0:a6:42:dd:72:e8:b8:21:d8:75:05:7a:8f:47:19: > > ca:3d:ae:89:a6:d3:87:fc:2a:02:c4:49:58:28:05: > > d5:d2:a9:fc:f5:06:40:1e:35:38:2e:33:f3:31:f2: > > c9:a8:16:6e:b9:0a:42:95:6e:de:1f:f7:3e:2d:c8: > > 34:64:00:77:d4:cf:5c:3d:28:78:ce:60:bd:e5:90: > > 09:a9 > > Exponent: 65537 (0x10001) > > X509v3 extensions: > > X509v3 Basic Constraints: critical > > CA:TRUE > > X509v3 Key Usage: critical > > Certificate Sign, CRL Sign > > X509v3 Subject Key Identifier: > > > A2:FF:95:62:C7:85:BC:1A:FE:D5:0B:F8:F7:A8:B1:B4:BF:29:8B:7D > > Netscape Cert Type: > > SSL CA > > Netscape Comment: > > example comment extension > > Signature Algorithm: sha1WithRSAEncryption > >73:f4:61:1c:f1:b7:d3:c4:e2:ae:b1:ea:1e:3f:b2:6b:bc:f3: > >85:80:a1:0d:a8:06:7e:5a:bd:2b:fe:13:ce:4d:80:4d:c8:3d: > >4a:95:f9:ee:9c:19:1d:6b:b4:57:79:72:d9:00:e7:d1:be:9c: > >c3:4f:2d:77:93:71:45:87:8f:99:bd:35:43:95:1b:69:31:71: > >f9:f4:ee:00:1f:cd:f7:f4:2e:b1:ae:e7:9c:8e:cb:ce:86:50: > >d8:1b:4e:3c:11:77:63:55:09:74:4c:89:ce:34:ae:4e:75:80: > >e8:9e:37:23:75:e2:eb:bf:27:f8:dc:07:9d:64:b3:96:01:84: > >4a:62:23:c9:52:0f:92:e1:4a:3f:db:c7:b9:82:e9:8b:bb:89: > >7f:6c:fc:90:da:e1:2b:e9:8f:a3:d2:8c:66:22:5a:4e:27:77: > >f9:88:0e:7c:87:45:c4:56:4b:c8:fa:93:7c:18:3a:d5:cd:a3: > >59:6e:e2:37:a6:45:57:e8:8f:1f:d6:65:b9:47:e4:5c:c0:83: > >80:63:ac:2d:1d:6a:0f:95:62:00:18:b0:66:4f:b7:76:5a:1f: > >f6:7c:27:f7:86:3e:8d:fc:1c:b0:d9:7c:60:44:61:e9:eb:ff: > >95:b4:31:67:df:d1:ce:fc:91:3e:f3:64:fa:ca:c8:29:16:3b: > >d4:ae:f4:0e > > -BEGIN CERTIFICATE- > > MIIDrjCCApagAwIBAgIBATANBgkqhkiG9w0BAQUFADBaMQ8wDQYDVQQKDAZWZXJp > > bnQxCzAJBgNVBAYTAlVTMRYwFAYDVQQDDA0xOTIuMTY4LjEuMjAwMREwDwYDVQQH > > DAhDb2x1bWJpYTEPMA0GA1UECwwGVmVyaW50MB4XDTIxMDcyMTIwNTExMloXDTIy > > MDcyMTIwNTExMlowWjEPMA0GA1UECgwGVmVyaW50MQswCQYDVQQGEwJVUzEWMBQG > > A1UEAwwNMTkyLjE2OC4xLjIwMDERMA8GA1UEBwwIQ29sdW1iaWExDzANBgNVBAsM > > BlZlcmludDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALjovQgQ5Nkt > > d1IzjBUwz4mg1L2VhRW6VDeNWxfkTT+j+wwI7n4w612T/dvzUYVgkWYE4bJV/VrP > > wXw6O0wwr2e4LyF8QqSGjtOo6rKOIvO3CJDsj3ogGq5ERYzbLO4g2VZ6i7nQuQtb > > rHvg9FMptAbLXv3Ph7ddn7vncTMn+LQB1Xh1Xpnh3H1bEngS1jgH9XM8jpti1q4w > > 9Y8xfkKBLRC0aiwzfEjblZyvqcqLksKTk1l6oKZC3XLouCHYdQV6j0cZyj2uiabT > > h/wqAsRJWCgF1dKp/PUGQB41OC4z8zHyyagWbrkKQpVu3h/3Pi3INGQAd9TPXD0o > >
Re: Question on "unsupported certificate purpose" error when trying to read the certificate on the web server
On Wed, Jul 21, 2021 at 06:34:03PM -0400, Thejus Prabhu wrote: > verify error:num=26:unsupported certificate purpose The certificate in question is CA certificate, not an EE certificate. Specifically, the key usage and Netscape Cert Type signal that its purpose is exclusively to be a CA, not a TLS server. X509v3 Key Usage: critical Certificate Sign, CRL Sign Netscape Cert Type: SSL CA > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 1 (0x1) > Signature Algorithm: sha1WithRSAEncryption > Issuer: O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = > Verint > Validity > Not Before: Jul 21 20:51:12 2021 GMT > Not After : Jul 21 20:51:12 2022 GMT > Subject: O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = > Verint > Subject Public Key Info: > Public Key Algorithm: rsaEncryption > RSA Public-Key: (2048 bit) > Modulus: > 00:b8:e8:bd:08:10:e4:d9:2d:77:52:33:8c:15:30: > cf:89:a0:d4:bd:95:85:15:ba:54:37:8d:5b:17:e4: > 4d:3f:a3:fb:0c:08:ee:7e:30:eb:5d:93:fd:db:f3: > 51:85:60:91:66:04:e1:b2:55:fd:5a:cf:c1:7c:3a: > 3b:4c:30:af:67:b8:2f:21:7c:42:a4:86:8e:d3:a8: > ea:b2:8e:22:f3:b7:08:90:ec:8f:7a:20:1a:ae:44: > 45:8c:db:2c:ee:20:d9:56:7a:8b:b9:d0:b9:0b:5b: > ac:7b:e0:f4:53:29:b4:06:cb:5e:fd:cf:87:b7:5d: > 9f:bb:e7:71:33:27:f8:b4:01:d5:78:75:5e:99:e1: > dc:7d:5b:12:78:12:d6:38:07:f5:73:3c:8e:9b:62: > d6:ae:30:f5:8f:31:7e:42:81:2d:10:b4:6a:2c:33: > 7c:48:db:95:9c:af:a9:ca:8b:92:c2:93:93:59:7a: > a0:a6:42:dd:72:e8:b8:21:d8:75:05:7a:8f:47:19: > ca:3d:ae:89:a6:d3:87:fc:2a:02:c4:49:58:28:05: > d5:d2:a9:fc:f5:06:40:1e:35:38:2e:33:f3:31:f2: > c9:a8:16:6e:b9:0a:42:95:6e:de:1f:f7:3e:2d:c8: > 34:64:00:77:d4:cf:5c:3d:28:78:ce:60:bd:e5:90: > 09:a9 > Exponent: 65537 (0x10001) > X509v3 extensions: > X509v3 Basic Constraints: critical > CA:TRUE > X509v3 Key Usage: critical > Certificate Sign, CRL Sign > X509v3 Subject Key Identifier: > A2:FF:95:62:C7:85:BC:1A:FE:D5:0B:F8:F7:A8:B1:B4:BF:29:8B:7D > Netscape Cert Type: > SSL CA > Netscape Comment: > example comment extension > Signature Algorithm: sha1WithRSAEncryption >73:f4:61:1c:f1:b7:d3:c4:e2:ae:b1:ea:1e:3f:b2:6b:bc:f3: >85:80:a1:0d:a8:06:7e:5a:bd:2b:fe:13:ce:4d:80:4d:c8:3d: >4a:95:f9:ee:9c:19:1d:6b:b4:57:79:72:d9:00:e7:d1:be:9c: >c3:4f:2d:77:93:71:45:87:8f:99:bd:35:43:95:1b:69:31:71: >f9:f4:ee:00:1f:cd:f7:f4:2e:b1:ae:e7:9c:8e:cb:ce:86:50: >d8:1b:4e:3c:11:77:63:55:09:74:4c:89:ce:34:ae:4e:75:80: >e8:9e:37:23:75:e2:eb:bf:27:f8:dc:07:9d:64:b3:96:01:84: >4a:62:23:c9:52:0f:92:e1:4a:3f:db:c7:b9:82:e9:8b:bb:89: >7f:6c:fc:90:da:e1:2b:e9:8f:a3:d2:8c:66:22:5a:4e:27:77: >f9:88:0e:7c:87:45:c4:56:4b:c8:fa:93:7c:18:3a:d5:cd:a3: >59:6e:e2:37:a6:45:57:e8:8f:1f:d6:65:b9:47:e4:5c:c0:83: >80:63:ac:2d:1d:6a:0f:95:62:00:18:b0:66:4f:b7:76:5a:1f: >f6:7c:27:f7:86:3e:8d:fc:1c:b0:d9:7c:60:44:61:e9:eb:ff: >95:b4:31:67:df:d1:ce:fc:91:3e:f3:64:fa:ca:c8:29:16:3b: >d4:ae:f4:0e > -BEGIN CERTIFICATE- > MIIDrjCCApagAwIBAgIBATANBgkqhkiG9w0BAQUFADBaMQ8wDQYDVQQKDAZWZXJp > bnQxCzAJBgNVBAYTAlVTMRYwFAYDVQQDDA0xOTIuMTY4LjEuMjAwMREwDwYDVQQH > DAhDb2x1bWJpYTEPMA0GA1UECwwGVmVyaW50MB4XDTIxMDcyMTIwNTExMloXDTIy > MDcyMTIwNTExMlowWjEPMA0GA1UECgwGVmVyaW50MQswCQYDVQQGEwJVUzEWMBQG > A1UEAwwNMTkyLjE2OC4xLjIwMDERMA8GA1UEBwwIQ29sdW1iaWExDzANBgNVBAsM > BlZlcmludDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALjovQgQ5Nkt > d1IzjBUwz4mg1L2VhRW6VDeNWxfkTT+j+wwI7n4w612T/dvzUYVgkWYE4bJV/VrP > wXw6O0wwr2e4LyF8QqSGjtOo6rKOIvO3CJDsj3ogGq5ERYzbLO4g2VZ6i7nQuQtb > rHvg9FMptAbLXv3Ph7ddn7vncTMn+LQB1Xh1Xpnh3H1bEngS1jgH9XM8jpti1q4w > 9Y8xfkKBLRC0aiwzfEjblZyvqcqLksKTk1l6oKZC3XLouCHYdQV6j0cZyj2uiabT > h/wqAsRJWCgF1dKp/PUGQB41OC4z8zHyyagWbrkKQpVu3h/3Pi3INGQAd9TPXD0o > eM5gveWQCakCAwEAAaN/MH0wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMC > AQYwHQYDVR0OBBYEFKL/lWLHhbwa/tUL+PeosbS/KYt9MBEGCWCGSAGG+EIBAQQE > AwICBDAoBglghkgBhvhCAQ0EGxYZZXhhbXBsZSBjb21tZW50IGV4dGVuc2lvbjAN > BgkqhkiG9w0BAQUFAAOCAQEAc/RhHPG308TirrHqHj+ya7zzhYChDagGflq9K/4T > zk2ATcg9SpX57pwZHWu0V3ly2QDn0b6cw08td5NxRYePmb01Q5UbaTFx+fTuAB/N >
Question on "unsupported certificate purpose" error when trying to read the certificate on the web server
Hi,
I am new to openssl and learning how to use it.
I am trying to read the self-signed SSL certificate created on a webserver.
I am using OpenSSL 1.1.1k on the client machine when I make a request
using:
openssl s_client -showcerts -connect 192.168.1.200:443
I end up with the following error "*unsupported certificate purpose" *from
the server.
CONNECTED(0003)
Can't use SSL_get_servername
depth=0 O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint
verify error:num=18:self signed certificate
verify return:1
depth=0 O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint
verify error:num=26:unsupported certificate purpose
verify return:1
depth=0 O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint
verify return:1
---
Certificate chain
0 s:O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint
i:O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint
-BEGIN CERTIFICATE-
MIIDrjCCApagAwIBAgIBATANBgkqhkiG9w0BAQUFADBaMQ8wDQYDVQQKDAZWZXJp
bnQxCzAJBgNVBAYTAlVTMRYwFAYDVQQDDA0xOTIuMTY4LjEuMjAwMREwDwYDVQQH
DAhDb2x1bWJpYTEPMA0GA1UECwwGVmVyaW50MB4XDTIxMDcyMTIwNTExMloXDTIy
MDcyMTIwNTExMlowWjEPMA0GA1UECgwGVmVyaW50MQswCQYDVQQGEwJVUzEWMBQG
A1UEAwwNMTkyLjE2OC4xLjIwMDERMA8GA1UEBwwIQ29sdW1iaWExDzANBgNVBAsM
BlZlcmludDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALjovQgQ5Nkt
d1IzjBUwz4mg1L2VhRW6VDeNWxfkTT+j+wwI7n4w612T/dvzUYVgkWYE4bJV/VrP
wXw6O0wwr2e4LyF8QqSGjtOo6rKOIvO3CJDsj3ogGq5ERYzbLO4g2VZ6i7nQuQtb
rHvg9FMptAbLXv3Ph7ddn7vncTMn+LQB1Xh1Xpnh3H1bEngS1jgH9XM8jpti1q4w
9Y8xfkKBLRC0aiwzfEjblZyvqcqLksKTk1l6oKZC3XLouCHYdQV6j0cZyj2uiabT
h/wqAsRJWCgF1dKp/PUGQB41OC4z8zHyyagWbrkKQpVu3h/3Pi3INGQAd9TPXD0o
eM5gveWQCakCAwEAAaN/MH0wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMC
AQYwHQYDVR0OBBYEFKL/lWLHhbwa/tUL+PeosbS/KYt9MBEGCWCGSAGG+EIBAQQE
AwICBDAoBglghkgBhvhCAQ0EGxYZZXhhbXBsZSBjb21tZW50IGV4dGVuc2lvbjAN
BgkqhkiG9w0BAQUFAAOCAQEAc/RhHPG308TirrHqHj+ya7zzhYChDagGflq9K/4T
zk2ATcg9SpX57pwZHWu0V3ly2QDn0b6cw08td5NxRYePmb01Q5UbaTFx+fTuAB/N
9/Qusa7nnI7LzoZQ2BtOPBF3Y1UJdEyJzjSuTnWA6J43I3Xi678n+NwHnWSzlgGE
SmIjyVIPkuFKP9vHuYLpi7uJf2z8kNrhK+mPo9KMZiJaTid3+YgOfIdFxFZLyPqT
fBg61c2jWW7iN6ZFV+iPH9ZluUfkXMCDgGOsLR1qD5ViABiwZk+3dlof9nwn94Y+
jfwcsNl8YERh6ev/lbQxZ9/RzvyRPvNk+srIKRY71K70Dg==
-END CERTIFICATE-
---
Server certificate
subject=O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint
issuer=O = Verint, C = US, CN = 192.168.1.200, L = Columbia, OU = Verint
---
No client certificate CA names sent
---
SSL handshake has read 1258 bytes and written 613 bytes
Verification error: unsupported certificate purpose
---
New, TLSv1.2, Cipher is AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher: AES256-GCM-SHA384
Session-ID:
CE62110F0FC98BF92D285826C94F8E243287309A5B8C685763E228E5A121B04C
Session-ID-ctx:
Master-Key:
1CD43EA64ED4BAABE3E2BD1B33BFFDDB3E9505D1BF786C5137E23D8FC10B117B6F05709A03312288FAAFFB0990258706
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
- 97 4d 2d 40 e0 55 22 0a-a0 9b a0 f6 76 03 a7 66 .M-@
.U".v..f
0010 - 1c 12 4d d7 d3 48 64 48-d3 86 b8 69 a2 02 74 64
..M..HdH...i..td
0020 - a7 01 59 99 98 f1 a7 7b-e1 8d 64 ec 42 e1 d1 9b
..Y{..d.B...
0030 - 4d 7a e1 6b 01 8b 0d fd-b5 f0 59 b5 ba 9e d8 ab
Mz.k..Y.
0040 - 2f c4 59 9b 85 c6 78 09-28 da 86 ea a7 fe a0 53
/.Y...x.(..S
0050 - 2e 74 2c 28 e2 91 f6 94-cc 35 7f 25 ab b1 b8 cd
.t,(.5.%
0060 - 48 96 af 36 de 28 46 d6-65 ce 00 ac a0 df f5 d3
H..6.(F.e...
0070 - bd f3 bb 6c 79 e6 3d 69-9c 50 0a db 3b f2 7c f4
...ly.=i.P..;.|.
0080 - 23 c9 29 62 b4 8c a5 55-70 ab 3d 18 1a f3 86 05
#.)b...Up.=.
0090 - b1 48 11 1d 29 d0 06 e5-df 32 3c fd 09 76 c7 55
.H..)2<..v.U
Start Time: 1626906266
Timeout : 7200 (sec)
Verify return code: 26 (*unsupported certificate purpose*)
Extended master secret: yes
---
Now I do not have access to the server but I would like to know what
"*unsupported
certificate purpose" *mean? Could anyone throw some light on this?
Directory structure ( SSL/TLS/HTTPS )
Learning to use opessl, I managed to generate private keys and publish in .pem format and I also signed where I was generated two types of private files (.csr and .crt), my doubts on the linux server running (debian 10) where I keep such keys because I want to serve web pages in the format (https)? *Webstrucs* Serviço de Atendimento Segunda - Sexta / 07:00 - 17:00 webstrucs.com
Re: verify ocsp manually
Try sending that block to
pbpaste| xxd -r -p | openssl asn1parse -inform DER
0:d=0 hl=3 l= 190 cons: SEQUENCE
3:d=1 hl=2 l= 52 cons: cont [ 1 ]
5:d=2 hl=2 l= 50 cons: SEQUENCE
7:d=3 hl=2 l= 11 cons: SET
9:d=4 hl=2 l= 9 cons: SEQUENCE
11:d=5 hl=2 l= 3 prim: OBJECT:countryName
16:d=5 hl=2 l= 2 prim: PRINTABLESTRING :US
20:d=3 hl=2 l= 22 cons: SET
22:d=4 hl=2 l= 20 cons: SEQUENCE
24:d=5 hl=2 l= 3 prim: OBJECT:organizationName
29:d=5 hl=2 l= 13 prim: PRINTABLESTRING :Let's Encrypt
44:d=3 hl=2 l= 11 cons: SET
46:d=4 hl=2 l= 9 cons: SEQUENCE
48:d=5 hl=2 l= 3 prim: OBJECT:commonName
53:d=5 hl=2 l= 2 prim: PRINTABLESTRING :R3
57:d=1 hl=2 l= 15 prim: GENERALIZEDTIME :2021071818Z
74:d=1 hl=2 l= 117 cons: SEQUENCE
76:d=2 hl=2 l= 115 cons: SEQUENCE
78:d=3 hl=2 l= 75 cons: SEQUENCE
80:d=4 hl=2 l= 9 cons: SEQUENCE
82:d=5 hl=2 l= 5 prim: OBJECT:sha1
89:d=5 hl=2 l= 0 prim: NULL
91:d=4 hl=2 l= 20 prim: OCTET STRING [HEX
DUMP]:48DAC9A0FB2BD32D4FF0DE68D2F567B735F9B3C4
113:d=4 hl=2 l= 20 prim: OCTET STRING [HEX
DUMP]:142EB317B75856CBAE500940E61FAF9D8B14C2C6
135:d=4 hl=2 l= 18 prim: INTEGER
:03DCBE0133C9B833125475B4A77AB54A3DF6
155:d=3 hl=2 l= 0 prim: cont [ 0 ]
157:d=3 hl=2 l= 15 prim: GENERALIZEDTIME :2021071818Z
174:d=3 hl=2 l= 17 cons: cont [ 0 ]
176:d=4 hl=2 l= 15 prim: GENERALIZEDTIME :2021072518Z
> On 21 Jul 2021, at 11:11, Gaardiolor wrote:
>
> Oh.. I'm a step further. I've checked every byte range of the ocsp response
> for the recovered sha256 signature.
>
> $ len=`cat ocsp.resp | wc -c`
> $ for start in `seq 1 $len`; do
> echo -n "$start "
> for end in `seq 1 $[$len+1-$start]`; do
> output=`cat ocsp.resp | tail -c +$start | head -c $end | sha256sum|
> grep b483f2c34a6c1b4edf66b4d5310b58c3603ce9200f4fb0df61882fc0e02566a8`
> if [ "$output" != "" ]; then
> echo ''
> echo $start $end $output
>cat ocsp.resp | tail -c +$start | head -c $end | od -An -tx1
> break
> fi
> done
> if [ "$output" != "" ]; then break; fi
> done
>
>
> 35 193 b483f2c34a6c1b4edf66b4d5310b58c3603ce9200f4fb0df61882fc0e02566a8 -
> 30 81 be a1 34 30 32 31 0b 30 09 06 03 55 04 06
> 13 02 55 53 31 16 30 14 06 03 55 04 0a 13 0d 4c
> 65 74 27 73 20 45 6e 63 72 79 70 74 31 0b 30 09
> 06 03 55 04 03 13 02 52 33 18 0f 32 30 32 31 30
> 37 31 38 31 38 30 30 30 30 5a 30 75 30 73 30 4b
> 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 48 da c9
> a0 fb 2b d3 2d 4f f0 de 68 d2 f5 67 b7 35 f9 b3
> c4 04 14 14 2e b3 17 b7 58 56 cb ae 50 09 40 e6
> 1f af 9d 8b 14 c2 c6 02 12 03 dc be 01 33 c9 b8
> 33 12 54 75 b4 a7 7a b5 4a 3d f6 80 00 18 0f 32
> 30 32 31 30 37 31 38 31 38 30 30 30 30 5a a0 11
> 18 0f 32 30 32 31 30 37 32 35 31 38 30 30 30 30
> 5a
>
>
> So the TBS part starts in byte 35 and is 193 bytes long, meaning bytes
> 35-227.
>
> Looking at wireshark, that's indeed the 'tbsResponseData'. Any way to extract
> the tbs with openssl ? Thanks.
>
>
>
> On 2021-07-21 00:04, Gaardiolor wrote:
>> Good day,
>>
>> I don't fully understand ocsp certificate verification. In order to better
>> understand it, I want to do it manually. I can already do that with
>> certificates.
>>
>> $ openssl s_client -connect openssl.org:443 -showcerts
>> # I save the server.crt and intermediate.crt
>>
>> $ openssl verify -no-CApath -partial_chain -trusted intermediate.crt
>> server.crt
>> server.crt: OK
>>
>> Manually:
>> # Get the ASN id's of the TBS and Signature
>> $ asn=`openssl asn1parse -i -in server.crt |egrep -e '(^ .*: SEQUENCE|: BIT
>> STRING)'`
>> $ asn_tbs=`echo "$asn" | head -1 | awk -F: '{print $1}' | sed 's/ //g'`
>> $ asn_sig=`echo "$asn" | tail -1 | awk -F: '{print $1}' | sed 's/ //g'`
>>
>> # Get tbs
>> openssl asn1parse -in server.crt -strparse ${asn_tbs} -out server.tbs >
>> /dev/null
>>
>> # Hash tbs
>> $ cat server.tbs | openssl sha256 -binary > server.tbs.sha256
>>
>> # Get signature (ignore 'header too long' error)
>> $ openssl asn1parse -in server.crt -strparse ${asn_sig} -out server.sig >
>> /dev/null
>>
>> # Get public key of intermediate
>> $ openssl x509 -in intermediate.crt -noout -pubkey > intermediate.pub
>>
>> # Recover (decrypt) the signature
>> $ openssl rsautl -inkey intermediate.pub -pubin -in server.sig -out
>> server.sig.recovered
>>
>> # Verify. Ignore the first line of server.sig.recovered, this is the hash
>> algoritm designator
>> $ od -An -tx1 -w19 server.sig.recovered
>> 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
>> 87 36 67 06 ba d7 10 18 72 d3 f6 58 00 a9 34 78 bc 82 bf
>> 57 37 20 ab 82 04 fb 04 78 38 e2
Re: verify ocsp manually
Oh.. I'm a step further. I've checked every byte range of the ocsp
response for the recovered sha256 signature.
$ len=`cat ocsp.resp | wc -c`
$ for start in `seq 1 $len`; do
echo -n "$start "
for end in `seq 1 $[$len+1-$start]`; do
output=`cat ocsp.resp | tail -c +$start | head -c $end |
sha256sum| grep
b483f2c34a6c1b4edf66b4d5310b58c3603ce9200f4fb0df61882fc0e02566a8`
if [ "$output" != "" ]; then
echo ''
echo $start $end $output
cat ocsp.resp | tail -c +$start | head -c $end | od -An -tx1
break
fi
done
if [ "$output" != "" ]; then break; fi
done
35 193 b483f2c34a6c1b4edf66b4d5310b58c3603ce9200f4fb0df61882fc0e02566a8 -
30 81 be a1 34 30 32 31 0b 30 09 06 03 55 04 06
13 02 55 53 31 16 30 14 06 03 55 04 0a 13 0d 4c
65 74 27 73 20 45 6e 63 72 79 70 74 31 0b 30 09
06 03 55 04 03 13 02 52 33 18 0f 32 30 32 31 30
37 31 38 31 38 30 30 30 30 5a 30 75 30 73 30 4b
30 09 06 05 2b 0e 03 02 1a 05 00 04 14 48 da c9
a0 fb 2b d3 2d 4f f0 de 68 d2 f5 67 b7 35 f9 b3
c4 04 14 14 2e b3 17 b7 58 56 cb ae 50 09 40 e6
1f af 9d 8b 14 c2 c6 02 12 03 dc be 01 33 c9 b8
33 12 54 75 b4 a7 7a b5 4a 3d f6 80 00 18 0f 32
30 32 31 30 37 31 38 31 38 30 30 30 30 5a a0 11
18 0f 32 30 32 31 30 37 32 35 31 38 30 30 30 30
5a
So the TBS part starts in byte 35 and is 193 bytes long, meaning bytes
35-227.
Looking at wireshark, that's indeed the 'tbsResponseData'. Any way to
extract the tbs with openssl ? Thanks.
On 2021-07-21 00:04, Gaardiolor wrote:
Good day,
I don't fully understand ocsp certificate verification. In order to
better understand it, I want to do it manually. I can already do that
with certificates.
$ openssl s_client -connect openssl.org:443 -showcerts
# I save the server.crt and intermediate.crt
$ openssl verify -no-CApath -partial_chain -trusted intermediate.crt
server.crt
server.crt: OK
Manually:
# Get the ASN id's of the TBS and Signature
$ asn=`openssl asn1parse -i -in server.crt |egrep -e '(^ .*:
SEQUENCE|: BIT STRING)'`
$ asn_tbs=`echo "$asn" | head -1 | awk -F: '{print $1}' | sed 's/ //g'`
$ asn_sig=`echo "$asn" | tail -1 | awk -F: '{print $1}' | sed 's/ //g'`
# Get tbs
openssl asn1parse -in server.crt -strparse ${asn_tbs} -out server.tbs
> /dev/null
# Hash tbs
$ cat server.tbs | openssl sha256 -binary > server.tbs.sha256
# Get signature (ignore 'header too long' error)
$ openssl asn1parse -in server.crt -strparse ${asn_sig} -out
server.sig > /dev/null
# Get public key of intermediate
$ openssl x509 -in intermediate.crt -noout -pubkey > intermediate.pub
# Recover (decrypt) the signature
$ openssl rsautl -inkey intermediate.pub -pubin -in server.sig -out
server.sig.recovered
# Verify. Ignore the first line of server.sig.recovered, this is the
hash algoritm designator
$ od -An -tx1 -w19 server.sig.recovered
30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
87 36 67 06 ba d7 10 18 72 d3 f6 58 00 a9 34 78 bc 82 bf
57 37 20 ab 82 04 fb 04 78 38 e2 d3 a2
$ od -An -tx1 -w19 server.tbs.sha256
87 36 67 06 ba d7 10 18 72 d3 f6 58 00 a9 34 78 bc 82 bf
57 37 20 ab 82 04 fb 04 78 38 e2 d3 a2
Yay. Now how do I do that with OCSP ?
# Get OCSP
$ ocsp=`openssl x509 -noout -ocsp_uri -in server.crt`
# Verify
$ ocsp_response=`openssl ocsp -noverify -no_nonce -respout ocsp.resp
-reqout ocsp.req -issuer intermediate.crt -cert server.crt -text -url
$ocsp`
$ echo "$ocsp_response" | grep server.crt
server.crt: good
Manually:
# Get the signature. Can't find how to do this with asn1parse
$ for byte in `echo "$ocsp_response" | grep -A40 " Signature
Algorithm" | grep -B40 "server.crt" | egrep -ve '(Signature
Algorithm|server.crt)' | sed -e 's/ //g' -e 's/:/ /g'`; do
echo -ne "\x$byte"
done > ocsp.resp.sig
# Recover (decrypt) the signature
$ openssl rsautl -inkey intermediate.pub -pubin -in ocsp.resp.sig -out
ocsp.resp.sig.recovered
# Print the decrypted signature (looks good, first line is hash
algorithm designator, length looks ok, no errors)
$ od -An -tx1 -w19 ocsp.resp.sig.recovered
30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
b4 83 f2 c3 4a 6c 1b 4e df 66 b4 d5 31 0b 58 c3 60 3c e9
20 0f 4f b0 df 61 88 2f c0 e0 25 66 a8
But.. How to extract the tbs data from the response, so I can sha256
that and compare ?
