azure - 为什么我的 k8s Nginx 入口 Controller 提供两个证书(其中之一是 Kubernetes 假证书)？

Question

我们正在 Azure 上运行 AKS Kubernetes 集群。我使用“NGINX Ingress Controller ”和“cert-manager ”进行路由和证书生成(通过 Let's Encrypt)。我遵循了 Microsoft 文档中的基本设置建议:https://learn.microsoft.com/en-us/azure/aks/ingress-tls

当在网络浏览器中访问我们的页面时，我们一开始没有注意到任何异常 - HTTPS 工作正常。浏览器可以验证 Let's Encrypt 证书。但是，我们后来注意到入口 Controller 实际上提供两个证书(其中一个具有通用名称:“Kubernetes Ingress Controller Fake Certificate”和替代名称:“ingress.local”):https://www.ssllabs.com/ssltest/analyze.html?d=test-aks-ingress.switzerlandnorth.cloudapp.azure.com&hideResults=on

长话短说 - 昨天，我尝试了各种方法，从重新安装 Nginx-ingress 和 cert-manager 到从头开始启动新的 Azure Kubernetes 服务，但每次我都会遇到同样的情况。

我读过许多遇到类似问题的人的讨论。通常，它们有点不同，因为它们实际上根本看不到有效的证书。我确认我们正在使用生产 Let's Encrypt ClusterIssuer:

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: ***@***
    privateKeySecretRef:
      name: letsencrypt
    solvers:
    - http01:
        ingress:
          class: nginx
          podTemplate:
            spec:
              nodeSelector:
                "kubernetes.io/os": linux

我还使用 test-ingress 创建了一个新的测试应用程序:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: hello-world-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /$1
    nginx.ingress.kubernetes.io/use-regex: "true"
    cert-manager.io/cluster-issuer: letsencrypt
spec:
  tls:
  - hosts:
    - test-aks-ingress.switzerlandnorth.cloudapp.azure.com
    secretName: tls-secret
  rules:
  - host: test-aks-ingress.switzerlandnorth.cloudapp.azure.com
    http:
      paths:
      - backend:
          serviceName: aks-helloworld-one
          servicePort: 80
        path: /hello-world-one(/|$)(.*)

据我了解，对于之前报告过此问题的人来说， secret 通常存在一些问题。这里我假设ClusterIssuer会生成相关证书并将其存储在自动生成的tls-secret中:

Name:         tls-secret                                                                       
Namespace:    test                                                                             
Labels:       <none>                                                                           
Annotations:  cert-manager.io/alt-names: test-aks-ingress.switzerlandnorth.cloudapp.azure.com  
              cert-manager.io/certificate-name: tls-secret                                     
              cert-manager.io/common-name: test-aks-ingress.switzerlandnorth.cloudapp.azure.com
              cert-manager.io/ip-sans:                                                         
              cert-manager.io/issuer-group: cert-manager.io                                    
              cert-manager.io/issuer-kind: ClusterIssuer                                       
              cert-manager.io/issuer-name: letsencrypt                                         
              cert-manager.io/uri-sans:                                                        
                                                                                               
Type:  kubernetes.io/tls                                                                       
                                                                                               
Data                                                                                           
====                                                                                           
tls.crt:  3530 bytes                                                                           
tls.key:  1675 bytes  

也许我仍然感到困惑的是这里不同的 secret /证书。 cert-manager 在 cert-manager 命名空间中运行，并在那里创建一个 letsencrypt key ，而我的测试设置则在test 命名空间(包括入口 Controller )。

[更新]但这里的实际问题是什么？在普通浏览器中一切都“正常工作”，对吧？不幸的是，真正的问题是连接不适用于特定的客户端应用程序，该应用程序可能不支持 SNI。

有没有办法不使用默认证书？我如何更改此处的配置以默认提供“Let's Encrypt”签名证书 - 这可能吗？

Answer 1

这是预期的行为。默认情况下，入口 Controller 创建自签名证书，CN 表明它是假的。当请求与 Ingress 中定义的规则不匹配时使用此选项。因此，当我们从浏览器访问此 URL 时，它会返回正确的证书，但对于不带 servername 字段的 openssl s_client，它与 Ingress 中定义的规则不匹配，会转到默认后端并返回自签名证书。

您还可以为 Ingress 指定默认证书。请参阅https://github.com/kubernetes/ingress-nginx/issues/4674了解更多详情。