Sort the array of domain name duplicates and create the text inputs
I wonder if the fqdn of the server is needed, I alway create a dns entry for it at my registar, but if you miss at least one dns valid name obviously the LE certificate creation will fail
Usually I insert multiple CNAMEs including the server name for at least the primary domain.
It should also be noted that the first FQDN is the one for which the certificate will be issued; the following ones being considered [Subject Alternative Name].
It would also be interesting to know which CNAMEs to always recommend in order to be able to fulfill all possible future requests from NethSever.
I am wondering if either to test a global domain list with let’sencrypt, we could test each domain. Like this we could know what domain is failing the LE test case and display it in the UI
I said this because the button to add all know fqdn could import a lot of false domains, created for tests or deleted from the vhosts list but not from the hosts database.
-d DOMAIN, --domains DOMAIN, --domain DOMAIN
Domain names to apply. For multiple domains you can use multiple -d flags or enter a comma separated list of domains as a parameter. The first domain provided will be the subject CN of the certificate, and all domains will be Subject Alternative Names on the certificate. The first domain will also be used in some software user interfaces and as the file paths for the certificate and related material unless otherwise specified or you already have a certificate with the same name. In the case of a name collision it will append a number like 0001 to the file path name. (default: Ask)
QUESTION:
Will the sort affect the name of the first domain in the list i.e. the subject CN?
It would be good to validate each domain with LE and show which one(s) is(are) failing, but as you say, rate limits are a concern. But to avoid listing domains that just don’t exist publicly, why not just scrub the list against a public DNS host like 1.1.1.1 or 8.8.8.8? That would weed out the test domains and such–if there’s no public A/CNAME record, resolving to a public IP address, you know LE won’t work.
I thing I have another plan, use the -t -d domain1,domain2,..., if you fail to probe the domain against LE, the cli gives back an output with the name of the failed domains.
But you are right if an external dns registar does not redirect to a A record, there is many chances to fail LE however I guess that LE tries to reach the web server to validate that the certificate is really used
If public DNS does not give an A record (or a valid CNAME), it’s nearly certain that LE will fail–the only way it might not would be if, say, Google public DNS is missing a record that exists on the authoritative host (so an authoritative lookup would be better, if practical). As a follow-up, it would be good to validate that the IP address returned matches the (or at least “a”) Red IP address for this server, though this should only warn, not fail (if you’re using Cloudflare for one or more of your domains, DNS will return their IP, not yours). Both of these checks could be done without involving LE (and therefore without affecting any rate limits) at all.
I just saw that for the TXT record of SPF, the “a” parameter specifies which systems have permission to send email and this is where the system server’s FQDN can be used.
Publish a policy : Domains and hosts identify the machines authorized to send email on their behalf. They do this by adding additional records to their existing DNS information: every domain name or host that has an A record or MX record should have an SPF record specifying the policy if it is used either in an email address or as HELO/EHLO argument.
The “ip4” and “a” specify the systems permitted to send messages for the given domain.
A → If the domain name has an address record (A or AAAA) that can be resolved to the sender’s address, it will match.
I agree with Dan: it’s not a problem, it’s an internal already handled by the system.
These are wrong assumptions. I might have a valid domain pointing to a machine which is not used as virtualhost.
I tend to agree with this but it could introduce some regressions. I think there is no a valid external DNS to query: the propagation of a record could be slow. Also, you do not know which kind of query the ACME authority is going to do.
Even if you go searching for an authoritative answer, you could encounter problem if there is a DNS proxy somewhere (often inside the router or in the ISP network).
In the end, I think that @stephdl proposal to parse the command output is the safes one, even if not elegant.
Yes, we do, at least to a close-enough approximation–it’s going to ask for an AAAA or A record for the FQDN in question, or for a CNAME that resolves to an AAAA or A. And since Neth still doesn’t support IPv6, we’re only interested in A records.
I would like to add something more to the validator, when you hit the rate limit, the error message is obvious, I want to display an error message in that meaning, please you have to wait 3 hours or change your IP
so in short:
display a warning on the rate limit
display what domain is failing
display when you hit the rate limit
An unexpected error occurred:
There were too many requests of a given type :: Error creating new account :: too many registrations for this IP: see https://letsencrypt.org/docs/rate-limits/
