Добрый день. Пишу роль для автоматизации получения сертификаторв Let's Encrypt. Нормально получаю

wildcard сертификаты. Однако, я получаю сертификаты, где CN = *.example.com и alternate name - список из wildcard: *.example.com, *.1.example.com и т.д. Такой сертификат нормально работает для субдоменов, типа www.example.com. Однако, для example.com (без www), он недействителен.

Использую модули acme_certificate, openssl_csr, openssl_privatekey. Режим челенджа: dns.

Суть такова, что я использую словарь с зонами, где ключи - зоны типа example.com, а значение ключа - список из субдоменов и wildcards.
При формировании CSR через openssl_csr, я задаю common_name=example.com, subject_alt_name= *.example.com, получаю обычный CSR.
Далее, при запуске челенджа, модуль acme_certificate формирует из example.com и *.example.com отдельные TXT записи со своими индивидуальными токенами. Но модуль требует занести их в _acme-challenge.example.com

Получается проблема. Для двух разных записей (example.com и *.example.com) модуль ищет свой токен в одной TXT записи _acme-challenge.example.com. Когда я заношу в ДНС токены, естественно, в запись попадает лишь один токен и челлендж падает.

Отсюда вопрос, как получить wildcard сертификат за один проход, который бы был действителен как для example.com, так и для *.example.com?

А уверены, что он не действителен для доменов example.com?

а ДНС где?

пример для CF https://privatebin.net/?c5ffda0e80688ff4#A7M1ReCrMny3BRxjWjx11LV13vEqmZRpvx5NaK6Vrc2i . могу роль в ЛС скинуть если не понятно будет

да, насколько мне удалось нагуглить сведений (NIC.ru, хабр и остальные стексоверфло)

Хмм, цитата с сайта LE Orders that contain both a base domain and its wildcard equivalent (e.g. *.example.com and example.com) are valid. In that case, there will be two authorization objects in the order for “example.com”, one of which represents the wildcard validation and one of which represents the base domain validation.

Днс у нас локальный, на базе Powerdns. При помощи ansible-модуля URI я заношу TXT запись, а потом при помощи модуля shell вызываю dig до тех пор, пока оба ns1 и ns2 не вернут искомую TXT запись. После успеха продолжается челендж

Уберите этот dig совсем и используйте acme_certificate с until+retries+delay

register: acme_cert_generation_result until: not acme_cert_generation_result.failed retries: 5 delay: 180

я опасаюсь, что в таком случае LE меня забанит за многочисленные обращения. И потом, а чем dig плох? АКМЕ обращается лишь к нашим NS

Меня не банит :)

Цикл проверок на наличие TXT записей в ns2 - name: Validate DNS record lookup shell: "dig +nocmd {{ item.key }} txt +noall +answer +short +nocookie @{{ response_dns_server }}" register: result until: "result.stdout | regex_replace('\"','') in item.value" retries: 10 delay: 30 with_items: "{{ query('dict', sample_com_challenge.challenge_data_dns|default({})) }}"

тем не менее, я пока не понимаю, как это мне поможет)