Role does not request second certificated.

[sfrique]

If you use this role for creating a second certificate after creating the first, it does not work.

It does not work because after the creating of the first, ansible doesnt rul the command again:

    args:
      creates: "/etc/letsencrypt/live/{{ letsencrypt_cert_domains[0] }}"

The command is right, but its condition is not.
Here is the command:
/usr/local/share/letsencrypt/env/bin/letsencrypt --agree-tos --text -d domain1.com -d domain2.com --email [email protected] --expand -a webroot --webroot-path /opt/letsencrypt_webroot certonly

But as it only verify for the first domain, the command get skipped.

Is there any work around it? Or it will get fixed?

Thanks

[thefinn93]

Hrm that is problematic. I'm open to suggestions for how people would fix. I'm super busy right now and can't think of a terribly non-dumb way to go about it, but I suspect if it was thought through it would be pretty easy.

[rfleschenberg]

IMHO it is ok to let the user handle this, e.g. by adding a pre_task that removes the existing certificate if desired.

[ryanpineo]

I can think of two ways:

1. Add a new variable that the user can override to force the command to run. e.g. letsencrypt_force_certonly
2. Use openssl to parse the current certificate and if the names on the cert differ than the letsencrypt role config the task gets run.

It may make sense to start with 1. as an easy fix and look into doing 2.

[gagath]

Interesting related certbot issue: certbot/certbot#3396

I have started to write an override mechanism with letsencrypt_force_certonly variable but when recreating certbot sees the files in the archive directory. I am going to continue to dig this way but it might have to delete the whole archive directory (and renewal) for this hack to work.

[popstas]

@thefinn93, maybe would be better to execute certbot for each domain separately? Something like this:

- include: get_cert.yml
  with_items: "{{ letsencrypt_cert_domains }}"

It also step closer to usage separate webroot path for each domain, it will handy for shared hosting servers.

I can create PR's if you don't see disadvantages of this way.

[thefinn93]

I see a major disadvantage: Let's Encrypt's rate limits are based on the number of certificates issued, not the number of domains in the SAN. Doing a cert per FQDN, depending on the number of FQDNs needed, that could eat up the rate limit pretty easily.

That being said, I could see an argument for defining some sort of data structure to describe how the certs should be, then having the role ensure it matches that structure. Something like:

certs:
  - domains:
    - example.org
    - www.example.org
    webroot: /var/www/html/
  - domains:
    - anotherdomain.org
    - www.anotherdomain.org
    - anothersubdomain.anotherdomain.org
    - whatever.net
    webroot: /var/www/anotherdomain

I would be open to a PR that allows this level of flexibility.