No longer able to request or renew certificates since the latest merge about certbot-route53 HOT 10 CLOSED

@jed just tested now and it works great, thanks @jordiclariana!

from certbot-route53.

If I change the printf -v QUERY back to use ends_with it works fine again:

diff --git a/certbot-route53.sh b/certbot-route53.sh
index bf02823..3894b90 100755
--- a/certbot-route53.sh
+++ b/certbot-route53.sh
@@ -19,7 +19,7 @@ if [ -z "${CERTBOT_DOMAIN}" ]; then
 else
   [[ ${CERTBOT_AUTH_OUTPUT} ]] && ACTION="DELETE" || ACTION="UPSERT"

-  printf -v QUERY 'HostedZones[?Name == `%s.`]|[?Config.Privatezone != `false`].Id' "${CERTBOT_DOMAIN}"
+  printf -v QUERY 'HostedZones[?ends_with(`%s.`,Name)]|[?Config.Privatezone != `false`].Id' "${CERTBOT_DOMAIN}"

   HOSTED_ZONE_ID="$(aws route53 list-hosted-zones --query "${QUERY}" --output text)"

from certbot-route53.

@jordiclariana, what do you think?

from certbot-route53.

I understand why it fails. My change makes it work only for domains, not hostnames. some refactor should be changed in order to find out if the --domains exists as a host in a zone or if it is a zone itself.

Give me some time to figure out the solution if you will.

from certbot-route53.

Please, try my proposed PR and let me know if it fixes this.

from certbot-route53.

My change makes it work only for domains, not hostnames.

Out of interest, why would you want this? For HTTPS, you need the CN in the certificate to match the hostname of the web server. Or have Let's Encrypt enabled wildcards? I know they're planning on it, but I hadn't heard that they had. :)

from certbot-route53.

example.com is a domain, but can have a certificate too. So you have to be able to treat domains as certificateable (I don't think that's a word, but anyway). Another reason for my first change is to avoid problems when several zones end the same:

• example.com
• foo.example.com

This was the main reason to get rid of the ends_with. Anything else is collateral.

About wildcards certificates in Letsencrypt you are right, it is planned to be released if I'm not wrong at the end of February, but my PR does not intent to use this new functionality, but I think it can help when it is finally released (although I don't know yet how it is going to be implemented on certbot side).

from certbot-route53.

I'm away from my office today, but I should be able to take the PR for a test tomorrow (Friday) in GMT+11.

from certbot-route53.

example.com is a domain, but can have a certificate too. So you have to be able to treat domains as certificateable

True, but not at the expense of preventing FQDNs from receiving certificates. :) Further, best practice suggests that you should use the SAN field for this, i.e. you'd request a certificate for -d www.domain.com -d domain.com so that a single certificate would be valid for both with and without the www. portion. In this case, ends_with would still be useful.

However, to be honest I've just (re-)discovered acme.sh and I'm replacing all my instances of certbot and certbot-route53 with it so that my mechanism for obtaining Let's Encrypt certificates is unified across all my devices, including all my Ubiquiti gear.

from certbot-route53.

@Djelibeybi, did you have a chance to try #10?

from certbot-route53.