Re: [squid-users] (92) Protocol error (TLS code: X509_V_ERR_CERT_HAS_EXPIRED)
On 6/23/20 11:04 AM, Andrea Venturoli wrote: > Running Squid 4.11 on FreeBSD 11.3 with SSLBump, since a few days, I've > got several sites (e.g. https://www.kawsaki.it/) failing with: > >> The following error was encountered while trying to retrieve the URL: >> https://www.kawasaki.it/* >> >> Failed to establish a secure connection to 54.39.161.167 >> >> The system returned: >> >> (92) Protocol error (TLS code: X509_V_ERR_CERT_HAS_EXPIRED) >> >> SSL Certificate expired on: May 30 10:48:38 2020 GMT > When this happens, in cache.log I see: >> 2020/06/23 15:03:31 kid1| ERROR: negotiating TLS on FD 33: >> error:14090086:SSL routines:ssl3_get_server_certificate:certificate >> verify failed (1/-1/0) > I know an intermediate certificate expired, but a new one should have > been published. > Does Squid perform something different from OpenSSL? Yes, Squid has custom TLS-related code, including certificate validation, generation, and fetching code. > Does it have some certificate cache Yes, there can be two or even four caches in play here: 1. The in-RAM cache of generated fake certificates (see dynamic_cert_mem_cache_size), 2. on-disk cache of generated fake certificates (see sslcrtd_program), 3. a regular HTTP in-RAM cache (see cache_mem) that may keep a copy of the intermediate certificate downloaded by Squid. 4. a regular HTTP on-disk cache (see cache_dir) that may keep a copy of the intermediate certificate downloaded by Squid. > I should clear? *If* Squid is caching an expired certificate without revalidation, then this is essentially a Squid bug. There are many unknowns here, so I cannot confirm or deny the existence of such a bug without spending more free time which I do not have (unfortunately). I also do not know (did not check) whether Squid is caching the expired fake certificate and/or the real intermediate one. You can try to fix the problem or workaround the Squid bug by clearing the caches. > How? I would begin with a full Squid shutdown and start. This will clear all in-RAM caches. If the problem persists, you can remove the entire on-disk certificate generator cache (or extract the bad certificates from it, but that requires even more work). See sslcrtd_program for more info on that cache location. Do not forget to re-initialize it! If the problem persists, you can remove the entire on-disk HTTP cache (or extract the bad certificates from it, but that requires even more work). See cache_dir for more info on that cache location. Do not forget to re-initialize it! I cannot give you step-by-step instructions, but others on the list may pitch in as you make progress in your triage using the above hints. HTH, Alex. ___ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
[squid-users] (92) Protocol error (TLS code: X509_V_ERR_CERT_HAS_EXPIRED)
Hello. Running Squid 4.11 on FreeBSD 11.3 with SSLBump, since a few days, I've got several sites (e.g. https://www.kawsaki.it/) failing with: The following error was encountered while trying to retrieve the URL: https://www.kawasaki.it/* Failed to establish a secure connection to 54.39.161.167 The system returned: (92) Protocol error (TLS code: X509_V_ERR_CERT_HAS_EXPIRED) SSL Certificate expired on: May 30 10:48:38 2020 GMT This proxy and the remote host failed to negotiate a mutually acceptable security settings for handling your request. It is possible that the remote host does not support secure connections, or the proxy is not satisfied with the host security credentials. When this happens, in cache.log I see: 2020/06/23 15:03:31 kid1| ERROR: negotiating TLS on FD 33: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (1/-1/0) 2020/06/23 15:03:31 kid1| ERROR: negotiating TLS on FD 33: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (1/-1/0) 2020/06/23 15:03:31 kid1| ERROR: negotiating TLS on FD 53: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (1/-1/0) I know an intermediate certificate expired, but a new one should have been published. What I find strange, is that using openssl directly succeeds: # openssl s_client -connect www.kawasaki.it:https CONNECTED(0003) depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert CN RSA CA G1 verify return:1 depth=0 C = CN, ST = \E7\A6\8F\E5\BB\BA\E7\9C\81, L = \E5\8E\A6\E9\97\A8\E5\B8\82, O = \E7\BD\91\E5\AE\BF\E7\A7\91\E6\8A\80\E8\82\A1\E4\BB\BD\E6\9C\89\E9\99\90\E5\85\AC\E5\8F\B8\E5\8E\A6\E9\97\A8\E5\88\86\E5\85\AC\E5\8F\B8, OU = IT, CN = webssl.chinanetcenter.com verify return:1 --- Certificate chain 0 s:/C=CN/ST=\xE7\xA6\x8F\xE5\xBB\xBA\xE7\x9C\x81/L=\xE5\x8E\xA6\xE9\x97\xA8\xE5\xB8\x82/O=\xE7\xBD\x91\xE5\xAE\xBF\xE7\xA7\x91\xE6\x8A\x80\xE8\x82\xA1\xE4\xBB\xBD\xE6\x9C\x89\xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8\xE5\x8E\xA6\xE9\x97\xA8\xE5\x88\x86\xE5\x85\xAC\xE5\x8F\xB8/OU=IT/CN=webssl.chinanetcenter.com i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert CN RSA CA G1 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert CN RSA CA G1 i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA --- Server certificate -BEGIN CERTIFICATE- MIIWEDCCFPigAwIBAgIQA1RHNwOepXqwyoBuZiYbQTANBgkqhkiG9w0BAQsFADBf MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMR4wHAYDVQQDExVEaWdpQ2VydCBDTiBSU0EgQ0EgRzEw HhcNMjAwNjE5MDAwMDAwWhcNMjAxMTA5MTIwMDAwWjCBnjELMAkGA1UEBhMCQ04x EjAQBgNVBAgMCeemj+W7uuecgTESMBAGA1UEBwwJ5Y6m6Zeo5biCMTYwNAYDVQQK DC3nvZHlrr/np5HmioDogqHku73mnInpmZDlhazlj7jljqbpl6jliIblhazlj7gx CzAJBgNVBAsTAklUMSIwIAYDVQQDExl3ZWJzc2wuY2hpbmFuZXRjZW50ZXIuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA11rUTXwosZacGiiTO6+o Qhm7qZzl8T5fGeNwXsZw/EGtCcySXD8pQ33+IpMdXq8hi5EaBXeHCpUs4UCg4S1S WXlfGr3PbP+SwLRiXGGNPOPYywLX8N0SyDy1VOkrMHHDRscbf1x6pSJpSTRkNqXS 7+/zFTP26fDpvVlgG3U9VpAf7jpCg+xO2ppCbEyKEd02DGNSzSC0vmBJnsg/vI+j E8kpiDLjBXAIl5nSns6rChXgxH9/BO60Vef+R3lA5EMVUp31CzhkvjNrk9pcSVbw 6AVKlEU314G5diBe/ju0Vie/rnUHXb9FIIHN8+XiNhLBGK2TrgpYvba7gC+wkvVu ZwIDAQABo4IShjCCEoIwHwYDVR0jBBgwFoAU70ULeBWRpbbRc6SSb2NaWdNfPp0w HQYDVR0OBBYEFGdOsyhZD+/HmDtCHqpecLdpZvYeMIIPwgYDVR0RBIIPuTCCD7WC CiouY2N0di5jb22CCSouMTYzLmNvbYIPKi5jaGluYWxpdmUuY29tgg0qLmNjdHZw aWMuY29tggwqLmlzZWV5b28uY26CECouMjAxMGV4cG90di5jb22CCSouY2N0di5j boIMKi5zYW1sY3IuY29tggoqLnN5eXguY29tgg8qLnpodW9xdWFwcC5jb22CDSou NTA1NDM5OS5jb22CDyouYWl3YW40Mzk5LmNvbYIKKi4zODM5LmNvbYIJKi40Mzk5 LmNugggqLjU2LmNvbYIJKi5jbnR2LmNugg4qLml3YW40Mzk5LmNvbYIOKi5saXZl Y2hpbmEuY26CDyoubGl2ZWNoaW5hLmNvbYIQKi5taXRhZ3Rlbm5pLm5ldIIOKi5v dXJkdnNzcy5jb22CDSouZGViZW5jZS5uZXSCDSouMzgzOWFwcC5jb22CDSouZGF5 amF1eS5uZXSCDSouYm13Z3JvdXAuY26CDCouZm94aWpuLmNvbYIPKi5jaGlkYXJl c3MuY29tgg4qLmNvdmluaXlhLmNvbYINKi5pbWc0Mzk5LmNvbYIKKi4xMjM3MS5j boIMKi5pcGFuZGEubmV0ggwzMDAwdGVzdC5jb22CCyouaTM4MzkuY29tggsqLmlw MTM4LmNvbYIJaXAxMzguY29tggwqLnpoZTgwMC5jb22CDSoudnhpbnlvdS5jb22C DCouNDM5OWtlLmNvbYIKKi4zMDAwLmNvbYIQKi40Mzk5eW91cGFpLmNvbYIMKi55 eGhoZGwuY29tgg0qLjMwMDBhcGkuY29tgg4qLmt1eWlueXVuLmNvbYIOKi5rdXlp bjEyMy5jb22CDCouZGl5cmluZy5jY4IOKi4zMDAwdGVzdC5jb22CDCoubWVpcGFp LmNvbYISKi5jYW5rYW94aWFveGkuY29tggsqLmNudHZ3Yi5jboIQKi5pYW5ub25l a3RtLm5ldIIMKi5pcGFuZGEuY29tggsqLmlwYW5kYS5jboINKi40Mzk5YXBpLm5l dIINKi51bmNjb2RvLmNvbYIPKi5tZWl0dWRhdGEuY29tggsqLm1laXR1LmNvbYIK Ki40Mzk5LmNvbYIPKi5uZXdzLmNjdHYuY29tghEqLm5ld2VyYS5jY3R2LmNvbYIS Ki5vcGVuY2xhLmNjdHYuY29tghYqLm5ld3Njb250ZW50LmNjdHYuY29tgg4qLm5u bi5jY3R2LmNvbYIOKi5uZXdzLmNudHYuY26CDyoubGl2ZS5jY3R2LmNvbYIUKi5u ZXdjb21tZW50LmNudHYuY26CESouaXR2LmNjdHZwaWMuY29tgg0qLmltZy5jbnR2 LmNughMqLmltZy5saXZlY2hpbmEuY29tgg8qLmlwYW5kYS5jb20uY26CDiouaXBy LmNjdHYuY29tgg0qLmlwci5jbnR2LmNughAqLmlzaG93LmNjdHYuY29tgg4qLml0
