Какие виды сертификатов поддерживаются?

What types of certificates are supported?

На данный момент модуль устанавливает следующие ClusterIssuer:

• letsencrypt
• letsencrypt-staging
• selfsigned
• selfsigned-no-trust

The module installs the following ClusterIssuers:

• letsencrypt
• letsencrypt-staging
• selfsigned
• selfsigned-no-trust

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

If you need support for other types of certificates, you can add them yourself.

Как добавить дополнительный ClusterIssuer?

How to add an additional ClusterIssuer?

В каких случаях требуется дополнительный ClusterIssuer?

When is an additional ClusterIssuer required?

В стандартной поставке присутствуют ClusterIssuer, издающие либо сертификаты из доверенного публичного удостоверяющего центра Let’s Encrypt, либо самоподписанные сертификаты.

The standard delivery set includes ClusterIssuer that issues certificates from the trusted public certificate authority Let’s Encrypt or issues self-signed certificates.

Чтобы издать сертификаты на доменное имя через Let’s Encrypt, сервис требует осуществить подтверждение владения доменом. Cert-manager поддерживает несколько методов для такого подтверждения при использовании ACME(Automated Certificate Management Environment):

• HTTP-01 — cert-manager создаст временный Pod в кластере, который будет слушать на определенном URL для подтверждения владения доменом. Для его работы необходимо иметь возможность направлять внешний трафик на этот Pod, обычно через Ingress.
• DNS-01 — cert-manager делает TXT-запись в DNS для подтверждения владения доменом. У cert-manager есть встроенная поддержка популярных провайдеров DNS: AWS Route53, Google Cloud DNS, Cloudflare и т.д. Полный перечень доступен в документации cert-manager.

To issue certificates for a domain name via Let’s Encrypt, the service requires that you verify domain ownership. The cert-manager supports several methods for verifying domain ownership when using ACME (Automated Certificate Management Environment):

• HTTP-01 - when using this method cert-manager will create a temporary Pod in the cluster that will listen on a specific URL to verify domain ownership. For it to work, you must be able to direct external traffic to this Pod, usually via Ingress.
• DNS-01 - when using this method cert-manager makes a TXT record in DNS to verify domain ownership. The cert-manager has built-in support for popular DNS providers: AWS Route53, Google Cloud DNS, Cloudflare, and others.

Метод HTTP-01 не поддерживает выпуск wildcard сертификатов.

The HTTP-01 method does not support issuing wildcard certificates.

Поставляемые ClusterIssuers, издающие сертификаты через Let’s Encrypt, делятся на два типа:

1. ClusterIssuer, специфичные для используемого cloud-провайдера.
   Добавляются автоматически, при заполнении настроек модуля связанных с cloud-провайдером. Поддерживают метод DNS-01.
   • clouddns
   • cloudflare
   • digitalocean
   • route53
2. ClusterIssuer использующие метод HTTP-01.
   Добавляются автоматически, если их создание не отключено в настройках модуля.
   • letsencrypt
   • letsencrypt-staging

The ClusterIssuers in standard delivery set that issue certificates via Let’s Encrypt are divided into two types:

Таким образом, дополнительный ClusterIssuer может потребоваться в случаях издания сертификатов:

1. В удостоверяющем центре (УЦ), отличном от Let’s Encrypt (в т.ч. в приватном). Поддерживаемые УЦ доступны в документации cert-manager
2. Через Let’s Encrypt с помощью метода DNS-01 через сторонний провайдер.

1. ClusterIssuer specific to the cloud provider being used.

Как добавить дополнительный ClusterIssuer, использующий Let’s Encrypt и метод подтверждения DNS-01?

Added automatically when filling in the module settings associated with the cloud provider.
These ClusterIssuers support the DNS-01 method.

• clouddns
• cloudflare
• digitalocean
• route53
  1. ClusterIssuers using the HTTP-01 method. Added automatically unless their creation is disabled in the module settings.
• letsencrypt
• letsencrypt-staging

Для подтверждения владения доменом через Let’s Encrypt с помощью метода DNS-01 требуется настроить возможность создания TXT-записей в публичном DNS.

In this way, an additional ClusterIssuer may be required in the following cases:

1. Certificates need to be issued in a CA other than Let’s Encrypt (including a private one). Supported CAs are available in the cert-manager documentation
2. Certificates need to be issued via Let’s Encrypt using the DNS-01 method via a third-party provider.

У cert-manager есть поддержка механизмов для создания TXT-записей в некоторых популярных DNS: AzureDNS, Cloudflare, Google Cloud DNS и т.д.
Полный перечень доступен в документации cert-manager.

How to add an additional ClusterIssuer using Let’s Encrypt and DNS-01 verification method?

Модуль автоматически создает ClusterIssuer поддерживаемых cloud-провайдеров, при заполнении настроек модуля связанных с используемым облаком.
При необходимости можно создать такие ClusterIssuer самостоятельно.

To verify domain ownership via Let’s Encrypt using the DNS-01 method, you need to configure the ability to create TXT records in a public DNS.

Пример использования AWS Route53 доступен в разделе Как защитить учетные данные cert-manager.
Актуальный перечень всех возможных для создания ClusterIssuer доступен в шаблонах модуля.

cert-manager has support for mechanisms for creating TXT records in some popular DNS: AzureDNS, Cloudflare, Google Cloud DNS, etc.
The full list is available in the cert-manager documentation.

Использование сторонних DNS-провайдеров реализуется через метод webhook.
Когда cert-manager выполняет вызов ACME DNS01, он отправляет запрос на вебхук-сервер, который затем выполняет нужные операции для обновления записи DNS.
При использовании данного метода требуется разместить сервис, который будет обрабатывать хук и осуществлять создание TXT-записи в DNS-провайдере.

The module automatically creates ClusterIssuer of supported cloud providers when filling in the module settings related to the cloud used.
If necessary, you can create such ClusterIssuer yourself.

В качестве примера рассмотрим использование сервиса Yandex Cloud DNS.

An example of using AWS Route53 is available in the section How to protect cert-manager credentials.
The list of all possible ClusterIssuers that can be created is available in the module templates.

1. Для обработки вебхука предварительно разместите в кластере сервис Yandex Cloud DNS ACME webhook согласно официальной документации.

Using third-party DNS providers is implemented via the webhook method.

1. Затем создайте ресурс ClusterIssuer:

When cert-manager makes an ACME DNS01 call, it sends a request to the webhook server, which then performs the necessary operations to update the DNS record.
When using this method, you need to place a service that will process the hook and create a TXT record in the DNS provider.

yaml apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: yc-clusterissuer namespace: default spec: acme: Вы должны заменить этот адрес электронной почты на свой собственный. Let’s Encrypt будет использовать его, чтобы связаться с вами по поводу истекающих сертификатов и вопросов, связанных с вашей учетной записью. email: your@email.com server: https://acme-staging-v02.api.letsencrypt.org/directory privateKeySecretRef: Ресурс секретов, который будет использоваться для хранения закрытого ключа аккаунта. name: secret-ref solvers:

• dns01: webhook: config: Идентификатор папки, в которой расположена DNS-зона folder: Это секрет, используемый для доступа к учетной записи сервиса serviceAccountSecretRef: name: cert-manager-secret key: iamkey.json groupName: acme.cloud.yandex.com solverName: yandex-cloud-dns

As an example, let’s consider using the Yandex Cloud DNS service.

Как добавить дополнительный Issuer и ClusterIssuer, использующий HashiСorp Vault для выпуска сертификатов?

1. To process the webhook, first place the Yandex Cloud DNS ACME webhook service in the cluster according to the official documentation

Для выпуска сертификатов с помощью HashiСorp Vault, можете использовать инструкцию.

1. Then, create the ClusterIssuer resource:

После конфигурации PKI и включения авторизации в Kubernetes, нужно:

• Создать ServiceAccount и скопировать ссылку на его Secret:

yaml apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: yc-clusterissuer namespace: default spec: acme: You must replace this email address with your own. Let’s Encrypt will use this to contact you about expiring certificates, and issues related to your account. email: your@email.com server: https://acme-staging-v02.api.letsencrypt.org/directory privateKeySecretRef: Secret resource that will be used to store the account’s private key. name: secret-ref solvers:

• dns01: webhook: config: The ID of the folder where dns-zone located in folder: This is the secret used to access the service account serviceAccountSecretRef: name: cert-manager-secret key: iamkey.json groupName: acme.cloud.yandex.com solverName: yandex-cloud-dns

shell kubectl create serviceaccount issuer ISSUER_SECRET_REF=$(kubectl get serviceaccount issuer -o json | jq -r “.secrets[].name”)

How to add an additional Issuer and ClusterIssuer using HashiCorp Vault to issue certificates?

• Создать Issuer:

You can use this manual for configuring certificate issuance using Vault.

shell kubectl apply -f - «EOF apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: vault-issuer namespace: default spec: vault: Если Vault разворачивался по вышеуказанной инструкции, в этом месте в инструкции опечатка. server: http://vault.default.svc.cluster.local:8200 Указывается на этапе конфигурации PKI. path: pki/sign/example-dot-com auth: kubernetes: mountPath: /v1/auth/kubernetes role: issuer secretRef: name: $ISSUER_SECRET_REF key: token EOF

After configuring PKI and enabling Kubernetes authorization, you have to:

• Create a service account and copy its secret reference:

• Создать ресурс Certificate для получения TLS-сертификата, подписанного CA Vault:

shell kubectl create serviceaccount issuer ISSUER_SECRET_REF=$(kubectl get serviceaccount issuer -o json | jq -r “.secrets[].name”)

shell kubectl apply -f - «EOF apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: example-com namespace: default spec: secretName: example-com-tls issuerRef: name: vault-issuer Домены указываются на этапе конфигурации PKI в Vault. commonName: www.example.com dnsNames:

• www.example.com EOF

• Create an Issuer:

Как добавить ClusterIssuer, использующий свой или промежуточный CA для заказа сертификатов?

shell kubectl apply -f - «EOF apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: vault-issuer namespace: default spec: vault: HashiCorp instruction has mistype here server: http://vault.default.svc.cluster.local:8200 path: pki/sign/example-dot-com # configure in pki setup step auth: kubernetes: mountPath: /v1/auth/kubernetes role: issuer secretRef: name: $ISSUER_SECRET_REF key: token EOF

Для использования собственного или промежуточного CA:

• Create a Certificate resource, to get a TLS certificate, which is issued by Vault CA:

• Сгенерируйте сертификат (при необходимости):

shell kubectl apply -f - «EOF apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: example-com namespace: default spec: secretName: example-com-tls issuerRef: name: vault-issuer domains are set on PKI setup commonName: www.example.com dnsNames:

• www.example.com EOF

shell openssl genrsa -out rootCAKey.pem 2048 openssl req -x509 -sha256 -new -nodes -key rootCAKey.pem -days 3650 -out rootCACert.pem

How to add ClusterIssuer using its own or intermediate CA to to issue certificates?

• В пространстве имён d8-cert-manager создайте секрет, содержащий данные файлов сертификатов. Пример создания секрета с помощью команды kubectl:

Follow the steps below to use a custom or interim CA:

shell kubectl create secret tls internal-ca-key-pair -n d8-cert-manager –key=”rootCAKey.pem” –cert=”rootCACert.pem”

• Generate a certificate (if necessary):

Пример создания секрета из YAML-файла (содержимое файлов сертификатов должно быть закодировано в Base64):

shell openssl genrsa -out rootCAKey.pem 2048 openssl req -x509 -sha256 -new -nodes -key rootCAKey.pem -days 3650 -out rootCACert.pem

yaml apiVersion: v1 data: tls.crt: <результат команды cat rootCACert.pem | base64 -w0> tls.key: <результат команды cat rootCAKey.pem | base64 -w0> kind: Secret metadata: name: internal-ca-key-pair namespace: d8-cert-manager type: Opaque

• In the d8-cert-manager namespace, create a secret containing certificate file data.

Имя секрета может быть любым.

An example of creating a secret with kubectl:

• Создайте ClusterIssuer из созданного секрета:

shell kubectl create secret tls internal-ca-key-pair -n d8-cert-manager –key=”rootCAKey.pem” –cert=”rootCACert.pem”

yaml apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: inter-ca spec: ca: secretName: internal-ca-key-pair # Имя созданного секрета.

An example of creating a secret from a YAML file (the contents of the certificate files must be Base64-encoded):

Имя ClusterIssuer также может быть любым.

yaml apiVersion: v1 data: tls.crt: <OUTPUT OF cat rootCACert.pem | base64 -w0> tls.key: <OUTPUT OF cat rootCAKey.pem | base64 -w0> kind: Secret metadata: name: internal-ca-key-pair namespace: d8-cert-manager type: Opaque

Теперь можно использовать созданный ClusterIssuer для получения сертификатов для всех компонентов Deckhouse или конкретного компонента.

You can use any name you like for the secret.

Например, чтобы использовать ClusterIssuer для получения сертификатов для всех компонентов Deckhouse, укажите его имя в глобальном параметре clusterIssuerName (kubectl edit mc global):

• Create a ClusterIssuer using the secret you created earlier:

yaml spec: settings: modules: https: certManager: clusterIssuerName: inter-ca mode: CertManager publicDomainTemplate: ‘%s.' version: 1

yaml apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: inter-ca spec: ca: secretName: internal-ca-key-pair # Name of the secret you created earlier.

Как защитить учетные данные cert-manager?

You can use any name as your ClusterIssuer name.

Если вы не хотите хранить учетные данные конфигурации Deckhouse (например, по соображениям безопасности), можете создать свой собственный ClusterIssuer / Issuer.

You can now use the created ClusterIssuer to issue certificates for all Deckhouse components or a particular component.

Пример создания собственного ClusterIssuer для сервиса route53:

• Создайте Secret с учетными данными:

For example, to issue certificates for all Deckhouse components, specify the ClusterIssuer name in the ClusterIssuerName global parameter (kubectl edit mc global):

shell kubectl apply -f - «EOF apiVersion: v1 kind: Secret type: Opaque metadata: name: route53 namespace: default data: secret-access-key: {{ “MY-AWS-ACCESS-KEY-TOKEN” | b64enc | quote }} EOF

yaml spec: settings: modules: https: certManager: clusterIssuerName: inter-ca mode: CertManager publicDomainTemplate: ‘%s.' version: 1

• Создайте простой ClusterIssuer со ссылкой на этот Secret:

How to secure cert-manager credentials?

shell kubectl apply -f - «EOF apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: route53 namespace: default spec: acme: server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: route53-tls-key solvers:

• dns01: route53: region: us-east-1 accessKeyID: {{ “MY-AWS-ACCESS-KEY-ID” }} secretAccessKeySecretRef: name: route53 key: secret-access-key EOF

If you don’t want to store credentials in the Deckhouse configuration (security reasons, for example), feel free to create your own ClusterIssuer / Issuer. For example, you can create your own ClusterIssuer for a route53 service in this way:

• Create a Secret with credentials:

• Закажите сертификаты как обычно, используя созданный ClusterIssuer:

shell kubectl apply -f - «EOF apiVersion: v1 kind: Secret type: Opaque metadata: name: route53 namespace: default data: secret-access-key: {{ “MY-AWS-ACCESS-KEY-TOKEN” | b64enc | quote }} EOF

shell kubectl apply -f - «EOF apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: example-com namespace: default spec: secretName: example-com-tls issuerRef: name: route53 commonName: www.example.com dnsNames:

• www.example.com EOF

• Create a simple ClusterIssuer with reference to that secret:

Работает ли старая аннотация TLS-acme?

shell kubectl apply -f - «EOF apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: route53 namespace: default spec: acme: server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: route53-tls-key solvers:

• dns01: route53: region: us-east-1 accessKeyID: {{ “MY-AWS-ACCESS-KEY-ID” }} secretAccessKeySecretRef: name: route53 key: secret-access-key EOF

Да, работает. Специальный компонент cert-manager-ingress-shim видит эти аннотации и на их основании автоматически создает ресурсы Certificate (в тех же namespaces, что и Ingress-ресурсы с аннотациями).

• Order certificates as usual, using created ClusterIssuer:

Важно! При использовании аннотации ресурс Certificate создается «прилинкованным» к существующему Ingress-ресурсу, и для прохождения Challenge НЕ создается отдельный Ingress, а вносятся дополнительные записи в существующий. Это означает, что если на основном Ingress’е настроена аутентификация или whitelist — ничего не выйдет. Лучше не использовать аннотацию и переходить на ресурс Certificate.

Важно! При переходе с аннотации на ресурс Certificate нужно удалить ресурс Certificate, который был создан по аннотации. Иначе по обоим ресурсам Certificate будет обновляться один Secret, и это может привести к достижению лимита запросов Let’s Encrypt.

shell kubectl apply -f - «EOF apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: example-com namespace: default spec: secretName: example-com-tls issuerRef: name: route53 commonName: www.example.com dnsNames:

• www.example.com EOF

yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: kubernetes.io/tls-acme: “true” # Аннотация. name: example-com namespace: default spec: ingressClassName: nginx rules:

• host: example.com http: paths:
• backend: service: name: site port: number: 80 path: / pathType: ImplementationSpecific
• host: www.example.com # Дополнительный домен. http: paths:
• backend: service: name: site port: number: 80 path: / pathType: ImplementationSpecific
• host: admin.example.com # Еще один дополнительный домен. http: paths:
• backend: service: name: site port: number: 80 path: / pathType: ImplementationSpecific tls:
• hosts:
• example.com
• www.example.com # Дополнительный домен.
• admin.example.com # Еще один дополнительный домен. secretName: example-com-tls # Имя для Certificate и Secret.

Does the legacy tls-acme annotation work?

Как посмотреть состояние сертификата?

Yes, it works! The dedicated component (cert-manager-ingress-shim) automatically creates Certificate resources based on these annotations (in the same namespaces as those of Ingress resources with annotations). HashiCorp

Caution! The Certificate for a particular annotation is linked to the existing Ingress resource. The additional records are put into the existing Ingress resource instead of creating a separate one. Thus, the process will fail if authentication or whitelist is set for the primary Ingress. In this case, you shouldn’t use the annotation; use the Certificate instead.

Caution! If you switched to the Certificate instead of annotation, then you need to delete the annotation-based Certificate. Otherwise, the same Secret will be updated for both Certificates (this may lead to exceeding the Let’s Encrypt limits).

shell kubectl -n default describe certificate example-com … Status: Acme: Authorizations: Account: https://acme-v01.api.letsencrypt.org/acme/reg/22442061 Domain: example.com Uri: https://acme-v01.api.letsencrypt.org/acme/challenge/qJA9MGCZnUnVjAgxhoxONvDnKAsPatRILJ4n0lJ7MMY/4062050823 Account: https://acme-v01.api.letsencrypt.org/acme/reg/22442061 Domain: admin.example.com Uri: https://acme-v01.api.letsencrypt.org/acme/challenge/pW2tFKLBDTll2Gx8UBqmEl846x5W-YpBs8a4HqstJK8/4062050808 Account: https://acme-v01.api.letsencrypt.org/acme/reg/22442061 Domain: www.example.com Uri: https://acme-v01.api.letsencrypt.org/acme/challenge/LaZJMM9_OKcTYbEThjT3oLtwgpkNfbHVdl8Dz-yypx8/4062050792 Conditions: Last Transition Time: 2018-04-02T18:01:04Z Message: Certificate issued successfully Reason: CertIssueSuccess Status: True Type: Ready Events: Type Reason Age From Message —- —— —- —- ——- Normal PrepareCertificate 1m cert-manager-controller Preparing certificate with issuer Normal PresentChallenge 1m cert-manager-controller Presenting http-01 challenge for domain example.com Normal PresentChallenge 1m cert-manager-controller Presenting http-01 challenge for domain www.example.com Normal PresentChallenge 1m cert-manager-controller Presenting http-01 challenge for domain admin.example.com Normal SelfCheck 1m cert-manager-controller Performing self-check for domain admin.example.com Normal SelfCheck 1m cert-manager-controller Performing self-check for domain example.com Normal SelfCheck 1m cert-manager-controller Performing self-check for domain www.example.com Normal ObtainAuthorization 55s cert-manager-controller Obtained authorization for domain example.com Normal ObtainAuthorization 54s cert-manager-controller Obtained authorization for domain admin.example.com Normal ObtainAuthorization 53s cert-manager-controller Obtained authorization for domain www.example.com

yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: kubernetes.io/tls-acme: “true” # The annotation. name: example-com namespace: default spec: ingressClassName: nginx rules:

• host: example.com http: paths:
• backend: service: name: site port: number: 80 path: / pathType: ImplementationSpecific
• host: www.example.com # The additional domain http: paths:
• backend: service: name: site port: number: 80 path: / pathType: ImplementationSpecific
• host: admin.example.com # Another additional domain http: paths:
• backend: service: name: site port: number: 80 path: / pathType: ImplementationSpecific tls:
• hosts:
• example.com
• www.example.com # The additional domain
• admin.example.com # Another additional domain secretName: example-com-tls # The name of the certificate and secret

Как получить список сертификатов?

How do I check the certificate status?

shell kubectl get certificate –all-namespaces

shell

NAMESPACE NAME AGE default example-com 13m

kubectl -n default describe certificate example-com … Status: Acme: Authorizations: Account: https://acme-v01.api.letsencrypt.org/acme/reg/22442061 Domain: example.com Uri: https://acme-v01.api.letsencrypt.org/acme/challenge/qJA9MGCZnUnVjAgxhoxONvDnKAsPatRILJ4n0lJ7MMY/4062050823 Account: https://acme-v01.api.letsencrypt.org/acme/reg/22442061 Domain: admin.example.com Uri: https://acme-v01.api.letsencrypt.org/acme/challenge/pW2tFKLBDTll2Gx8UBqmEl846x5W-YpBs8a4HqstJK8/4062050808 Account: https://acme-v01.api.letsencrypt.org/acme/reg/22442061 Domain: www.example.com Uri: https://acme-v01.api.letsencrypt.org/acme/challenge/LaZJMM9_OKcTYbEThjT3oLtwgpkNfbHVdl8Dz-yypx8/4062050792 Conditions: Last Transition Time: 2018-04-02T18:01:04Z Message: Certificate issued successfully Reason: CertIssueSuccess Status: True Type: Ready Events: Type Reason Age From Message —- —— —- —- ——- Normal PrepareCertificate 1m cert-manager-controller Preparing certificate with issuer Normal PresentChallenge 1m cert-manager-controller Presenting http-01 challenge for domain example.com Normal PresentChallenge 1m cert-manager-controller Presenting http-01 challenge for domain www.example.com Normal PresentChallenge 1m cert-manager-controller Presenting http-01 challenge for domain admin.example.com Normal SelfCheck 1m cert-manager-controller Performing self-check for domain admin.example.com Normal SelfCheck 1m cert-manager-controller Performing self-check for domain example.com Normal SelfCheck 1m cert-manager-controller Performing self-check for domain www.example.com Normal ObtainAuthorization 55s cert-manager-controller Obtained authorization for domain example.com Normal ObtainAuthorization 54s cert-manager-controller Obtained authorization for domain admin.example.com Normal ObtainAuthorization 53s cert-manager-controller Obtained authorization for domain www.example.com

Что делать, если появляется ошибка: CAA record does not match issuer?

How do I get a list of certificates?

Если cert-manager не может заказать сертификаты с ошибкой:

shell

text CAA record does not match issuer

kubectl get certificate –all-namespaces NAMESPACE NAME AGE default example-com 13m

то необходимо проверить CAA (Certificate Authority Authorization) DNS-запись у домена, для которого заказывается сертификат. Если вы хотите использовать Let’s Encrypt-сертификаты, у домена должна быть CAA-запись: issue "letsencrypt.org". Подробнее про CAA можно почитать в документации Let’s Encrypt.

The “CAA record does not match issuer” error

Suppose cert-manager gets the following error when trying to provide a certificate:

text CAA record does not match issuer

In this case, you have to check the CAA (Certificate Authority Authorization) DNS record of the domain for which the certificate is intended. For Let’s Encrypt certificates, the domain must have the issue "letsencrypt.org" CAA record. You can read more about CAA in the Let’s Encrypt documentation.