-
-
Notifications
You must be signed in to change notification settings - Fork 982
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
exoscale: fails when issuing certificate for "*.domain.example" and "domain.example" #2174
Comments
Hello,
Do you have a link to documentation about that? |
I could not find any references to this in the documentation. At least when using Egoscale (which is also what lego's Exoscale DNS provider uses), trying to create a TXT record with the same name as an already existing one triggers an error. However, the Exoscale web interface does allow creation of multiple equally named TXT records. Since the web interface uses the API in the background, it actually does not seem to be an inherent API limitation. |
Maybe someone at Exoscale can explain the behavior, ping @pierre-emmanuelJ |
@TobyGiacometti which client API are you using: |
v2 |
Thanks for reporting the issue, we will take a look on our side and reproduce it, and come back here |
@pierre-emmanuelJ I am now able to create multiple TXT records with the same name and different values. Not sure if you did something, or if I did not test thoroughly enough and only tried creating multiple TXT records with the same name and value (which indeed fails). |
@TobyGiacometti I've checked the v2 code, nothing sounds differ from the web interface (Exoscale Portal). Feel free to reopen it if the issue happens again, thank you |
Thanks for checking @pierre-emmanuelJ! @ldez We can forgo the sequential validation and instead remove the record updating logic from the provider. Additionally, the cleanup logic must be adjusted as well, because |
lego calls the same number of times as the number of domains, so it works. |
@ldez I don't understand why this issue was closed. The Exoscale provider fails as described:
lego/providers/dns/exoscale/exoscale.go Line 159 in acd3382
It won't work in some cases: If multiple instances of lego are running on different hosts and are validating the same domains at the same time, records might get deleted that should not be deleted. |
Using 2 instances of lego to handle certificates on the same domain seems a bad idea and unwanted. The root domain and the wildcard should be handled in the same command. Creating 2 times the certificates for the same domain will not produce the expected behavior because the second call will be evaluated as a renewal and not as a creation of a new certificate. |
PTAL #2179 |
Thanks for fixing this! |
Welcome
What did you expect to see?
ACME DNS-01 challenge succeeds for both
*.domain.example
anddomain.example
and the certificate is issued.What did you see instead?
ACME DNS-01 challenge for one of the domains fails because the Exoscale DNS provider does not create two TXT records (with the same name). Instead, the record for one of the domains is overwritten with the value of the other domain before validation starts.
This is a limitation of the Exoscale DNS API: it does not allow creation of TXT records with the same name. The domains must be validated sequentially just like theexec
provider does it.How do you use lego?
Binary
Reproduction steps
EXOSCALE_API_KEY=<key> EXOSCALE_API_SECRET=<secret> lego --email <email> --dns exoscale --domains <domain> --domains *.<domain> run
Version of lego
lego version 4.16.1 linux/amd64
Logs
# paste output here
Go environment (if applicable)
The text was updated successfully, but these errors were encountered: