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 ?