No, it uses another file, freecert.pfx, produced with command
openssl pkcs12 -inkey /etc/letsencrypt/live/hub1.cet.cloud/privkey.pem -in /etc/letsencrypt/live/hub1.cet.cloud/fullchain.pem -export -out freecert.pfx -password pass:[mypassword]
No, it uses another file, freecert.pfx, produced with command
Well then is is having issues with the PFX file (or contents therein) or is unable to match the chain entries to whichever root store it uses.
It fails to serve the provided chain.
[mind of its' own]
--- Certificate chain 0 s:/CN=hub1.cet.cloud i:/C=US/O=Let's Encrypt/CN=R3 1 s:/C=US/O=Let's Encrypt/CN=R3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 ---
Our domains have been affected by the DST Root CA X3 expiration.
The only solution we found was to update certbot to at least 1.12 to have access to the --prefered-chain command to force ISRG Root X1.
The problem is that certbot only goes up to 0.31 with apt.
We tried snapd but it seems to not be compatible with our Ubuntu 16.04 (error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount: unknown filesystem type 'squashfs')
Same goes for pip installation, which shows errors that seems to be linked to our python version.
Any help would be appreciated to update our certbot version, like many others, our system is down and clients are waiting.
I thought the same, but
openssl pkcs12 -info -in freecert.pfx
produces (see original help request for complete message)
Certificate bag Bag Attributes: <No Attributes> subject=/C=US/O=Let's Encrypt/CN=R3 issuer=/C=US/O=Internet Security Research Group/CN=ISRG Root X1
Where ***** does it find reference to DST CA X3?
Drop it (for now) and use another ACME client - like:
Welcome to the community forum! Yes, there are several working and specific solutions that many posters have adopted to resolve issues client side. However the specific solution depends on which of the two expirations are causing you problems and what your set-up is like.
In this thread, many users have discovered they are sending an incorrect chain or no chain at all. The solution is to update the configuration specific to your server to serve the correct the chain. You can use the search field on this thread or in the forum generally to see if information has posted and resolved for your server.
The other problem is around which chain you are sending particularly for the roots. There are trade-offs for each one and you can read about them here under the RSA changes for May 4th Production Chain Changes
Those are the main server side options you can take to still use Let’s Encrypt. There are some client side problems related to cached certificates and chain building behavior that have specific solutions as well.
Please begin by searching on the forum to see if your specific setup has been asked about. If you cannot find it, you will need to include some basic information like what is running server-side, what problem you are seeing, and your domain.
The toe bone is connected to the foot bone...
The foot bone is connected to the heal bone...
End-leaf cert connects to R3
R3 connects to X1
X1 connects to X3
Even if you don't explicitly provide that info - it is in there - like DNA!
But that chain contains
-----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-----
that is https://letsencrypt.org/certs/lets-encrypt-r3.pem, which refers to X1 self signed, or not (I do not know how to link to original help request)?
? ? ?
I'm not arguing about what that file contains or not.
What I've said, and the test show, is that the system is NOT serving a trusted chain.
This is all of what I get directly from it:
-----BEGIN CERTIFICATE----- MIIFIjCCBAqgAwIBAgISA6bJd9Q/QePvDBKsI+penHAdMA0GCSqGSIb3DQEBCwUA MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD EwJSMzAeFw0yMTA5MzAxMDQwMzVaFw0yMTEyMjkxMDQwMzRaMBkxFzAVBgNVBAMT Dmh1YjEuY2V0LmNsb3VkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2QKa90ruzeJvuDpsz3xLGZecF8xIwOhF2WCgWpj1b0rk7m9eWHJ/CnyvL2bkPYgj xwIJ1SnhoIhRoUg2acVmw7HeP8/2ixJ4w+B4SBcsfnHk+yF/W0PY11hSCyikDmoH FAFygZPKjsW6pcvoYvkaH5TjkoKLoAatCELPgA8+bDGvbus4KwKFuqclvHxH4602 2m1IVgdUrm0Yod4bhVzJVjz8Mbn/q9E9lEUZAZNH5nDOdF9Xgjb1YdQJdNFwUfaH hm01XFv1huYTb6IhhYXyOU8xUxuK4pKGSFIhVdmlnjVZwsWNzm01vgy5/F13mnGa IwNiSlsHFKcF46dJ1YXPGwIDAQABo4ICSTCCAkUwDgYDVR0PAQH/BAQDAgWgMB0G A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1Ud DgQWBBScx2SaR2DlHI8kNlJzXHTkSkIkVDAfBgNVHSMEGDAWgBQULrMXt1hWy65Q CUDmH6+dixTCxjBVBggrBgEFBQcBAQRJMEcwIQYIKwYBBQUHMAGGFWh0dHA6Ly9y My5vLmxlbmNyLm9yZzAiBggrBgEFBQcwAoYWaHR0cDovL3IzLmkubGVuY3Iub3Jn LzAZBgNVHREEEjAQgg5odWIxLmNldC5jbG91ZDBMBgNVHSAERTBDMAgGBmeBDAEC ATA3BgsrBgEEAYLfEwEBATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vY3BzLmxldHNl bmNyeXB0Lm9yZzCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB2AH0+8viP/4hVaCTC wMqeUol5K8UOeAl/LmqXaJl+IvDXAAABfDaBmJgAAAQDAEcwRQIhAJY0gQ/vQEWR 1fwn+ML/RA1BKvqTtis7pVUnK/JMtVlZAiAGgtsPJ/IvB66eidubtJK5yHM9aIoo CZsB3bLNUx0KxwB2AG9Tdqwx8DEZ2JkApFEV/3cVHBHZAsEAKQaNsgiaN9kTAAAB fDaBmUIAAAQDAEcwRQIhAP9nXqL7HtpVBYBSbcPb2kiWyDpGzJe1rSubYd/r/pHA AiA0bI92IbJx4wW3P6lPrs/c1feK4P7qH2pDnZelCboz8zANBgkqhkiG9w0BAQsF AAOCAQEApasjJEtVS+k/xon8uzzY2r9e3ogwKOShEX1y+O/8q8y2adaVNh6/R8rz /A7Fja4EwnMfEBIlew6SzLWBKWoJ3oF2TXee2/E0Z6/gBC0imlBG/po1RwVrldck Zh7TSAAlqjNZfPsz+CSuMXqZ4/D30lgLpB0nrqL1rNxJrhLphNSOzkOmNRF3xokM dzCsOl5+9k2MXWQqAZSEXXKdt/qVgc2CVzD3Q5KODsPv8nNNsQcq0+Bj5VAdO3Nv nrD5lTVs31Ykf4BXslw8vEma5SDxnhNXOoW7TJOtMLE+f2mdLa+6mNZazyBv8Uza tGgku+XQSB2XAEH0xY6+2uEbGCxQxQ== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIEZTCCA02gAwIBAgIQQAF1BIMUpMghjISpDBbN3zANBgkqhkiG9w0BAQsFADA/ MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT DkRTVCBSb290IENBIFgzMB4XDTIwMTAwNzE5MjE0MFoXDTIxMDkyOTE5MjE0MFow MjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUxldCdzIEVuY3J5cHQxCzAJBgNVBAMT AlIzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuwIVKMz2oJTTDxLs jVWSw/iC8ZmmekKIp10mqrUrucVMsa+Oa/l1yKPXD0eUFFU1V4yeqKI5GfWCPEKp Tm71O8Mu243AsFzzWTjn7c9p8FoLG77AlCQlh/o3cbMT5xys4Zvv2+Q7RVJFlqnB U840yFLuta7tj95gcOKlVKu2bQ6XpUA0ayvTvGbrZjR8+muLj1cpmfgwF126cm/7 gcWt0oZYPRfH5wm78Sv3htzB2nFd1EbjzK0lwYi8YGd1ZrPxGPeiXOZT/zqItkel /xMY6pgJdz+dU/nPAeX1pnAXFK9jpP+Zs5Od3FOnBv5IhR2haa4ldbsTzFID9e1R oYvbFQIDAQABo4IBaDCCAWQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8E BAMCAYYwSwYIKwYBBQUHAQEEPzA9MDsGCCsGAQUFBzAChi9odHRwOi8vYXBwcy5p ZGVudHJ1c3QuY29tL3Jvb3RzL2RzdHJvb3RjYXgzLnA3YzAfBgNVHSMEGDAWgBTE p7Gkeyxx+tvhS5B1/8QVYIWJEDBUBgNVHSAETTBLMAgGBmeBDAECATA/BgsrBgEE AYLfEwEBATAwMC4GCCsGAQUFBwIBFiJodHRwOi8vY3BzLnJvb3QteDEubGV0c2Vu Y3J5cHQub3JnMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9jcmwuaWRlbnRydXN0 LmNvbS9EU1RST09UQ0FYM0NSTC5jcmwwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYf r52LFMLGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjANBgkqhkiG9w0B AQsFAAOCAQEA2UzgyfWEiDcx27sT4rP8i2tiEmxYt0l+PAK3qB8oYevO4C5z70kH ejWEHx2taPDY/laBL21/WKZuNTYQHHPD5b1tXgHXbnL7KqC401dk5VvCadTQsvd8 S8MXjohyc9z9/G2948kLjmE6Flh9dDYrVYA9x2O+hEPGOaEOa1eePynBgPayvUfL qjBstzLhWVQLGAkXXmNs+5ZnPBxzDJOLxhF2JIbeQAcH5H0tZrUlo5ZYyOqA7s9p O5b85o3AM/OJ+CktFBQtfvBhcJVd9wvlwPsk+uyOy2HI7mNxKKgsBTt375teA2Tw UdHkhVNcsAKX1H7GNNLOEADksd86wuoXvg== -----END CERTIFICATE-----
That second cert expired yesterday!
we are using IIS 10.0 and have to support old Android devices, so it is important that our server provides both paths, including the "New Default Chain" with IdenTrust DST Root CA X3.
Sadly, the IIS removes the path including the expired IdentTrust Certificate.
The Workaround we found was putting the "ISGR Root X1" in the Untrusted Store of the Windows Certificate Manager as described here and reboot the server.
Is there a better way to do this? This way we are unable to renew the certificates using win-acme.
It is astounding, but explains perfectly what happens. Please, can you tell me how you have obtained that response (two certificates, second being probably the obsolete R3)?
openssl s_client -connect EXAMPLE.COM:443 -servername EXAMPLE.COM -showcerts
[simply copy out the certs shown]
Hello, we are using centos 7. I updated the ca-certificates package and checked to make sure it's removed
trust list | grep -C3 'DST Root CA X3', however, I'm still seeing the root certificate listed when I check our sites:
Is a server reboot required, or is there another way to clear this certificate from the chain?
99% of our users can access the site without any issue. We are having issues with users that have older device (mostly old MacBooks)
To all webhosts looking to continue supporting older clients, I suggest that
you confirm the root certificate you want to use is on the system you want to support, example:
OS X Mavericks: List of available trusted root certificates - Apple Support (IL)
you configure your ACME client to use a different CA server
example: SSL | Buypass Go SSL – Technical information | Buypass CA
when an embedded certificate expires, if the device isn't getting updated, that's that. check the expiration date of the embedded root certificate on the older system you want to support, and the browser is probably deriving it's trusted root from the operating system.
exception: firefox, but firefox accepts expired trusted root certs, unlike chrome, so there's that.
we're using HAProxy 2.4.4 and seeing some older macs and ubuntu 15 seeing cert expired messages when they go to docucopies.com is there a config change I can make in haproxy that will fix that?
Thank you, I will try to find which subject is substituting R3 certificate. Thank you again.
Hi @deckberg-qd, welcome to the LE community forum
That site is using the exact same trust path (chain) that this forum is using.
You have only three choices:
- upgrade the clients to work with this trust path (chain)
[may not even be possible now, or ever (for some no-longer-supported clients)]
- modify all the servers to use a different trust path (chain)
this isn't very likely; as you can't possibly control the very large number of systems on the Internet that are using this same trust path (chain)
- put all your troubled clients behind a proxy (one that terminates the TLS connections
that may keep those clients within your trust path (chain) control; as they would only see the proxy
[there may be other ways... I'm running low on ]
for your 2nd bullet. am I thinking correct that I can update certbot to 1.12 and put in the correct whatever for --preferred-chain ?
sorry, I'm not trying to make the clients work everywhere on the net, I just want my older customers to be able to get to my website docucopies.com without the expired cert warning
For the servers under your control, sure.
"a different trust path" can includes using other FREE, or paid, CAs [all valid choices]
Many ways to slice that pie!
Looks like SSL labs is saying there is and issue with one of the paths. So I need to include the cross signed cert somewhere?