amazon-web-services - Lets-encrypt Ingress - NewOrder 请求没有包含足够短的 SAN 以适应 CN

Question

我们在 AWS 中有一个 EKS 集群。使用以下命令指向我们的 eks 集群后，aws eks --region us-east-1 update-kubeconfig --name cluster-name .
然后我们使用以下 shell 脚本为该集群部署了 nginx。file: 1_cert_manager.sh

###Nginx
# This script install nginx and cert manager using helm install..

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install nginx-ingress ingress-nginx/ingress-nginx \
    --set controller.replicaCount=2 \
    --set controller.nodeSelector."beta\.kubernetes\.io/os"=linux \
    --set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux

sleep 60
kubectl get service nginx-ingress-ingress-nginx-controller


###########
#Cert-manager
##########


# Label the cert-manager namespace to disable resource validation
kubectl label  cert-manager.io/disable-validation=true

# Add the Jetstack Helm repository
helm repo add jetstack https://charts.jetstack.io

# Update your local Helm chart repository cache
helm repo update

# Install the cert-manager Helm chart
helm install \
  cert-manager \
  --version v0.16.1 \
  --set installCRDs=true \
  --set nodeSelector."beta\.kubernetes\.io/os"=linux \
  jetstack/cert-manager

我们使用运行上述脚本 chmod +x ./1_cert_manager.sh sh ./1_cert_manager.sh安装 nginx 后，我们可以在访问 AWS 负载均衡器中提供的 DNS 时看到 nginx 主页。 kubectl get services给出了负载均衡器的 DNS 地址。
该页面使用 http 加载。为了启用对 https 的支持，我们安装了证书管理器。
我们已经安装了letsencrypt-issuer ClusterIssuer。 File: 2_cluster-issuer.yaml

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

我们已经使用以下命令安装了 Cluster issuer。 kubectl apply -f 2_cluster-issuer.yaml然后我们安装了一个示例 hello world 服务。 file:3_service.yaml

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: console
spec:
  selector:
    matchLabels:
      app: console
      tier: console
      track: stable
  replicas: 1
  template:
    metadata:
      labels:
        app: console
        tier: console
        track: stable
    spec:
      containers:
        - name: console
          image: "gcr.io/google-samples/hello-go-gke:1.0"
          ports:
            - name: http
              containerPort: 80
---
---
apiVersion: v1
kind: Service
metadata:
  name: console
spec:
  selector:
    app: console
    tier: console
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

kubectl apply -f 3_service.yaml我们有 2-3 个服务将在不同的端口上运行。出于测试目的，我们只安装了一项服务。
该服务已成功安装，我们已使用该服务进行了验证 kubectl get pods和 kubectl get services .
最后我们部署了入口 yaml 文件来提供主机详细信息和路由信息。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nandha-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$1
    nginx.ingress.kubernetes.io/use-regex: "true"
    kubernetes.io/ingress.class: nginx
    cert-manager.io/cluster-issuer: letsencrypt-issuer
    nginx.ingress.kubernetes.io/cors-allow-headers: "Content-Type"
    nginx.ingress.kubernetes.io/cors-allow-methods: "GET, POST, PUT, DELETE, OPTIONS"
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-credentials: "true"
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "600"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "600"
    nginx.ingress.kubernetes.io/client-body-buffer-size: "16m"
    nginx.ingress.kubernetes.io/proxy-body-size: "16m"
    nginx.ingress.kubernetes.io/enable-modsecurity: "true"
spec:
  tls:
      - hosts:
        - a2e858295f1201234aab29d960a10bfa-41041144.us-east-1.elb.amazonaws.com
        secretName: tls-secret
  rules:
    - host: a2e858295f1201234aab29d960a10bfa-41041144.us-east-1.elb.amazonaws.com
      http:
        paths:
          - pathType: Prefix
            backend:
              service:
                name: console
                port:
                  number: 80
            path: /(.*)

kubectl apply -f 4_ingress.yaml如果前面的命令成功执行，我们应该准备好我们的 tls-secret 证书。 (对于 GCP，它工作正常)。
我们调试使用 kubectl get certificates kubectl describe certificates tls-secret对于 describe 命令，我们收到以下错误，
创建订单失败:400 urn:ietf:params:acme:error:rejectedIdentifier:
NewOrder 请求未包含足够短以适合 CN 的 SAN
当我们搜索错误时，我们发现问题出在 DNS 的长度上。 AWS DNS 的长度大于 64。
当前解决方法:
我们已经为 AWS DNS url 创建了一个 CNAME 映射，并且我们在第 4 步中使用了该短映射 url 而不是实际的 url。
到目前为止，这有效。但是我们还需要为实际的 DNS 启用 SSL。
如何为 AWS DNS 值启用 SSL？
当我们启动 EKS 时，这 (a2e858295f1201234aab29d960a10bfa-41041144.us-east-1.elb.amazonaws.com) 是我们的主机。目前我们的 EKS 已终止。

Answer 1

"Length of AWS DNS is greater than 64."

不，这不是问题。每个 DNS 标签最多限制为 63 个字符(实际上是字节)，而您的第一个标签长度为 42，所以没问题。另一条规则是全名最多只能包含 255 个字符/字节，但实际上是 253。这对您的名字也可以。
问题出在其他地方，因为 LDAP/X520/certificate 引用说完整的 CN 必须小于 64，但它与 DNS 无关(CN 一开始通常是个人或组织名称，后来被劫持以放置 DNS 名称在那里，直到 SAN 扩展被写入(现在是默认设置)，DV 证书的主题实际上不再相关，部分原因是这些限制；SAN 中的名称又名 dnsName 被定义为有一个最大值实现，但也定义为有效域名，因此在实践中，上述规则适用于每个标签 63/255 个总数)。
这就是您的问题所在。
现代基于主机的证书只需要适当的 SAN，CN 现在与浏览器无关。因此，您需要在 SAN 中使用所有好的数据生成证书，但在 CN 中生成另一个虚假数据。这似乎是您所做的，但不确定是否理解。该证书对 SAN 中的所有名称都有效。
见 https://community.letsencrypt.org/t/a-certificate-for-a-63-character-domain/78870/6的想法。基本上添加另一个名称作为名字，它更小并且您也可以控制，以便能够获得颁发证书的验证。
真正的解决方案是通过 CA 摆脱 CN，如 https://github.com/letsencrypt/boulder/issues/2093 中所述。但这似乎被其他地方的其他标准化工作所阻碍。
同时，您还应该向您的云提供商寻求帮助。