What types of certificates are supported?

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

The module installs the following ClusterIssuers:

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

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

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

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

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

How to add an additional ClusterIssuer?

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

When is an additional ClusterIssuer required?

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

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

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

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.

Чтобы издать сертификаты на доменное имя через 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.

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

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

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

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

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

1. ClusterIssuer specific to the cloud provider being used.

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

1. В удостоверяющем центре (УЦ), отличном от Let’s Encrypt (в т.ч. в приватном). Поддерживаемые УЦ доступны в документации cert-manager
2. Через 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

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

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.

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

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

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

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.

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

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

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.

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

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

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

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

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.

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

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

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

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

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

1. Then, create the ClusterIssuer resource:

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

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

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

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

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

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

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

• Создать Issuer:

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

• Create a service account and copy its secret reference:

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

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

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

• Create an Issuer:

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

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

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

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

Для использования собственного или промежуточного 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

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

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

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

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

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

• Generate a certificate (if necessary):

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

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

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

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

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

An example of creating a secret with kubectl:

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

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

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

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

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

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 также может быть любым.

You can use any name you like for the secret.

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

• Create a ClusterIssuer using the secret you created earlier:

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

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.

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

You can use any name as your ClusterIssuer name.

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

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

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

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

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

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

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

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

How to secure cert-manager credentials?

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

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:

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

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

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

• Create a simple ClusterIssuer with reference to that secret:

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

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

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

• Order certificates as usual, using created ClusterIssuer:

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

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

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

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

Does the legacy tls-acme annotation work?

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.

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).

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

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

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

How do I check the certificate status?

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

shell

shell kubectl get certificate –all-namespaces

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

NAMESPACE NAME AGE default example-com 13m

How do I get a list of certificates?

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

shell

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

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

text CAA record does not match issuer

The “CAA record does not match issuer” error

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

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.