# Unable to verify certificate **URL:** \ **Category:** Help\ **Created:** [September 27, 2021, 5:28pm UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616 "2021-09-27T17:28:05Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![jeffd](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jeffd/32/8305_2.png) [@jeffd](https://community.letsencrypt.org/u/jeffd)\ **Post date:** [September 27, 2021, 5:28pm UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/1 "2021-09-27T17:28:05Z")
I am having the same issue on 20.04. After reading this thread, i'm going to put in my responses to your questions to andyrue. If I should open another issue, since its a different OS, that is fine. I found this when i was updating `ocsp` files, and ended up getting it down the first command below. Before you get to the nitty gritty, thanks in advance! `$> openssl verify -CAfile /etc/letsencrypt/live/ukybonds.com/chain.pem /etc/letsencrypt/live/ukybonds.com/cert.pem` Results in: ```nohighlight C = US, O = Internet Security Research Group, CN = ISRG Root X1 error 2 at 2 depth lookup: unable to get issuer certificate error /etc/letsencrypt/live/ukybonds.com/cert.pem: verification failed ``` I _am_ able to run `wget https://letsencrypt.org/certs/isrgrootx1.pem` fine. ```nohighlight $> sudo apt install libgnutls30 Reading package lists... Done Building dependency tree Reading state information... Done libgnutls30 is already the newest version (3.6.13-2ubuntu1.6). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. ``` ```nohighlight $> sudo apt install libgnutls-openssl27 Reading package lists... Done Building dependency tree Reading state information... Done libgnutls-openssl27 is already the newest version (3.6.13-2ubuntu1.6). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. ``` `$> ls -l /usr/local/share/ca-certificates/` -- Empty directory ```nohighlight $> ls -l /etc/ssl/certs/ca-certificates.crt -rw-r--r-- 1 root root 199113 Sep 27 17:12 /etc/ssl/certs/ca-certificates.crt ``` If i use `openssl s_client` to read the live certs it works fine, and says that each level is valid `$> openssl s_client -connect www.ukybonds.com:443 -showcerts | openssl x509` ```nohighlight verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = ukybonds.com verify return:1 -- certificate omitted for space -- ``` ---
**Author:** ![jeffd](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jeffd/32/8305_2.png) [@jeffd](https://community.letsencrypt.org/u/jeffd)\ **Post date:** [September 27, 2021, 5:47pm UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/2 "2021-09-27T17:47:18Z")
Thanks @rg305 ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [September 27, 2021, 5:47pm UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/3 "2021-09-27T17:47:42Z")
I think there may be a problem with the way you tried to verify the cert. I'm able to reach your site with `curl` and `wget` without issue. ---
**Author:** ![jeffd](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jeffd/32/8305_2.png) [@jeffd](https://community.letsencrypt.org/u/jeffd)\ **Post date:** [September 27, 2021, 5:53pm UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/4 "2021-09-27T17:53:34Z")
The site works perfectly fine, but i can not generate ocsp files, for HAProxy b/c the local cert itself won't validate with `openssl verify` using the two files you recommended in the split question. Is there something wrong with my first command? `$> sudo openssl verify -CAfile /etc/letsencrypt/live/ukybonds.com/chain.pem /etc/letsencrypt/live/ukybonds.com/cert.pem`? Oh and this happens with all my LE certs, about 140 Certbot is 1.19.0 ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [September 27, 2021, 5:56pm UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/5 "2021-09-27T17:56:40Z")
Please show: > [@jeffd](#): > > `/etc/letsencrypt/live/ukybonds.com/chain.pem` [so others too can troubleshoot this issue] ---
**Author:** ![jeffd](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jeffd/32/8305_2.png) [@jeffd](https://community.letsencrypt.org/u/jeffd)\ **Post date:** [September 27, 2021, 5:57pm UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/6 "2021-09-27T17:57:53Z")
Contents of `/etc/letsencrypt/live/ukybonds.com/chain.pem` ```nohighlight -----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----- -----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----- ``` ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [September 27, 2021, 7:41pm UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/7 "2021-09-27T19:41:15Z")
Not sure what to make of this (from an Ubuntu 14 with OpenSSL 1.0.1f): [it should have failed?] ```nohighlight curl -I https://www.ukybonds.com/ HTTP/1.1 301 Moved Permanently server: nginx date: Mon, 27 Sep 2021 19:36:44 GMT content-length: 0 keep-alive: timeout=120 location: https://www.ukybonds.com/university-of-kentucky-bonds-ky/i2095 set-cookie: BONDLINK=eyJhbGciOiJIUzI1NiJ9.eyJkYXRhIjp7Im1vZCI6IjE2MzI3NzE0MDQiLCJjc3JmVG9rZW4iOiJkOTlmYzA2NTNlZjUwYzFkNWQwMGU4YmE2YmFiZjQyYmEzNDBkODY3NTA3MWE0NmU3YzE0N2U3YmQwZWE4OTA3LTE2MzI3NzE0MDQ1OTUtZjk5OGQxOGRkNzkyZGI3NTdhYjVmMDg0NDYzNmZkMGQ5NGQ5ZWRhMiJ9LCJleHAiOjE2NjQzMDc0MDQsIm5iZiI6MTYzMjc3MTQwNCwiaWF0IjoxNjMyNzcxNDA0fQ.67vr6FBRfJY5lcafKw-9-NIPnWqjwKwc7BfwY1drsGY; Max-Age=31536000; Expires=Tue, 27 Sep 2022 19:36:44 GMT; SameSite=None; Path=/; Secure; HTTPOnly server-timing: tst;dur=12;desc="Total Server Time" p3p: CP="BondLink does not have a P3P Policy" strict-transport-security: max-age=31536000; includeSubDomains; preload feature-policy: accelerometer 'none';camera 'none';encrypted-media 'none';geolocation 'none';gyroscope 'none';magnetometer 'none';microphone 'none';midi 'none';usb 'none' ``` ```nohighlight wget https://www.ukybonds.com/ --2021-09-27 15:36:55-- https://www.ukybonds.com/ Resolving www.ukybonds.com (www.ukybonds.com)... 52.55.173.69 Connecting to www.ukybonds.com (www.ukybonds.com)|52.55.173.69|:443... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://www.ukybonds.com/university-of-kentucky-bonds-ky/i2095 [following] --2021-09-27 15:37:00-- https://www.ukybonds.com/university-of-kentucky-bonds-ky/i2095 Reusing existing connection to www.ukybonds.com:443. HTTP request sent, awaiting response... 200 OK Length: 94489 (92K) [text/html] Saving to: ‘index.html’ 100%[==============================================================================>] 94,489 291KB/s in 0.3s 2021-09-27 15:37:01 (291 KB/s) - ‘index.html’ saved [94489/94489] ``` ```nohighlight openssl version OpenSSL 1.0.1f 6 Jan 2014 ``` ```nohighlight openssl s_client -connect ukybonds.com:443 -servername ukybonds.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=ukybonds.com i:/C=US/O=Let's Encrypt/CN=R3 1 s:/C=US/O=Let's Encrypt/CN=R3 i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 --- ``` ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [September 27, 2021, 8:06pm UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/8 "2021-09-27T20:06:30Z")
Maybe curl and wget linked against GnuTLS? ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [September 27, 2021, 8:42pm UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/9 "2021-09-27T20:42:33Z")
Ubuntu 14 should have an outdated GnuTLS as well. ---
**Author:** ![jeffd](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jeffd/32/8305_2.png) [@jeffd](https://community.letsencrypt.org/u/jeffd)\ **Post date:** [September 27, 2021, 9:04pm UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/10 "2021-09-27T21:04:55Z")
Just a SO question, but seems to align with exactly what you are seeing, only tls \>= 1.1 is allowed to connect to this server. [linux - Unable to establish SSL connection upon wget on Ubuntu 14.04 LTS - Stack Overflow](https://stackoverflow.com/questions/28757232/unable-to-establish-ssl-connection-upon-wget-on-ubuntu-14-04-lts) ```nohighlight Another variable is that the www.website.com uses TLS 1.0. I don't have an idea how this affects wget. But if I wget an image from TLS 1.2 websites I don't get any ssl connection errors from both test cases. ``` Still fairly confused, but just looking for common issues. ---
**Author:** ![jeffd](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jeffd/32/8305_2.png) [@jeffd](https://community.letsencrypt.org/u/jeffd)\ **Post date:** [September 28, 2021, 9:35pm UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/11 "2021-09-28T21:35:41Z")
A big thing that has been bothering me is this just started, it was noticed during OCSP updates and never impact the running server, in this case haproxy. This only started about two weeks ago (i was on vacation). I ran an `openssl verify` against certificates created in February, months before the problem, and those certs fail as well. Which makes little sense, as my openssl version `OpenSSL 1.1.1f 31 Mar 2020`. Yet has not failed until recently. I would love to hear from anyone that has a recent cert update/creation, on 20.04 and the same openssl version, does it succeed or fail. There are more tests that i want to do, but i'm having a hard time accepting that this is an LE issue. ---
**Author:** ![jeffd](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jeffd/32/8305_2.png) [@jeffd](https://community.letsencrypt.org/u/jeffd)\ **Post date:** [September 28, 2021, 9:47pm UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/12 "2021-09-28T21:47:17Z")
To add a bit more, my haproxy configuration shows the following for `openssl` ```nohighlight Built with OpenSSL version : OpenSSL 1.1.1 11 Sep 2018 Running on OpenSSL version : OpenSSL 1.1.1f 31 Mar 2020 ``` which should mean the online verify should be using the same as `openssl verify`. This is production, so i'm not changing anything, but may spin up a new one. ---
**Author:** ![jeffd](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jeffd/32/8305_2.png) [@jeffd](https://community.letsencrypt.org/u/jeffd)\ **Post date:** [October 5, 2021, 12:32am UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/13 "2021-10-05T00:32:32Z")
So i have/had doubts, but since this failed at the same time that the LE deprecated certs hit the market. All of my certs have the correct root (as you can see from both our outputs), but clearly something else is amiss. I'd like to see this kept open. Also spun up a new instance of a webserver and used fresh install of certbot two days ago, and they will not validate for the same reason. @Osiris @rg305 ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [October 5, 2021, 2:57am UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/14 "2021-10-05T02:57:22Z")
@jeffd Have you tried reissuing a cert with the shorter preferred trust path chain? ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [October 5, 2021, 3:50am UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/15 "2021-10-05T03:50:43Z")
> [@rg305](#): > > Not sure what to make of this (from an Ubuntu 14 with OpenSSL 1.0.1f): > [it should have failed?] I think that proves that curl does not use the openssl `verify` function and must do its own validation. The problem with the older openssl verify was just the way openssl walked the chain during verify. Nothing to do with the trust store itself. I did the same test as you just now and my `curl -I https://community.letsencrypt.org` (long chain) worked without error even though this: ```nohighlight curl -V **curl 7.76.1** (x86_64-koji-linux-gnu) libcurl/7.76.1 **OpenSSL/1.0.2k-fips** zlib/1.2.7 libidn2/2.3.0 libssh2/1.4.3 nghttp2/1.41.0 Release-Date: 2021-04-14 Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB SPNEGO SSL UnixSockets ``` and ```nohighlight openssl version OpenSSL **1.0.2k-fips** 26 Jan 2017 ``` The openssl verify shows cert expired unless I use the `-trusted_first` option. What do you think? ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [October 5, 2021, 3:56am UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/16 "2021-10-05T03:56:24Z")
> [@MikeMcQ](#): > > What do you think? I think `openssl verify` does things in a very "_all things must be perfect_" approach; And we are intentionally inserting an expired root (to serve old Androids), so things are NOT perfect and it fails. Anything that relies on similar "_logic_" will also fail. ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [October 5, 2021, 3:57am UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/17 "2021-10-05T03:57:31Z")
Agreed. But your post made it seem like you thought the curl's would fail. But they did not. Perhaps I misunderstood. ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [October 5, 2021, 3:59am UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/18 "2021-10-05T03:59:45Z")
I had expected them to fail - yes - It's Ubuntu 14 ! ! ! ---
**Author:** ![jeffd](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jeffd/32/8305_2.png) [@jeffd](https://community.letsencrypt.org/u/jeffd)\ **Post date:** [October 5, 2021, 3:23pm UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/19 "2021-10-05T15:23:33Z")
> [@rg305](#): > > Have you tried reissuing a cert with the shorter preferred trust path chain? Thanks for the reply but, I'm not sure exactly what you mean. I've been obtaining certs like this for over 5 years, let me know if i should change something. ```nohighlight sudo certbot certonly --webroot -w /var/www/html -d ${DOMAIN} -d www.${DOMAIN} ``` There is a wrapper script around this b/c it has to do other things, pushing to haproxy, rsync to the second load balancer (which is why i use certonly). I have 196 live certs from LE in production, and this is how they are obtained. Happy to try something different, but confused, why now? ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [October 5, 2021, 3:31pm UTC](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616/20 "2021-10-05T15:31:35Z")
> [@jeffd](#): > > `sudo certbot certonly --webroot -w /var/www/html -d ${DOMAIN} -d www.${DOMAIN}` add `--preferred-chain "ISRG Root X1"` OR edit the `fullchain.pem` (or `chain.pem`) file used and remove the last cert. [note this manual edit method won't survive a cert renewal - but may be faster/simpler to test with] [Next page](https://community.letsencrypt.org/t/unable-to-verify-certificate/160616.md?page=2)