Ansible certificate obtaining - just a key of the account?

[germebl]

Hey everyone,

actually building a provisioning playbook which should obtain a SSL certificate with DNS provider.

Here's the task:

    - name: Obtain SSL certificate (DNS Challenge)
      ansible.builtin.shell: |
        set -o errexit
        set -o pipefail

        # Alle *_FILE Dateien in Umgebungsvariablen umwandeln
        for file in /etc/vailor/dnsconfig/*_FILE; do
          if [ -f "$file" ]; then
            varname=$(basename "$file" | sed 's/_FILE$//')  # _FILE entfernen
            export "$varname"="$(cat "$file")"
          fi
        done

        /usr/local/bin/lego --email {{ lego_email }} --dns {{ dns_provider }} \
        --domains {{ hostname }} --path /etc/vailor/certificates run
      args:
        executable: /bin/bash
        creates: "/etc/vailor/certificates"
      when: acme_challenge == "dns"

When running it, i will get this path:

/etc/vailor/certificates/accounts/acme-v02.api.letsencrypt.org/[email protected]/keys

With a file named [email protected] which includes a EC PRIVATE KEY.

Am I misunderstanding something or shouldn't the .key and .crt of the created certificate actually be in the /etc/vailor/certificates/ directory?

Thanks in advance

[ldez]

I'm not sure to understand your question, can you be more precise?

[germebl]

I would likely more to go around this and set a higher DNS record propagation timeout in combination with a general good public dns provider like Cloudflare.

Because we never had a problem with the Authority checking the DNS propagation.

[ldez]

your answer doesn't seem related to your first message 🤔

So it seems like it did not waited long enough for the dns propagation...

The propagation timeout is controlled per DNS provider with xxx_PROPAGATION_TIMEOUT (and xxx_POLLING_INTERVAL).

It would be recommended to set a public nameserver which has the TXT record available fast. Or is there a way to set a higher value of determine the DNS record propagation?

There is no recommendation because the ACME servers (like Let's Encrypt) use their own list of DNS servers to check. Those lists are not public.

For me, the only recommendation is to use several nameservers.
By default, lego uses authoritative nameservers and recursive nameservers.

The propagation timeout is controlled per DNS provider with xxx_PROPAGATION_TIMEOUT (and xxx_POLLING_INTERVAL).

As i hadnt this problem with other acme Clients and Let's Encrypt as authority in the past.

Because mainly, other ACME clients don't check the propagation but they use a sleep.
The lego propagation check is more robust than a sleep.

I try to fine-tune the default values but this is not perfect.

But if you want to use a sleep, I strongly discourage doing that, you can use --dns.propagation-wait

[germebl]

your answer doesn't seem related to your first message 🤔

Because I had no logs thanks to the typo in my debug task (only an RC=0) and I didn't understand why the key was created for the account but not the certificate. It turned out that the /etc/vailor/certificates directory already existed due to testing and my task had the condition that this did not exist in order to execute the command at all. (This is also how the RC=0 came about). I've changed that now from checking the certificates folder to checking if the certificate exists. I thought the folder would be enough cause this is actually just for the cert which is needed for the hostname for services like mailserver etc. and obtain would simply run one time while provisioning the system. The user-based cert provisioning will be handled in other ways (still lego, but other logic). It's just silly if I don't take the testing into account and the folder could already exist as a result - so let's just forget about it again :D

The propagation timeout is controlled per DNS provider with xxx_PROPAGATION_TIMEOUT (and xxx_POLLING_INTERVAL).

So if this is available for all the DNS providers (didnt checked yet) and the CLI flag name is always the xxx in Uppercase, it would be simple for me to override these regardless of which DNS provider the user selects.

is available for all the DNS providers
the CLI flag name is always the xxx in Uppercase

Do you can confirm this faster from knowledge then me checking all provider docs?

But if you want to use a sleep, I strongly discourage doing that, you can use --dns.propagation-wait

Nope, after you explained the difference to me, i know now more as before, why LEGO was a good choice to get with and get rid of the old ones.

[ldez]

This is available for all the DNS providers.

Nope, after you explained the difference to me, i know now more as before, why LEGO was a good choice to get with and get rid of the old ones.

Great!

[ldez]

I hope you enjoy my work, please consider donating or asking your company to do so.
My only source of revenue is donations.
This will be appreciated, thank you ❤️

https://donate.ldez.dev/