Ошибка диспетчера сертификатов kubernetes: цепочка сертификатов искажена или повреждена

У меня есть менеджер сертификатов для подписания сертификата с эмитентом частного центра сертификации. секрет частного CA настроен правильно, и перед добавлением секрета TLS я проверил цепочку с помощью команды проверки OpenSSL, и все они правильно проверяют корень. Но когда то же самое делается с диспетчером сертификатов, сертификат не подписывается, и я получаю сообщение об ошибке «Сообщение: запрос сертификата не выполнен и будет повторен: ошибка подписи сертификата: цепочка сертификатов неверна или нарушена».

Вот 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 находится в пространстве имен диспетчера сертификатов

эмитент 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 не имеет никаких проблем с цепочкой

      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
Источник

2 ответа

Судя по вашим комментариям , проблема сохраняется даже после обеспечения правильного порядка и объединения сертификатов.

      [ 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 может проверить цепочку,в контексте Kubernetes это может интерпретироваться по-другому. Это может быть связано с тем, как обрабатывается анализ сертификатов.
Рассмотрите возможность использования такого инструмента, какkubectl describeнаCertificateиCertificateRequestресурсы, чтобы получить больше подсказок.

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

Иногда файлы сертификатов могут содержать скрытые символы или проблемы с форматированием, которые трудно обнаружить. Убедитесь, что файлы PEM не содержат посторонних символов или неправильных окончаний строк. Вы можете использовать такие инструменты, какcat -vили текстовый редактор с видимостью скрытых символов для проверки файлов.

Убедитесь, что центр сертификации, представленныйmy-tls-secretимеет необходимые разрешения для подписи сертификатов. Некоторым центрам сертификации может быть разрешено подписывать только определенные типы или уровни сертификатов. Это особенно актуально, поскольку в иерархии ЦС имеется несколько уровней.

Увеличьте детализацию журнала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
    ...

На всякий случай проблема может быть связана с глубиной вашей цепочки сертификатов. Хотя это и не распространено, некоторые системы имеют ограничения на глубину цепочки, которую они могут обрабатывать. Если возможно, протестируйте более простую цепочку (меньшее количество уровней), чтобы увидеть, сохраняется ли проблема.

Источник

Похоже, что проблема может быть связана с форматом или содержимым цепочки сертификатов в секрете 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

Дайте мне знать, как это происходит!

Источник
Другие вопросы по тегам