exoscale: fails when issuing certificate for "*.domain.example" and "domain.example" about lego HOT 14 CLOSED

Maybe someone at Exoscale can explain the behavior, ping @pierre-emmanuelJ

from lego.

Thanks for reporting the issue, we will take a look on our side and reproduce it, and come back here

from lego.

PTAL #2179

from lego.

Thanks for fixing this!

from lego.

Hello,

This is a limitation of the Exoscale DNS API

Do you have a link to documentation about that?

from lego.

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.

from lego.

@TobyGiacometti which client API are you using: v1, v2, or v3`?

from lego.

v2

from lego.

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

from lego.

@TobyGiacometti I've checked the v2 code, nothing sounds differ from the web interface (Exoscale Portal).
API call is made without any restriction, I think you can close this issue if all good on your side.

Feel free to reopen it if the issue happens again, thank you

from lego.

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 findExistingRecordID currently returns the first TXT record amongst the list of equally named records.

from lego.

Additionally, the cleanup logic must be adjusted as well, because findExistingRecordID currently returns the first TXT record amongst the list of equally named records.

lego calls the same number of times as the number of domains, so it works.

from lego.

@ldez I don't understand why this issue was closed. The Exoscale provider fails as described:

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.

lego calls the same number of times as the number of domains, so it works.

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.

from lego.

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.

from lego.