jed/certbot-route53

No longer able to request or renew certificates since the latest merge

Djelibeybi opened this issue · 10 comments

Djelibeybi commented

Hi,

With the latest changes, I can't seem to request a certificate for a specific machine. I'm running the following:

# certbot-route53.sh --agree-tos --manual-public-ip-logging-ok --domains hostname.domain.com --email me@mydomain.com

I am hosting my domain.com on Route 53 and before today, this worked just fine and requested a certificate for the machine named hostname.domain.com. Today, it no longer works because it tries to search for hostname.domain.com on Route 53 and fails immediately.

If I use --domains domain.com it works, but creates a certificate with CN=domain.com which will fail validation if used for HTTPS on hostname.domain.com.

Am I doing something wrong?

Djelibeybi commented

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)"
jed commented

@jordiclariana, what do you think?

jordiclariana commented

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.

jordiclariana commented

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

Djelibeybi commented

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

jordiclariana commented

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

Djelibeybi commented

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

Djelibeybi commented

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.

jed commented

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

Djelibeybi commented

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

  • 👍2