Alpine Linux issue

[thecode_jc]

Hi jsha,

I have alpine linux container, and the services are not able to communicate over ssl, due to this issue.
I removed the DST Root CA X3 from the Trust Store, yet not able to communicate over ssl.
could you suggest any steps to be taken in alpine linux for this.
TIA

[rg305]

Hi @thecode_jc welcome to the LE community forum

Please provide more detail on your specific problem.

[thecode_jc]

Hi Rudy,
I have 2 services running in kubernetes cluster in IBM Cloud.
The container running my service is based on Alpine Linux. I have an ingress which uses the letsencrypt certificate.
Service 1 is trying to hit Service 2 with the ingress URL, and getting SSL certificate expired error(The certificate says 84 days remaining in the Browser and in Cloud panel).
On further digging I came to know about this issue, So I Removed the DST Root CA X3 certificate from Trust store.
However, I am still getting this error.
Is the alpine linux having a cache from which its referring the old certificate ?

[rg305]

@thecode_jc
You may also need to remove the "DST Root CA X3" from the chain being served.
[note: the whole point of its' presence is to provide a path for older Androids to trust]

[thecode_jc]

Hi Rudy,

Thanks for the reply
I have removed the certificate from /etc/ca-certificates.conf by commenting DST Root CA X3 cert, and running update-ca-certificates, now the /etc/ssl/certs/ca-certificates.crt which contains all the certificates, does not have this certificate.
Do you know which other place we have a reference of the old certificate ?

[rg305]

Try:
grep -Ri DST /etc/ssl/ | grep -i X3
grep -Ri DST /usr/share/ca-certificates/mozilla | grep -i X3

And, if the problem continues, let us know.

[thecode_jc]

The DST Root CA X3, is not present in above paths and the problem still persists

[rg305]

Please share the FQDN to better see the problem and help you.

[thecode_jc]

Here is the url to the site - https://ibm-test-org-2.rsbn-sandbox-client-ser-365e4929a22526f4d6f2195da807e4b0-0000.us-south.containers.appdomain.cloud

[rg305]

The chain being served still includes "DST Root CA X3":

openssl s_client -connect ibm-test-org-2.rsbn-sandbox-client-ser-365e4929a22526f4d6f2195da807e4b0-0000.us-south.containers.appdomain.cloud:443 -servername ibm-test-org-2.rsbn-sandbox-client-ser-365e4929a22526f4d6f2195da807e4b0-0000.us-south.containers.appdomain.cloud
CONNECTED(00000005)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = rsbn-sandbox-client-ser.us-south.containers.appdomain.cloud
verify return:1
---
Certificate chain
 0 s:CN = rsbn-sandbox-client-ser.us-south.containers.appdomain.cloud
   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
---

I suspect that if you remove it, your problem will cease.

[thecode_jc]

Hi Rudy,
Thanks for the reply
I checked and found that the TLS request is getting terminated at nginx, so this changes will be needed at nginx ingress service, hence we are seeing this issue.
Have raised a query with the support team, as its a managed cluster.
Will update here once I get an answer

[rg305]

Let them know they would need to switch:
--preferred-chain "ISRG Root X1"

[thecode_jc]

Hi Rudy,

Thanks for the correct direction, I was able to remove the third certificate from the chain, which was signed by DST Root CA X3.
This certificate was stored in a kubernetes secret and I had to created a duplicate and modify the certificate chain, and recreate the nginx ingress definition