I suspect it was that run.
1 Like
Then... there are two certbots installed ???
2 Likes
Excellent question. 
1 Like
OK, that makes little sense [to me].
2 Likes
The last logs today are from 0.40 version and it was tested with the version 2.4 yesterday in a virtual machine. Apologies for misleading with that.
I hope it helps this comment
Thank you
1 Like
Ok, so we are agreed that both versions have the same problem.
So, it is not a version/certbot problem.
Is there any other way for you to test the route53 credentials?
3 Likes
I have tested it with another domain in the same aws account and didn't give that problem. This is what confuses me I will have another look to it.
1 Like
I will be out for a while so can't try these things on my own Route53 system.
But you could try running the Certbot Route53 script on its own to see if it works that way (probably won't).
It might be easier to try using the acme.sh ACME client. It is a bash script and so its Route53 handler is also that. See the dns_aws.sh script in the dnsapi folder at the github for acme.sh. I am not good with Python so find bash scripts easier to debug.
3 Likes
How would one do that?
3 Likes
On the previous occasions I've seen something like this, it's been because of:
- Wrong AWS account is being used. It's possible for multiple accounts to create Route53 zones for a single domain. However, only one zone will ultimately win out - whichever the domain has its nameservers set to.
- Wrong Route53 zone is being used due to duplicate zones in an account. It's possible for one AWS account to have both a public and private zone resource for the same domain, and this will confuse Certbot. (See this issue).
Because Certbot's Route53 plugin is not erroring out, AWS is indeed writing the zone records to a zone somewhere. It's going to be the wrong zone. What you probably need to do is use --debug-challenges, and while it is paused, open up your AWS account (or use aws-cli) and connect the dots. Find where the resource records have been created and work backwards to see why it's not visible in public DNS.
6 Likes
I'm assuming a lot based on python being an interpretive script language. But, you know it way better than me so if you don't think it's easy then the acme.sh bash version is easier. And, frankly, it just might be worth trying acme.sh anyway for the different Route53 plug-in - just for fun
I figured you could just hardcode the needed variables for the IAM auth and domain names and run it directly. Doesn't that work? The purpose is to prove Route53 and the IAM / Auth is setup right. You know, basic unit-testing to help isolate where this is going wrong. Something seems odd given it works for other domain names.
The acme.sh Route53 script (dns_aws.sh) looks easy enough to do this with. But, I was away until just now and haven't tried it.
EDIT: And, I see _az has now weighed in with a good idea so that is worth trying.
4 Likes
True, but also very modular where modules sometimes can be run as a standalone application, but most often not. In the case of Certbot plugins, they can't be run separately from the main Certbot application: Certbot loads the required functions from the plugin module. I wouldn't know where to begin to use a Certbot plugin as a standalone module.
That would be way easier I believe, yes.
5 Likes
Hello, thanks a lot for your comments all, they are very valuable and they are guiding me in the direction I need to
I am going to have a look to the script now to see any results in there
In regards to this: certbot-dns-route53 - no clear way to handle duplicate zone definitions · Issue #9030 · certbot/certbot · GitHub where a domain associated to various accounts could create issues seems to me the same problem that I am facing at the moment.
B) option to be able to pass in a "domain: resource id" mapping -- this seems like it could be generalized across multiple dns plugins, with the 'id' to be interpreted by the particular plugin.
i.e. allow me to say
--dns_zone_map "{ "example.com' : 'ABCDEF123123123123' }"
to allow explicitly telling the plugin "use this particular zone" instead.
Do you know if it is possible to map more than one hosted zone in that domain as it is a wildcard using *domain?
Thank you very much,
Guille
1 Like
Hello,
I am testing the acme.sh script, would it be something like that?
./acme.sh --issue -d DOMAIN --standalone -d *.DOMAIN
I am trying to understand if it is enough number of flags here as it is a route53 domain.
Thank you for your help,
Guille
I'm not familiar with acme.sh, but I believe this is the standalone plugin like the standalone plugin of Certbot, which is not a DNS plugin. See dnsapi · acmesh-official/acme.sh Wiki · GitHub
4 Likes
Thank you Osiris, looks like the issue was that there was an association to an specific account even it was in many accounts such domain.
So I think the problem is sorted 
Thanks a lot for your help, it was really helpful.
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.