☰

kubernetes cert-manager 因证书链畸形或损坏而失败

tag-icon • tag-icon kubernetes cert-manager
kubernetes cert-manager 因证书链畸形或损坏而失败

我已经设置了 cert-manager 来使用私有 CA 颁发者签署证书。私有 CA 机密已正确设置，在添加到 TLS 机密之前，我已经使用 OpenSSL verify 命令验证了链，并且它们都正确地验证了根。但是当使用 cert-manager 执行相同操作时，证书未签名，我收到错误消息“消息：证书请求未能完成，将重试：签名证书时出错：证书链格式错误或损坏”

以下是证书颁发者的 yaml

   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
    name: my-ca-issuer
    namespace: default
   spec:
   ca:
      secretName: my-tls-secret
   ---
   apiVersion: cert-manager.io/v1
   kind: Certificate
   metadata:
     name: cert-test
     namespace: default
   spec:
     secretName: my-tls-secret
   issuerRef:
     name: my-ca-issuer
     kind: ClusterIssuer
   commonName: cert-test.com
   renewBefore: 12h # Renew the certificate when it's 12 hours from expiration

my-tls-secret 位于 cert-manager 命名空间中

CA 发行者验证正确

  kubectl get clusterissuers -o wide
NAME                        READY   STATUS                AGE
my-ca-issuer            True    Signing CA verified   27h

my-tls 密钥是使用此命令创建的

 kubectl create secret generic my-tls-secret --from-file=tls.crt=cert-chain.pem --from-file=tls.key=myca.key --from-file=ca.crt=ca-chain.pem -n cert-manager

有没有线索可以说明为什么证书管理器中的链条格式不正确，而 openssl verify 中的链条没有任何问题

openssl crl2pkcs7 -nocrl -certfile ca-chain.pem | openssl pkcs7 -print_certs -noout

subject=C = US, ST = TX, L = Austin, O = org, CN = app-TLS-Sub-CA
issuer=C = US, ST = TX, L = Austin, O = org, CN = Issuing-Sub-CA

subject=C = US, ST = TX, L = Austin, O = org, CN = Issuing-Sub-CA
issuer=C = US, ST = TX, L = Austin, O = org, CN = Root

subject=C = US, ST = TX, L = Austin, O = org, CN = Root
issuer=C = US, ST = TX, L = Austin, O = org, CN = Root

答案1

从你的评论即使确保证书的顺序和连接正确，问题仍然存在。

[ Kubernetes Cluster ]
         |
   [ cert-manager ]
         | \
         |  [ Increased Log Verbosity ]
         |
[ my-ca-issuer ClusterIssuer ]
         | \
         |  [ Check CA Permissions ]
         |
[ my-tls-secret (CA secret) ]
         | \
         |  [ Verify Certificate Chain Formatting ]
         |
[ cert-test Certificate ]
         |
   [ CertificateRequest Debugging ]

虽然 OpenSSL 能够验证该链，cert-manager在 Kubernetes 上下文中可能会有不同的解释。这可能是由于cert-manager处理证书解析的方式不同。
考虑使用类似kubectl describeCertificate和资源来CertificateRequest获取更多线索。

kubectl describe certificate cert-name -n default
kubectl describe certificaterequest -n default
kubectl describe clusterissuer my-ca-issuer

有时，证书文件可能包含隐藏字符或不易发现的格式问题。确保 PEM 文件不包含任何无关字符或不正确的行尾。您可以使用类似工具cat -v或具有隐藏字符可见性的文本编辑器来检查文件。

确保所代表的 CAmy-tls-secret具有签署证书所需的权限。某些 CA 可能被限制只能签署某些类型或级别的证书。这尤其重要，因为您的 CA 层次结构中有多个级别。

增加日志详细程度cert-manager以获取有关签名过程中发生的情况的更多详细信息。

kubectl get deployments -n cert-manager
kubectl edit deployment <cert-manager-deployment-name> -n cert-manager

spec:
  containers:
  - args:
    - --v=4  # This sets log verbosity to level 4
    ...

以防万一，您的证书链的深度可能会导致问题。虽然这种情况并不常见，但有些系统对它们可以处理的链深度有限制。如果可能，请使用更简单的链（更少的层级）进行测试，看看问题是否仍然存在。

答案2

问题似乎与 my-tls-secret 密钥中的证书链的格式或内容有关。您应该确保 tls.crt 中的证书链顺序正确且包含所有必要的中间证书。

尝试按正确的顺序连接您的证书：首先是叶证书，然后是中间证书（如果有），最后是根证书。然后使用正确排序的链更新 my-tls-secret。

像这样：

kubectl create secret generic my-tls-secret --from-file=tls.crt=combined-chain.pem --from-file=tls.key=myca.key --namespace=cert-manager

然后合并证书：

cat leaf-cert.pem intermediate-cert.pem root-cert.pem > combined-chain.pem

让我知道进展如何！

相关内容