From dfnsonfsduifb at gmx.de Tue Dec 12 13:21:25 2017 From: dfnsonfsduifb at gmx.de (Johannes Bauer) Date: Tue, 12 Dec 2017 13:21:25 +0100 Subject: [gnutls-help] Problem with OCSP status in gnutls-cli Message-ID: Hi list, I'm currently writing some software for pentesting. It includes an OCSP and TLS server that both are based on OpenSSL. With Ubuntu 17.04, I added some integration tests that featured the gnutls-cli TLS client. Yesterday I updated to Ubuntu 17.10 and now the gnutls tests are broken; gnuTLS rejects the OCSP responses from my server as invalid. Let me stress that it is *very* possible that the fault is not gnuTLS, but my software. However, OpenSSL doesn't show any issue with the OCSP response and from the error message I'm getting from gnuTLS I find myself unable to debug the root cause of this issue. Here's the certificates first: Root certificate: -----BEGIN CERTIFICATE----- MIIBwjCCAWmgAwIBAgIRAM+WnyNpKNFHJcOZmR1Ki7UwCgYIKoZIzj0EAwIwMjEe MBwGA1UEAwwVRXZpbCByb290IGNlcnRpZmljYXRlMRAwDgYDVQQLDAdyYXRjaGVk MB4XDTE3MTIxMTExMDI0MVoXDTIyMTIxMTExMDI0MVowMjEeMBwGA1UEAwwVRXZp bCByb290IGNlcnRpZmljYXRlMRAwDgYDVQQLDAdyYXRjaGVkMFkwEwYHKoZIzj0C AQYIKoZIzj0DAQcDQgAEy62s1qumg4c77BUH8BBP1t7p9EhTGMxIXJMKOziUVuV5 Tfz6ioR7U9bIKaEuEX+TGgX50zonsVrL9PnODdP+d6NgMF4wDwYDVR0TAQH/BAUw AwEB/zAdBgNVHQ4EFgQUTV3bnZY4luDxYCj6vSqPjggzKcYwHwYDVR0jBBgwFoAU TV3bnZY4luDxYCj6vSqPjggzKcYwCwYDVR0PBAQDAgGGMAoGCCqGSM49BAMCA0cA MEQCICBvNYUAbTECj4Rbfq68ZdTwuy18BTnASW68S2jDefj2AiB4s46YM0xBjt7n o4DuU/Q/YWNa3y9oOskeflDabrzVuA== -----END CERTIFICATE----- Server certificate: -----BEGIN CERTIFICATE----- MIIBsjCCAVigAwIBAgIQI0huLc/BXgKkidK7C88FEjAKBggqhkjOPQQDAjAyMR4w HAYDVQQDDBVFdmlsIHJvb3QgY2VydGlmaWNhdGUxEDAOBgNVBAsMB3JhdGNoZWQw HhcNMTcxMjExMTIwOTI3WhcNMTgxMjEyMTIwOTI3WjAUMRIwEAYDVQQDDAkxMjcu MC4wLjEwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASM5we/E0r/UYS7NDwpHZx1 nY00vGOgYYffhPTZMpNdF9d2sU3VK1Y9NbLr7pI73OxGVrcxhDqetsS3eQ/Bboa/ o24wbDAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBSx4uRrl2YVFLA2l63vlbBJGi6D vzAfBgNVHSMEGDAWgBRNXdudljiW4PFgKPq9Ko+OCDMpxjALBgNVHQ8EBAMCA6gw DwYDVR0RBAgwBocEfwAAATAKBggqhkjOPQQDAgNIADBFAiEAnnnc8Suuu3yEjVb6 IBbcTjyHSAMj0PJb7NkFp9afaYkCIH8F3OVr5lRwwOf/qLIV2/2r3DwSM6mFS3Hi nYvCH2xs -----END CERTIFICATE----- OCSP response that's included in the ServerHello: -----BEGIN OCSP RESPONSE----- MIIBEgoBAKCCAQswggEHBgkrBgEFBQcwAQEEgfkwgfYwgZ6iFgQUTV3bnZY4luDx YCj6vSqPjggzKcYYDzIwMTcxMjEyMTIwOTI3WjBzMHEwSTAJBgUrDgMCGgUABBS3 Mfjck2a2obQn2qhOU5CfoouacQQUTV3bnZY4luDxYCj6vSqPjggzKcYCECNIbi3P wV4CpInSuwvPBRKAABgPMjAxNzEyMTIwOTA5MjdaoBEYDzIwMTcxMjI2MTIwOTI3 WjAKBggqhkjOPQQDAgNHADBEAiA2SYR4gyroYetUjezA5ZzwJZohOGjms4kBlYw3 Fzp2+AIgBmOh0xlwt6pSE/DRD2p0BtwEirdpb3QXgqirWeOMM1s= -----END OCSP RESPONSE----- (OCSP SHA256 of the DER is 36082255...) Now, with OpenSSL, I can verify that OCSP response just fine: $ openssl ocsp -respin ocsp.der -issuer root.crt -cert server.crt -text OCSP Request Data: Version: 1 (0x0) Requestor List: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: B731F8DC9366B6A1B427DAA84E53909FA28B9A71 Issuer Key Hash: 4D5DDB9D963896E0F16028FABD2A8F8E083329C6 Serial Number: 23486E2DCFC15E02A489D2BB0BCF0512 Request Extensions: OCSP Nonce: 0410E58C1C5EAE62DD5E2EDE854CF02EA157 OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: 4D5DDB9D963896E0F16028FABD2A8F8E083329C6 Produced At: Dec 12 12:09:27 2017 GMT Responses: Certificate ID: Hash Algorithm: sha1 Issuer Name Hash: B731F8DC9366B6A1B427DAA84E53909FA28B9A71 Issuer Key Hash: 4D5DDB9D963896E0F16028FABD2A8F8E083329C6 Serial Number: 23486E2DCFC15E02A489D2BB0BCF0512 Cert Status: good This Update: Dec 12 09:09:27 2017 GMT Next Update: Dec 26 12:09:27 2017 GMT Signature Algorithm: ecdsa-with-SHA256 30:44:02:20:36:49:84:78:83:2a:e8:61:eb:54:8d:ec:c0:e5: 9c:f0:25:9a:21:38:68:e6:b3:89:01:95:8c:37:17:3a:76:f8: 02:20:06:63:a1:d3:19:70:b7:aa:52:13:f0:d1:0f:6a:74:06: dc:04:8a:b7:69:6f:74:17:82:a8:ab:59:e3:8c:33:5b WARNING: no nonce in response Response verify OK server.crt: good This Update: Dec 12 09:09:27 2017 GMT Next Update: Dec 26 12:09:27 2017 GMT Also, the certificates look OK, at least OpenSSL thinks so: $ openssl verify -check_ss_sig -CAfile root.crt root.crt root.crt: OK $ openssl verify -CAfile root.crt server.crt server.crt: OK However: $ LD_LIBRARY_PATH="/home/joe/tmp/gnutls-3.6.1/lib/.libs" /home/joe/tmp/gnutls-3.6.1/src/.libs/gnutls-cli --port=9999 --x509cafile=/home/joe/.config/ratched/root.crt 127.0.0.1 Processed 1 CA certificate(s). Resolving '127.0.0.1:9999'... Connecting to '127.0.0.1:9999'... - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - subject `CN=127.0.0.1', issuer `OU=ratched,CN=Evil root certificate', serial 0x23486e2dcfc15e02a489d2bb0bcf0512, EC/ECDSA key 256 bits, signed using ECDSA-SHA256, activated `2017-12-11 12:09:27 UTC', expires `2018-12-12 12:09:27 UTC', pin-sha256="a0SEAr7c1914pYZhUR9m1gvT+KMbx6/TY6gdWZ+JoXg=" Public Key ID: sha1:fcfa19101266ef624aa968f13b30641038d03e32 sha256:6b448402bedcd7dd78a58661511f66d60bd3f8a31bc7afd363a81d599f89a178 Public Key PIN: pin-sha256:a0SEAr7c1914pYZhUR9m1gvT+KMbx6/TY6gdWZ+JoXg= - Status: The certificate is NOT trusted. The received OCSP status response is invalid. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** handshake has failed: Error in the certificate. With more debugging: |<4>| HSK[0x55a19fda5a00]: CERTIFICATE STATUS (22) was received. Length 283[283], frag offset 0, frag length: 283, sequence: 0 - Certificate type: X.509 - Got a certificate list of 1 certificates. - Certificate[0] info: - subject `CN=127.0.0.1', issuer `OU=ratched,CN=Evil root certificate', serial 0x23486e2dcfc15e02a489d2bb0bcf0512, EC/ECDSA key 256 bits, signed using ECDSA-SHA256, activated `2017-12-11 12:09:27 UTC', expires `2018-12-12 12:09:27 UTC', pin-sha256="a0SEAr7c1914pYZhUR9m1gvT+KMbx6/TY6gdWZ+JoXg=" Public Key ID: sha1:fcfa19101266ef624aa968f13b30641038d03e32 sha256:6b448402bedcd7dd78a58661511f66d60bd3f8a31bc7afd363a81d599f89a178 Public Key PIN: pin-sha256:a0SEAr7c1914pYZhUR9m1gvT+KMbx6/TY6gdWZ+JoXg= |<3>| ASSERT: common.c[_gnutls_x509_get_raw_field2]:1558 |<3>| ASSERT: ocsp.c[find_signercert]:1913 |<3>| ASSERT: common.c[_gnutls_x509_der_encode]:864 |<3>| ASSERT: ocsp.c[find_signercert]:2008 |<3>| ASSERT: common.c[_gnutls_x509_get_raw_field2]:1558 |<3>| ASSERT: ocsp.c[gnutls_ocsp_resp_verify]:2269 |<3>| ASSERT: x509.c[check_ocsp_response]:153 |<3>| ASSERT: name_constraints.c[gnutls_x509_crt_get_name_constraints]:470 - Status: The certificate is NOT trusted. The received OCSP status response is invalid. *** PKI verification of server certificate failed... |<3>| ASSERT: handshake.c[run_verify_callback]:2345 |<3>| ASSERT: handshake.c[handshake_client]:2441 *** Fatal error: Error in the certificate. |<5>| REC: Sending Alert[2|42] - Certificate is bad |<5>| REC[0x55a19fda5a00]: Preparing Packet Alert(21) with length: 2 and min pad: 0 |<9>| ENC[0x55a19fda5a00]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 |<5>| REC[0x55a19fda5a00]: Sent Packet[2] Alert(21) in epoch 0 and length: 7 *** handshake has failed: Error in the certificate. However, ocsptool says: $ ocsptool --load-signer=root.crt -e References: Message-ID: <1513147606.2340.3.camel@gmail.com> On Tue, 2017-12-12 at 13:21 +0100, Johannes Bauer wrote: > Hi list, > > I'm currently writing some software for pentesting. It includes an > OCSP > and TLS server that both are based on OpenSSL. With Ubuntu 17.04, I > added some integration tests that featured the gnutls-cli TLS client. > Yesterday I updated to Ubuntu 17.10 and now the gnutls tests are > broken; > gnuTLS rejects the OCSP responses from my server as invalid. > > Let me stress that it is *very* possible that the fault is not > gnuTLS, > but my software. However, OpenSSL doesn't show any issue with the > OCSP > response and from the error message I'm getting from gnuTLS I find > myself unable to debug the root cause of this issue. Here's the > certificates first: [...] > With more debugging: > > <4>| HSK[0x55a19fda5a00]: CERTIFICATE STATUS (22) was received. > > Length > > 283[283], frag offset 0, frag length: 283, sequence: 0 > - Certificate type: X.509 > - Got a certificate list of 1 certificates. > - Certificate[0] info: > ?- subject `CN=127.0.0.1', issuer `OU=ratched,CN=Evil root > certificate', > serial 0x23486e2dcfc15e02a489d2bb0bcf0512, EC/ECDSA key 256 bits, > signed > using ECDSA-SHA256, activated `2017-12-11 12:09:27 UTC', expires > `2018-12-12 12:09:27 UTC', > pin-sha256="a0SEAr7c1914pYZhUR9m1gvT+KMbx6/TY6gdWZ+JoXg=" > Public Key ID: > sha1:fcfa19101266ef624aa968f13b30641038d03e32 > sha256:6b448402bedcd7dd78a58661511f66d60bd3f8a31bc7afd3 > 63a81d599f89a178 > Public Key PIN: > pin-sha256:a0SEAr7c1914pYZhUR9m1gvT+KMbx6/TY6gdWZ+JoXg= > > > <3>| ASSERT: common.c[_gnutls_x509_get_raw_field2]:1558 > > <3>| ASSERT: ocsp.c[find_signercert]:1913 > > <3>| ASSERT: common.c[_gnutls_x509_der_encode]:864 > > <3>| ASSERT: ocsp.c[find_signercert]:2008 > > <3>| ASSERT: common.c[_gnutls_x509_get_raw_field2]:1558 > > <3>| ASSERT: ocsp.c[gnutls_ocsp_resp_verify]:2269 > > <3>| ASSERT: x509.c[check_ocsp_response]:153 > > <3>| ASSERT: > > name_constraints.c[gnutls_x509_crt_get_name_constraints]:470 > > - Status: The certificate is NOT trusted. The received OCSP status > response is invalid. What I can see from the code involved in the asserts above is that the signer of the OCSP response cannot be found either in the chain sent by the server, or in the trusted store. The message "Got a certificate list of 1 certificates" further suggests that the server didn't include root.crt in its chain. Is that correct? regards, Nikos From dfnsonfsduifb at gmx.de Wed Dec 13 11:38:43 2017 From: dfnsonfsduifb at gmx.de (Johannes Bauer) Date: Wed, 13 Dec 2017 11:38:43 +0100 Subject: [gnutls-help] Problem with OCSP status in gnutls-cli In-Reply-To: <1513147606.2340.3.camel@gmail.com> References: <1513147606.2340.3.camel@gmail.com> Message-ID: <873b829f-e05f-e539-3275-c55e2b0f1416@gmx.de> Hi Nikos, On 13.12.2017 07:46, Nikos Mavrogiannopoulos wrote: >> - Status: The certificate is NOT trusted. The received OCSP status >> response is invalid. > > What I can see from the code involved in the asserts above is that the > signer of the OCSP response cannot be found either in the chain sent by > the server, or in the trusted store. > > The message "Got a certificate list of 1 certificates" further suggests > that the server didn't include root.crt in its chain. Is that correct? That is correct. The server only sends its server certificate, which is directly signed by the self-signed root CA certificate. The certificate that I pass to to gnutls-cli is that exact root certificate. So IMHO, gnuTLS should have all the required trust prerequisites to validate the certificate, shouldn't it? I will now also try to make the server send the root CA cert as well in its response and see if that changes the behavior. Thanks for your assistance, Kind regards, Joe From dfnsonfsduifb at gmx.de Wed Dec 13 12:07:46 2017 From: dfnsonfsduifb at gmx.de (Johannes Bauer) Date: Wed, 13 Dec 2017 12:07:46 +0100 Subject: [gnutls-help] Problem with OCSP status in gnutls-cli In-Reply-To: <873b829f-e05f-e539-3275-c55e2b0f1416@gmx.de> References: <1513147606.2340.3.camel@gmail.com> <873b829f-e05f-e539-3275-c55e2b0f1416@gmx.de> Message-ID: Hi again, Nikos, On 13.12.2017 11:38, Johannes Bauer wrote: > The certificate that I pass to to gnutls-cli is that exact root > certificate. So IMHO, gnuTLS should have all the required trust > prerequisites to validate the certificate, shouldn't it? I will now also > try to make the server send the root CA cert as well in its response and > see if that changes the behavior. Indeed it does! When the server includes its root of trust in the CA certificate chain send to the client, the gnuTLS client accepts the OCSP ticket as valid, even thoght the client already has access to that certificate via its trust store. So, for now, this works as a workaround for me -- but I do think that is unintended behavior on gnuTLS' side, isn't it? Thanks for helping me with this, Kind regards, Johannes From n.mavrogiannopoulos at gmail.com Wed Dec 13 12:46:31 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 13 Dec 2017 12:46:31 +0100 Subject: [gnutls-help] Problem with OCSP status in gnutls-cli In-Reply-To: References: <1513147606.2340.3.camel@gmail.com> <873b829f-e05f-e539-3275-c55e2b0f1416@gmx.de> Message-ID: On Wed, Dec 13, 2017 at 12:07 PM, Johannes Bauer wrote: > Hi again, Nikos, > > On 13.12.2017 11:38, Johannes Bauer wrote: > >> The certificate that I pass to to gnutls-cli is that exact root >> certificate. So IMHO, gnuTLS should have all the required trust >> prerequisites to validate the certificate, shouldn't it? I will now also >> try to make the server send the root CA cert as well in its response and >> see if that changes the behavior. > > Indeed it does! > > When the server includes its root of trust in the CA certificate chain > send to the client, the gnuTLS client accepts the OCSP ticket as valid, > even thoght the client already has access to that certificate via its > trust store. > So, for now, this works as a workaround for me -- but I do think that is > unintended behavior on gnuTLS' side, isn't it? I'm not sure. There is already a test for that (see tests/ocsp-tests/ocsp-tls-connection) and gnutls-cli seems to be able to connect. Could you help me by providing a reproducer to the issue? There may be something special in the certificates that you are using that are preventing the lookup of the OCSP response's CA. regards, Nikos From dfnsonfsduifb at gmx.de Wed Dec 13 13:26:26 2017 From: dfnsonfsduifb at gmx.de (Johannes Bauer) Date: Wed, 13 Dec 2017 13:26:26 +0100 Subject: [gnutls-help] Problem with OCSP status in gnutls-cli In-Reply-To: References: <1513147606.2340.3.camel@gmail.com> <873b829f-e05f-e539-3275-c55e2b0f1416@gmx.de> Message-ID: <5809fc47-8cd6-e563-68a0-f452693ab473@gmx.de> Hi Nikos, On 13.12.2017 12:46, Nikos Mavrogiannopoulos wrote: >> So, for now, this works as a workaround for me -- but I do think that is >> unintended behavior on gnuTLS' side, isn't it? > > I'm not sure. There is already a test for that (see > tests/ocsp-tests/ocsp-tls-connection) and gnutls-cli seems to be able > to connect. Could you help me by providing a reproducer to the issue? Sure thing! I've created a blob, ocsp_reproducer.tar.gz (attached at bottom), that contains all certificates and an OCSP response which I crafted to be valid for a year. It relies on OpenSSL (possibly 1.1, don't know when the -status_file option was added). Here's how it works: $ ./start_server [...] ~~~~~~~~~ NOT serving the status request ~~~~~~~~~ Using default temp DH parameters ACCEPT and then, in a separate terminal $ ./connect_client [...] - Handshake was completed But give "start_server" any argument and it'll serve OCSP: $ ./start_server x [...] ~~~~~~~~~ Serving OCSP status request ~~~~~~~~~ Using default temp DH parameters ACCEPT and then $ ./connect_client [...] - Status: The certificate is NOT trusted. The received OCSP status response is invalid. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** handshake has failed: Error in the certificate. Let me know if there's anything else I can contribute. Thanks for looking into this! Kind regards, Johannes ocsp_reproducer.tar.gz: ------- BEGIN BASE64 ------- H4sIAGcaMVoAA+1ZW4gjWRnunps7BeqKwyLCQG3PwOqGTE7dclEaPCdVSVWnq5Kq VCWpyG5vUqlUbl2VVCWpVLzOgD4oq4KwoLLuuAou7Jsuig/6qIKwDwou6ML6oi+C IL4sCuJJ+jb2XNqVnh5l8xXhVP78p/7zn//85/9OxbOC4Y5vD32vNbFsP7H2EAAw UgAsWirF/Vt7gDWKoSmWpjiKTa4BimY4bo3kHsZgjmMSjBs+Sa71PPuBeif9/n8K 71j8F99vtGz/NG0sApx8QPxZ5jD+LEtzOP4soJg1EpzmIO6Hd3n8wa31K8T62u1b 6+/Ft5cvXY5dWr948T1gff3CzX+Am2+Dm99++YkLV+Rnfv/iC+kX/vDX5z7y958+ /dWvPMZ89Ocfej+N40jRFIM/NODqIAAjIIHLly7G3nf+3Icvrl248mPq7Te/3v7R d1576nevKOWvvfTyl785uvfTzj1uffCN3xhPSJ9+Vnzjrb9d87c+v3ZkAWSWFm5/ YClK32mUuPTY018UX9+8cP7ceWkN5M49ufbqPx+fP/Wtt27/Jf/HL7zywi+uirf+ /NLnLprpH37v+U/87PqzFlb59ff71de+Yd1809p88Usfu/rL7/721cTrV9o/+RV8 7vmrf/J/8KjjclY4nv+W57q2Nd6xBl3bHZ+OjZP2fwon+8H+DzgK5z9HJ8Eq/88C 155MNLtuotkIOmTcJq7hi3DcyXgQxPESIOPxGQcyVqPdHdibvueNb1j+GEuHHm4y 6VSSpOjUDYAvinjUrqzwX+B4/ge2P7X9G307Oj0bJ9V/Jkkd1n8O7wW4/jMpdpX/ Z4H4AkjISwpZ0qQK1AWyIJhLKSFLeRE6ApSRnEfRKF+W2Qz+ns9m9+9DQUR5EDZC CUFVdSSnYI+ctBHrDEGGVceE4c5cO6oX0lv2MMealLgbyyW2u8liNOpoUMlCWJa5 0E4IwE8YZjml8OFQrM8o1wRgmi86hGm2252SXpeHSiuXadGBwVQKlJlRmtt+aiil mOIsX/GtWYcf2eOgzNhqAjW9RoJYOiAo/N1OPeoJ/x/DXfmPs2G8s7cLnJaNk+p/ kmWPzn/L/OcAvcr/M8G96r83tN0gGJB4CXTbERm3OrbV3wmCnaDrkPEsXJAB8pAM HNzc1e244n5puVN1sfrIuG8Hw65LHhw9yXg3CCa4PeIbY3s2Johum/wkuXGd2iA3 N8mNDfKZj5Pjju0Sl22r45Ebnz0AqRT1pbWu6yw0SBzi8SQgfXs0sYMxeai4QdiD wL67f3m/bzFbLj2g82Wo5cubG/E9jZ2ltwdObBDt7qGbwX5CkfGGZdnDfeYUx/l2 56yQcVx1yaMCTF7/1MLAZx7qlnWf+o+Hc3o2Tqj/uNrTR+f/5PL8zwJ6lf9ngTvq f1bQdCknZXG5PKj/UlbsZbPQKjtwUeMdSTVnpRqgjGq5NrPLSrudjpSo3IMF5Dij Tr9XLKkqD3swkjU2JERo8hUs4FEl19odBJK4NW0yqmPSlaiVH+w2qkqnlTdmAg+L yFEqCAYyYrawTPHqVRU/oGMpsm7N5J4QybqEWxhVlzJnIZsfynpwV9akUDgwCPtY bk0IOcuG2z3hvhaqOtSRY+0PXUJHbsgIhUqWOIminMRQiPtRFI8VRVkSBRmGeUgZ LSEUUCJUszKEoahiNzRQRMgUiNy22OXyk1q9YxgB36j5dqwSCP3GtldMyCi97CyF qimjBswJVIvm6Gpxq+mkq9CL+WBE9FhWkiM3L8NgqcyHqoDDyY942FjMiagJgjCH muPsTdrenOVFJKYhhAKOQrgcThvPTpjrQcNDBUeQzGJD1IDFe9Ntuj5tRlyvSYOw 4JhSITQRUg0RqoIg9qBFyMjDpBFbV40cmkPUcTivJWphsZuemru5aHtXmTb1Y4vI USTIoxzsQobQ+7GEihw0Y1htWkqmzKGY604hbyYKFGqjfnJSM/jtMW2oUgcqsekY RYoj82mfdSdMBdSIdrpapuZ8E8iRXDO0qVdjWsCMgiOieNfqf9SZeTY4vv8va+6p nv7e6flv7/0vt3r/eyY4zfOfNjFKIQdFLTcvMozYIqJhwKS2BtEw6WQseqiZfmJe 79SSXS62f/7Tt/3GvDpKNvjOfBrk1HYoCIkqM3FBOSebxFzoWP3QSxW3tCpXGyiJ 0qjQEcc6FThDr8xqbU5uoLarF7v2rBpMQcxiFZDgmNX57z/FPfP/VNnfyfyPZu/4 /ye1n//cKv/PAifwPxQu+F9194D/aVCOVd1IGRaUnLhlFeu7GlXopowwu6j7Xl2a 98CCXISYndm47i+5DRaEFa1WHzazKGrSGSDllYHlasP67qBn1rSBrMGQd5bUbZuH rQjLeo18pY8fwNZ4XWCWPE8XZjIvAbniYZkUHZMtLR43SLxTi3KuHwqhKe67gvmf eugXD1WLVx0oREk6oEaTXYe1UilkiGmEStQ4NcwIHT0vz6TallwozrtGZVLhCL09 T3Y9LWVkmlKhIUyEWkzPOzUOzD03qPjbmZJb5FulWCuJGUuODfk9sqVDVUwgaIQE XBDDOWwtqZrKCjlHNfQK03TrJjuY8DMz20tOy6NSz3HmBcsM99lab8nWPGgQD1LO 7imX8P6NGVcec0TvcHtHUM5CYEFCFtSslEVTxTRgUxeyPVZrtkfJdL2lh5OISiPd heVqMl2me7zd7tGwi9iATZoymKHeOOUSHstPjISaMKtKg4kyXjHo2+0B32j688oE bm6+61nYCiussMIKK5wt/gX6QubAACgAAA== ------- END BASE64 len 2089 MD5 01ca145c6faa7ed52f6ef3abc95fb4fe ------- From n.mavrogiannopoulos at gmail.com Fri Dec 15 15:52:36 2017 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 15 Dec 2017 15:52:36 +0100 Subject: [gnutls-help] Problem with OCSP status in gnutls-cli In-Reply-To: <5809fc47-8cd6-e563-68a0-f452693ab473@gmx.de> References: <1513147606.2340.3.camel@gmail.com> <873b829f-e05f-e539-3275-c55e2b0f1416@gmx.de> <5809fc47-8cd6-e563-68a0-f452693ab473@gmx.de> Message-ID: On Wed, Dec 13, 2017 at 1:26 PM, Johannes Bauer wrote: > Hi Nikos, > > On 13.12.2017 12:46, Nikos Mavrogiannopoulos wrote: > >>> So, for now, this works as a workaround for me -- but I do think that is >>> unintended behavior on gnuTLS' side, isn't it? >> >> I'm not sure. There is already a test for that (see >> tests/ocsp-tests/ocsp-tls-connection) and gnutls-cli seems to be able >> to connect. Could you help me by providing a reproducer to the issue? > > Sure thing! I've created a blob, ocsp_reproducer.tar.gz (attached at > bottom), that contains all certificates and an OCSP response which I > crafted to be valid for a year. It relies on OpenSSL (possibly 1.1, > don't know when the -status_file option was added). Here's how it works: Thank you. I checked it further and it seems that openssl s_client doesn't seem to check/verify any OCSP responses given. That's why you see it working on that server. gnutls attempts OCSP verification with the following steps: 1. reads the included certificates in the OCSP response. [no such certs are included in that response] 2. If that fails, it extracts the DN of the OCSP signer and search the included trusted list based on DN. [no DN is included in the OCSP response; only a hash of the DN] 3. If all of the above fails, it will try to verify against the client's issuer certificate in the presented chain. [fails because the server chain doesn't include its issuer] Did you generate this OCSP response based on some rules which suggested to have it that way? I suspect it would be possible to extend the trust database searching (in gnutls and p11-kit as well) using SHA1 hash of fields, but that would not be a trivial change. regards, Nikos [0]. OCSP Response Information: Response Status: Successful Response Type: Basic OCSP Response Version: 1 Responder Key ID: 4d5ddb9d963896e0f16028fabd2a8f8e083329c6 Produced At: Wed Dec 13 12:12:05 UTC 2017 Responses: Certificate ID: Hash Algorithm: SHA1 Issuer Name Hash: b731f8dc9366b6a1b427daa84e53909fa28b9a71 Issuer Key Hash: 4d5ddb9d963896e0f16028fabd2a8f8e083329c6 Serial Number: 6313d7d35516497c5e48d7dff323724a Certificate Status: good This Update: Wed Dec 13 09:12:05 UTC 2017 Next Update: Thu Dec 13 12:12:05 UTC 2018 Extensions: From beeftacowithhotsauce at mail.ru Tue Dec 19 06:22:41 2017 From: beeftacowithhotsauce at mail.ru (=?UTF-8?B?QmVlZiBUYWNv?=) Date: Tue, 19 Dec 2017 08:22:41 +0300 Subject: [gnutls-help] =?utf-8?q?Linking_a_static_gnutls_with_nettle_in_th?= =?utf-8?q?e_application=2E?= Message-ID: <1513660961.252226004@f409.i.mail.ru> Hello. I'm making a project that uses gnutls as a dependency ( to libvncclient library ) on Debian 9 amd64. I have build the 3.6.1 version with the following configuration: ./configure --prefix=/usr --without-p11-kit --enable-static --enable-shared --with inclided-unistring After that i ended up with the static version, which i linked to my project along with the nettle 3.4 build statically myself. But when i try to build my application, i get errors like this: https://pastebin.com/DWkNpgFY ? My linker options are arranged like this: -L/home/user/Documents/git_stuff/libvncserver/build -L/usr/lib/x86_64-linux-gnu -lvncclient -lgcrypt -lz -ljpeg -lpng -lcrypto -lssl -lgnutls -lnettle -lgmp -lgpg-error -ltasn1 -pthread -static Judging by errors like this: /home/user/Documents/git_stuff/gnutls/lib/nettle/mpi.c:138: undefined reference to `nettle_mpz_set_str_256_s' I have assumed, there is a dependency on a specific earloer version of libnettle? Or how to fix this erros? -- Beef Taco -------------- next part -------------- An HTML attachment was scrubbed... URL: