Certificate error when requested via HTTPS protocol in the POD of the Server node

[gaecfov]

I have a K3S cluster, 1 Server node, 1 Agent node, version is v1.31.1+k3s1;

Phenomenon: Certificate error when requested via HTTPS protocol in the POD of the Server node.
It is confirmed that:

1. The Server node can make normal requests, but the Pod requests inside the Server node cannot
2. The Pod request of the Agent node is normal

My question is that I requested the URL of a third party, and the certificate of this URL is normal. Why does the request in Pod prompt that there is a self-signed certificate of k3s-server in the certificate chain?
Has anyone encountered this problem?

Executed inside a Pod
openssl s_client -connect gw-api.pinduoduo.com:443 -CApath /etc/ssl/certs/
Error:

CONNECTED(00000003)
depth=1 CN = k3s-server-ca@1733295404
verify error:num=19:self signed certificate in certificate chain
verify return:1
depth=1 CN = k3s-server-ca@1733295404
verify return:1
depth=0 O = k3s, CN = k3s
verify return:1
---
Certificate chain
 0 s:O = k3s, CN = k3s
   i:CN = k3s-server-ca@1733295404
 1 s:CN = k3s-server-ca@1733295404
   i:CN = k3s-server-ca@1733295404
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICKTCCAdCgAwIBAgIINDnu5oNiGrEwCgYIKoZIzj0EAwIwIzEhMB8GA1UEAwwY
azNzLXNlcnZlci1jYUAxNzMzMjk1NDA0MB4XDTI0MTIwNDA2NTY0NFoXDTI1MTIw
NDA2NTY0NFowHDEMMAoGA1UEChMDazNzMQwwCgYDVQQDEwNrM3MwWTATBgcqhkjO
PQIBBggqhkjOPQMBBwNCAASGDJY5BNirFjzyHE+FFgua5JbE1zm3QN0GHyHD1nri
/WCS0g/387jrXhMFOmRC4AWHO1CGxGEyk132YjzU6B8go4H0MIHxMA4GA1UdDwEB
/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDATAfBgNVHSMEGDAWgBSo0IVAzjZ7
jzQNjvL0LnH9LaOZDTCBqAYDVR0RBIGgMIGdgg5hbGl5dW4tb21zLTE0MYIKa3Vi
ZXJuZXRlc4ISa3ViZXJuZXRlcy5kZWZhdWx0ghZrdWJlcm5ldGVzLmRlZmF1bHQu
c3ZjgiRrdWJlcm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWyCCWxvY2Fs
aG9zdIcECisAAYcEfwAAAYcErBjb9IcQAAAAAAAAAAAAAAAAAAAAATAKBggqhkjO
PQQDAgNHADBEAiAg34VIVQXiP9y7dR1EmT+hytlKVUR2GIQzR04D6SYYvgIgDt8R
024Nv5xRyc9TDawQMVMSyT6vZLtUzvZ9Fn9i6Zo=
-----END CERTIFICATE-----
subject=O = k3s, CN = k3s

issuer=CN = k3s-server-ca@1733295404

---
No client certificate CA names sent
Requested Signature Algorithms: RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA384:ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA384:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 1363 bytes and written 416 bytes
Verification error: self signed certificate in certificate chain
---
New, TLSv1.3, Cipher is TLS_AES_128_GCM_SHA256
Server public key is 256 bit
Secure Renegotiation IS NOT supported
No ALPN negotiated
Early data was not sent
Verify return code: 19 (self signed certificate in certificate chain)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_128_GCM_SHA256
    Session-ID: A5D9B2582C7FD0FE75620DDE3700DA772E96B815A44775F8D3C7B490395C2B2F
    Session-ID-ctx: 
    Resumption PSK: BF75102F4ACC0876431430B6CFC62B07973BA7C49B3F4C0630219B4817758E5D
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 604800 (seconds)
    TLS session ticket:
    0000 - d7 78 0d bf d7 3b d6 8e-47 98 f5 a0 a3 71 9f 58   .x...;..G....q.X
    0010 - 3c fe 95 5f cd b1 50 f5-e6 8b 03 82 44 ff e5 bb   <.._..P.....D...
    0020 - 81 7a 9e 45 b4 cc 72 bc-87 39 d5 59 d3 d8 c2 b7   .z.E..r..9.Y....
    0030 - 44 c1 f0 5e a5 c8 c1 a7-ed 20 a1 c7 1b e4 24 71   D..^..... ....$q
    0040 - 00 24 4a ae 8b ae 0f 78-d7 ae ad ac 38 52 6a 50   .$J....x....8RjP
    0050 - 65 65 cc 20 45 a5 98 49-cb d7 9a 4d a8 9e e2 71   ee. E..I...M...q
    0060 - 55 08 2b d4 d2 11 ab 85-f8                        U.+......

    Start Time: 1735558603
    Timeout   : 7200 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK

[brandond]

You'd need to figure out why gw-api.pinduoduo.com is resolving to the address of one of your K3s nodes, or the Kubernetes in-cluster service endpoint, when looked up within the cluster.