<p>I have a werid problem - when asking for my internal hostname, <code>xxx.home.arpa</code> via e.g <code> openssl s_client -connect xxx.home.arpa:443</code> one (example) pod</p>
<pre class="lang-yaml prettyprint-override"><code> -  image: docker.io/library/node:8.17.0-slim
    name: node
    args:
      - &quot;86400&quot;
    command:
      - sleep
</code></pre>
<p>is getting response with <strong>DEFAULT NGINX INGRESS CERTIFICATE</strong>.</p>
<p>Other pod in the same namespace <strong>for the same command</strong> is getting response with my <strong>custom certificate</strong>.</p>
<p><strong>Question:</strong>
Why one pod RECEIVES different cert for the same request?</p>
<p>For the purpose of this problem, please assume that cert-manager and certs should be properly configured - they are working in most of the system, it's only few pods that are misbehaving</p>
<p><strong>Configuration</strong>: k8s nginx ingress, calico CNI, custom coredns svc which manages DNS responses (might be important?), my own CA authority.</p>
<p>e:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: ca-issuer
    kubernetes.io/ingress.class: nginx
  creationTimestamp: &quot;2022-03-13T06:54:17Z&quot;
  generation: 1
  name: gerrit-ingress
  namespace: gerrit
  resourceVersion: &quot;739842&quot;
  uid: f22034ab-0ed8-4779-b01e-2738e6f63eb7
spec:
  rules:
  - host: gerrit.home.arpa
    http:
      paths:
      - backend:
          service:
            name: gerrit-gerrit-service
            port:
              number: 80
        pathType: ImplementationSpecific
  tls:
  - hosts:
    - gerrit.home.arpa
    secretName: gerrit-tls
status:
  loadBalancer:
    ingress:
    - ip: 192.168.10.2                  
</code></pre>
<p>Most of the configuration (Except DNS) <a href="https://github.com/Venthe/Personal-Development-Pipeline/blob/develop/provisioning/cluster_vagrant/provisioning/1.10_ingress.yml" rel="nofollow noreferrer">is up here</a>.</p>

Jacek Lipiec
<p>As it turns out, my initial guesses were far off - particular container had a set of tools which were both configured to not send servername (Or not support SNI at all, which was the problem), specifically <code>yarn:1.x</code> and <code>openssl:1.0.x</code>.</p>
<p>The problem was with SNI of course, newer openssl or curl do use -servername by default satisfying SNI requirements.</p>
<p>To this I've considered two solutions:</p>
<ul>
<li>Wildcard DNS for the clients that do not support SNI, which is easier but does not feel secure</li>
<li>TLS termination with reverse proxy allowing me to transparently use client with SNI support, which I haven't yet tried.</li>
</ul>
<p>I went with wildcard DNS, though I don't feel that this should be done in prod. :)</p>
