The challenges are part of the ACME protocol for issuing DV certificates. DV certs are for validating control of a given domain. If you successfully get a .arpa cert that's trusted by everyone, particularly a wildcard cert, you could perform MITM attacks on untold numbers of networks. It's not likely to happen.
You'll probably.need to make your own CA cert, trust it on devices, and issue certificates from it (or a sub CA cert, which you'd then have to bundle with others). If you only do this with a handful of haproxy nodes, the server cert config shouldn't be too hard, but the trust store gets stupid to manage quickly. A lot of software requires its own config for this to work.
The way I handled this issue myself is to make an "internal" subdomain, e.g. "internal.domain.tld", you can then split names between your root zone and a sub zone; this allows issuance of letsencrypt or other dns01 acme issuers to work via DNS challenges. Also useful if you don't want to or cannot do split horizon DNS resolution - you can still make public facing DNS records with private IPs. The biggest risk here is that internal-only services' names can be exposed via certificate transparency logs (CT logs). If you use LE for both internal and external names, you also increase names per domain usage which could have an impact on quotas/API limits.
The challenges are part of the ACME protocol for issuing DV certificates. DV certs are for validating control of a given domain. If you successfully get a .arpa cert that's trusted by everyone, particularly a wildcard cert, you could perform MITM attacks on untold numbers of networks. It's not likely to happen.
You'll probably.need to make your own CA cert, trust it on devices, and issue certificates from it (or a sub CA cert, which you'd then have to bundle with others). If you only do this with a handful of haproxy nodes, the server cert config shouldn't be too hard, but the trust store gets stupid to manage quickly. A lot of software requires its own config for this to work.
The way I handled this issue myself is to make an "internal" subdomain, e.g. "internal.domain.tld", you can then split names between your root zone and a sub zone; this allows issuance of letsencrypt or other dns01 acme issuers to work via DNS challenges. Also useful if you don't want to or cannot do split horizon DNS resolution - you can still make public facing DNS records with private IPs. The biggest risk here is that internal-only services' names can be exposed via certificate transparency logs (CT logs). If you use LE for both internal and external names, you also increase names per domain usage which could have an impact on quotas/API limits.
Good luck with whatever you choose