route53.v2.0.7.315 only works for second level aws zone files

[TheBigBear]

Issue description

when trying to create ssl certificates for a sub-domain.domain.com or even a *.sub-domain.domain.com the route 53 plugin complains that it can't find a zone for domain.com, but there is not necessarily a domain for domain.com. As it is perfectly OK to have delegation and separation of zone files in bigger companies and only have access to uk.domain.com as my root or aws zone file.

so uk.domain.com is its own aws zone file and it won't contain any domain.com records as the root of this domain is actually uk.domain.com.

Can this wrong assumption please be fixed in the route53 code, please?

Steps to reproduce

C:\Program Files\win-acme>wacs --host uk-wsus.uk.mymotherdomain.com --validation route53 --validationmode dns-01 --route53accesskeyid xyz --route53secretaccesskey xyz --target manual
gives the following error

[EROR] Can't find hosted zone for domain mymotherdomain.com

Reason is that the aws zone and root file is only for zone uk.mymotherdomain.com and NOT for mymotherdomain.com

[WouterTinus]

I cooked up a little patch, but I can't test it because I don't use AWS myself. Please try the build:

https://ci.appveyor.com/project/WouterTinus/win-acme-s8t9q/builds/25142114/artifacts

[TheBigBear]

Hi Wouter, Thank you so much. Yes it is now working, but is giving some wrong diagnostics along the way. it now says:

[INFO] Authorize identifier: uk-gw.mydomain.com [INFO] Authorizing uk-gw.mydomain.com using dns-01 validation (Route53) [INFO] Creating TXT record _acme-challenge.uk-gw.mydomain.com with value IbtQsP<rest-cut-off> [INFO] Waiting for DNS changes propagation [INFO] Answer should now be available at _acme-challenge.uk-gw.mydomain.com [WARN] Preliminary validation failed: no TXT records found [INFO] Will retry in 30 seconds (retry 1/5)... [WARN] Preliminary validation failed: no TXT records found [INFO] Will retry in 30 seconds (retry 2/5)... [WARN] Preliminary validation failed: no TXT records found [INFO] Will retry in 30 seconds (retry 3/5)... [WARN] Preliminary validation failed: no TXT records found [INFO] Will retry in 30 seconds (retry 4/5)... [WARN] Preliminary validation failed: no TXT records found [INFO] Will retry in 30 seconds (retry 5/5)... [WARN] Preliminary validation failed: no TXT records found [INFO] It looks like validation is going to fail, but we will try now anyway [INFO] Authorization result: valid [INFO] Deleting TXT record _acme-challenge.uk-gw.mydomain.com with value IbtQsP<rest-cut-off> [INFO] Requesting certificate [Manual] uk-gw.mydomain.com [INFO] Store with CertificateStore... [INFO] Installing certificate in the certificate store [INFO] Adding certificate [Manual] uk-gw.mydomain.com 2019/6/10 10:48:57 to soo [INFO] Installing with None...

If I check in aws then the new and correct TXT record is created even before the first 30 second check window and persists throughout until it is being deleted in the end after the 5th failed check. But evidently the action taken when it reports: "[INFO] It looks like validation is going to fail, but we will try now anyway” must be different, because it finds the vlcdi challenge and correctly reports that it did and then goes on to delete the dns challenge record.

[INFO] Authorization result: valid [INFO] Deleting TXT record _acme-challenge.uk-gw.mydomain.com with value IbtQsP<rest-cut-off>

So thank you so much for the little patch it now works for me. If you have another version you would like me to test, let me know. Regards,

…

On 8 Jun 2019, at 20:36, Wouter Tinus ***@***.***> wrote: I cooked up a little patch, but I can't test it because I don't use AWS myself. Please try the build: https://ci.appveyor.com/project/WouterTinus/win-acme-s8t9q/builds/25142069/artifacts <https://ci.appveyor.com/project/WouterTinus/win-acme-s8t9q/builds/25142069/artifacts> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1143>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADTAQP5OJHG4HLQRRTQFO3PZP33NANCNFSM4HWHK5QA>.

[WouterTinus]

The preliminary validation is a check done by this program to warn the user about possible mistakes or synchronization issues, the actual validation is done by Let's Encrypt in a completely independent and much more sophisticated way.

From your description and log it looks like there is some bug that causes the pre-validation to fail when it shouldn't. It would be helpful if you could create a TXT record on this domain and share its name and value with us, so that we can trace that issue.

[TheBigBear]

Dear Wouter, Thanks. As requested. Here is a TXT record on this domain: _acme-challenge.www.portal .uk.om.org. value = "DDiuH2iKURl7-i3cXXVeJBI83gzzqcDWRAj3Sk3mYGw" or at one level higher up _acme-challenge.gw-qui .uk.om.org. value = "LQSfSQIAf8IqH-gh4WGWLDbyXizu-jWEtp7rtxgUR-U" Hope that helps. Thanks for looking at this. Regards.

…

On 11 Jun 2019, at 13:01, Wouter Tinus ***@***.***> wrote: The preliminary validation is a check done by this program to warn the user about possible mistakes or synchronization issues, the actual validation is done by Let's Encrypt in a completely independent and much more sophisticated way. From your description and log it looks like there is some bug that causes the pre-validation to fail when it shouldn't. It would be helpful if you could create a TXT record on this domain and share its name and value with us, so that we can trace that issue. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1143>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADTAQPFS4INZ54CXHH7LILPZ6AYRANCNFSM4HWHK5QA>.

[WouterTinus]

I checked both of those records and they are currently resolved properly by the program, so the pre-validation was also supposed to be successful.

Perhaps timing is a factor here, because by now the records will have had plenty of time to propagate, which may not have been the case yet during those first couple of minutes. Would you mind do a run with the --verbose switch? That should give more insight into which DNS servers are queried etc.

[TheBigBear]

Hi Wouter, OK, the ```—verbose``` switch was a good idea. ;-) The records are there, right away, no timing issue, but the client checks the wrong name servers . ;-) It checks the name servers of ```om.org``` and not of the specified downlevel ```uk.om.org``` . so the checking code makes the ’same’ mistake that you tried to fix in the first place. Trust this helps. Thanks for your help.

…

On 23 Jun 2019, at 11:56, Wouter Tinus ***@***.***> wrote: I checked both of those records and they are currently resolved properly by the program, so the pre-validation was also supposed to be successful. Perhaps timing is a factor here, because by now the records will have had plenty of time to propagate, which may not have been the case yet during those first couple of minutes. Would you mind do a run with the --verbose switch? That should give more insight into which DNS servers are queried etc. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1143>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADTAQP42ON4RUPHBCQTTZLP35CFTANCNFSM4HWHK5QA>.

[WouterTinus]

Good catch, there was a bug in the PreValidation code that effectively caused the logic that determines the authoritative name servers for the sub domain to be bypassed. This should also be fixed with the next release. You can test the latest CI build if you like: https://ci.appveyor.com/project/WouterTinus/win-acme-s8t9q/build/artifacts

[WouterTinus]

This has been released in version 2.0.8