Hello!
I'd like to confirm the status of "This Let's Encrypt chain includes the expired DST Root CA X3 in order to remain compatible with older operating system such as Android 7.0 and lower." - is this then the legacy chain?
We have some microservices running in Kubernetes and they aren't happy with one of our 3rd party service provider's API endpoint - which is using LE. Can we then inform them to update their system to use the modern one?
Thanks!
Hi @makatinie welcome to the LE community forum 
[I've moved your post to a separate topic because it wasn't directly related to the "New Chain Checker Tool topic]
Before having them make any changes, can you check that your Kubernetes systems will access other LE secured sites that are using the "more modern trust path" without any issues?
You can by all means ask your API provider to update their chain but they may have a reason they have gone for the legacy compatibility chain. If they require that for other clients but it's problematic for you then you should tell them, so they can decide what to do.
Most modern and updated systems should be able to consume either chain. however you will find some specific tools continue to dislike the expired root used in the legacy compatibility chain.
Long term, everyone will need to use the modern chain because the legacy chain will only survive for a few more years.
Thanks for this 
I'll chat to the development team and see if we can find an API to test that's using the modern LE chain. For now it seems only one of our 3rd party providers are using LE services, so we'll have to look for a test/demo LE endpoint.
We are using Google Cloud Platform and asp.net core, and are calling REST services on the 3rd party side. Not sure of perhaps the list of CA certs are also pulled/compiled during builds. So far we can't find any info or other communities where they are having the same issues...
I agree that most systems should be able to consume either chain
@makatinie
Just my personal thoughts...
If push comes to shove and you are left underserviced...
And you have access to any other web enabled and Internet connected "device"...
And you are willing to go "outside the box" and maybe outside the factory that makes the boxes...
You could proxy the requests to them via one of your own systems.
A system that you can control and be sure that it works as you expect.
[you would have to change the FQDN to one of yours to serve the requests securely]
[Warning: I'm the guy that likes to always use a bigger hammer when things don't go as expected]
Thanks for the quick replies and suggestions! Proxying the requests isn't a bad idea as a type of "last resort" - will keep this in mind
It will depend whether your .net core service is using a windows or linux host as linux doesn't have the same concept of a single platform trust store. It may also depend which exact version of .net core you are running (e.g. Cryptography breaking changes - .NET | Microsoft Learn)
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.