I have to issue a certificate from 10 different locations for the same domain. Each location would work with the same wildcard certificate (*.example.com), but that will hit the rate limit „New Certificates per Exact Set of Identifiers“.
It seems a better plan would be to come up with a way to get the cert in one place, then distribute it to the others. You've come up with a way to circumvent the rate limits, but they're there to prevent abuse of LE's resources, and you're still doing that if you proceed with this plan.
Whether you want to or not, you'd need to in order to get a wildcard cert.
It's up to your DNS host, really--if use of that token is tied to a specific IP address, then you wouldn't be able to use it anywhere else. But in general, it should be possible. In doing so, you're going to be spreading that token around a bit; if it were to be compromised in any way, you'd have to fix it on all of these systems. A better practice would probably be separate tokens for each system--one of them can be revoked, if needed, without affecting operations of the other systems.
This was my first approach. I'm able to distribute the wirdcard certificate to all locations. But I need to install the cert on some pfSense Firewalls and use it for the captive portal. The acme client on the pfSense does that automatically. But I'm not able to replace the certificate over the shell in pfSense. Otherwise a cron-job could to the job.
As these systems are all pfSense firewalls, I don't think this is a problem. If one of them gets compromised, I will have much more problems.
My question was, if there is a potential problem from the letsencrypt side. If two acme clients are requesting a certificate at the same time, could this result in a conflict when the both use the same API Token?
I ask this, because of this:
You can have multiple TXT records in place for the same name. For instance, this might happen if you are validating a challenge for a wildcard and a non-wildcard certificate at the same time. However, you should make sure to clean up old TXT records, because if the response size gets too big Let’s Encrypt will start rejecting it. Challenge Types - Let's Encrypt
Let's Encrypt neither knows nor cares about the API token for your DNS host; that's a matter between you, your DNS host, and your ACME client. If your client is coded very stupidly, it might try to delete all the _acme-challenge.domain TXT records during its "cleanup" cycle, and if it does that, the one request would interfere with the other. Though if that happens, the system for which the challenge failed tries again the next day and succeeds--and in doing so, likely offsets the renewal of that cert by a day, avoiding that specific problem in the future.
I'm not familiar enough with the ACME client that ships with pfSense to say whether this is the case--I wouldn't expect so, but I just don't know.
Mixing different CAs is an option for initial setup
If you do want all your certs using Let's Encrypt, you could do it later, once all of the machines changed to Let's Encrypt, let cron job to its thing.
For everyone who's interested, here's a nice script to import the LE-Certs and CAs into pfSense. So if you manage multiple pfSense, you can issue and deploy the cert on one pfSense and then install it with this script on all others:
Saves LE- Resources and centralizes the Cert management.