為什么我的 k8s Nginx 入口 controller 提供兩個證書（其中一個是 Kubernetes 假證書）？

Question

我們在 Azure 上運行 AKS Kubernetes 集群。 我正在使用“ NGINX Ingress Controller ”和“ cert-manager ”進行路由和證書生成（通過Let's Encrypt）。 我遵循了 Microsoft 文檔中的基本設置建議： https://docs.microsoft.com/en-us/azure/aks/ingress-tls

在網絡瀏覽器中訪問我們的頁面時，我們一開始並沒有發現任何異常——HTTPS 工作正常。 瀏覽器可以驗證 Let's Encrypt 證書。 但是，我們后來注意到，入口 controller 實際上提供兩個證書（其中一個具有通用名稱：“Kubernetes Ingress Controller Fake Certificate”和替代名稱：“ingress.local”）： Z5E056C500A1C4B6BADE5Z11：//www.500A1C4B6BADE5Z110。 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

我還使用測試入口創建了一個新的測試應用程序：

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  

也許我仍然感到困惑的是這里不同的秘密/證書。 cert-manager在cert-manager命名空間中運行，並在那里創建一個letsencrypt secret，而我的測試設置在test命名空間（包括入口控制器）中運行其他所有內容。

[更新]但是這里的實際問題是什么？ 一切都在普通瀏覽器中“正常工作”，對吧？ 不幸的是，真正的問題是連接不適用於可能不支持 SNI 的特定客戶端應用程序。

有沒有辦法沒有默認證書？ 我將如何更改此處的配置以默認提供“讓我們加密”簽名證書 - 這可能嗎？

Answer 1

這是預期的行為。 默認情況下，Ingress controller 創建自簽名證書，其中 CN 表明它是假的。 這在請求與 Ingress 中定義的規則不匹配時使用。 因此，當我們從瀏覽器訪問此 URL 時，它返回正確的證書，但 openssl s_client 沒有 servername 字段，它與 Ingress 中定義的規則不匹配，並轉到默認后端並返回自簽名證書。

您還可以為 Ingress 指定默認證書。 有關詳細信息，請參閱https://github.com/kubernetes/ingress-nginx/issues/4674 。