The requested path will always be http://example.org/.well-known/acme-challenge/random_token for validating example.org, --webroot specifies the document root for where to create that path.
Then add an exception for .well-known/acme-challenge.
At least not for the beta. There's some prospect that the limits will be raised after the beta anyhow. Please keep in mind that the limit is per domain according to the public suffix list. So you can only request five certificates for example.org within seven days, but after you hit that limit you can still request five more for example.com and so on. Also notice that you can put up to 100 SANs into a single certificate, so you can have a single certificate valid for foo00.example.org up to foo99.example.org.
Yes, point the client at https://acme-staging.api.letsencrypt.org/directory via the --server option. It will issue invalid certificates but has very high rate limits.
1.) Register an account. This is effectively just associating a public key with an email address. If you would share the keypair of an account to all machines you wouldn’t need to create new accounts, but that’s not really needed as there’s no constraint on how many accounts with the same email address you create.
2.) Validate hostnames. This associates hostnames to an account for which its allowed to issue certificates. The same hostname can be associated to multiple accounts. Here the challenges are used, like creating a file on a webserver or hosting a HTTPS server that responds with self signed certificates for specific names.
3.) Request a certificate for one or more of the successfully validated hostnames. A certificate can be valid for up to 100 hostnames. The certificate is associated to the account in order to send reminder emails and such, but it doesn’t bind a domain or hostname to a specific account either, other accounts can still get a certificate for the same one given they successfully validated it. Renewal is technically the same as this, simply a new certificate is issued.
The 10 registrations per IP per 3 hours limit applies to the first step. Once you have an account keypair successfully submitted you don’t need to do it again. Only successful registrations count into the limit.
In the above I said hostname but really meant FQDN, www.example.org, www.example.com and example.com are distinct in that point of view. However when it comes to understanding the 5 issuances per domain per 7 days limit, we first need to understand that www.example.com and example.com have the same domain according to the public suffix list, namely example.com. Likewise www.example.org has the domain example.org. The limit prevents you from completing step 3 if there were already 5 certificates containing any hostname with any of the same domains in the current request issued within the last 7 days. Revocation of any of those previous certificates does not lower the count.
So picking up the last example, say you successfully requested 2 certificates for for example.com, 2 for www.example.com and example.com and 1 for example.com, www.example.com and www.example.org, you can no longer request a cert for say example.com, www.example.com, example.org and www.example.org, since example.com exceeded its limit, but you can still request 4 certificates for example.org, so for example www.example.org and example.org.
Tell me more please verification domain does not require any action by the administrator to pass the challenge?
And what a test is selected for verification ?
I use ./letsencrypt-auto certonly --webroot --text -w /home/z/die/example.ru/public_html -d example.com -d www.example.com to obtain a certificate .
That depends on the client and mode of the client you use. Usually the client should prompt you when you need to take action.
Each mode has a preferred challenge type, but there should be a flag that lets you choose which one to use. The server currently always offers the http-01 and the tls-sni-01 challenge.
I’d be careful with putting a lot of hosts into certificates since each hostname increases the size of the certificate. The certificate, including all the hosts in it, is transferred in each TLS handshake when a connection is established. If you decide to do this anyway, consider increasing the keepalive value and appropriate values so encrypted sessions can be reused.
http-01 is the only challenge that works by requesting a specifically named file via HTTP. All other challenges don’t do that. --webroot defines the place where to put those files in order to complete the http-01 challenge, it makes no sense at all for any other challenge.
And to repeat, the only challenges LE’s ACME server provides are at the moment http-01 and tls-sni-01, with dns-01 being worked on but not ready yet.