exoscale: fails when issuing certificate for "*.domain.example" and "domain.example"

[TobyGiacometti]

Welcome

• [X] Yes, I'm using a binary release within 2 latest releases.
• [X] Yes, I've searched similar issues on GitHub and didn't find any.
• [X] Yes, I've included all information below (version, config, etc).

What did you expect to see?

ACME DNS-01 challenge succeeds for both *.domain.example and domain.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 the exec 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

```console # paste output here ```

Go environment (if applicable)

```console $ go version && go env # paste output here ```

[ldez]

Hello,

This is a limitation of the Exoscale DNS API

Do you have a link to documentation about that?

[TobyGiacometti]

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.

[ldez]

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

[ldez]

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

[TobyGiacometti]

v2

[pierre-emmanuelJ]

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

[TobyGiacometti]

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

[pierre-emmanuelJ]

@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

[TobyGiacometti]

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.

[ldez]

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.

[TobyGiacometti]

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

https://github.com/go-acme/lego/blob/acd338259d9e8b7b819cdf73b89917ad4a816f6e/providers/dns/exoscale/exoscale.go#L159

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.

[ldez]

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.

[ldez]

PTAL https://github.com/go-acme/lego/pull/2179

[TobyGiacometti]

Thanks for fixing this!