In renewing a cert with exisitng domains, under nginx, I would state:
./letsencrypt-auto certonly --standalone -d 3.domain2.com 3.domain1.com
However the creation of the cert required:
./letsencrypt-auto certonly -a standalone -d 3.domain2.com 3.domain1.com --server https://acme-v01.api.letsencrypt.org/directory --agree-dev-preview
How can I now expand this cert to include 6 additional domains with two 3rd level domains? Total 12 tagged onto the first two.
If youâre running it interactively, the certonly command should prompt you asking whether youâd like to expand the existing cert by adding the new names (as long as the new list of names is a strict superset of the old list).
I confirm that, after sudo service nginx stop without which the procedure cannot continue, the command raises the interactive dialog. Appending domains resulted in expanding the cert. However I had to drop one domain for the motive urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up A for staging.[...].me Is the client intended to mean the server where this domain is being handled? This feels contradictory given nginx had to be turned off. Doubly so as the first domain got handled as expected.
Worse yet, notwithstanding the Congratulations message, the new added domains do not seem to have been registered. When connecting via browser
addeddomain.com uses an invalid security certificate. The certificate is only valid for the following names: staging.de4.me, staging.uuv.me (Error code: ssl_error_bad_cert_domain)
Checking the /etc/letsencrypt/renewal/staging.de4.me.conf file only the above names are shown.
What is the domain name you are trying to add ?
Here are two: saim-service.com with and without www prefixing. Better yet how can this error be verified beforehand?
Is that the domain you were adding which gave the " DNS problem: NXDOMAIN looking up A for staging." problem ?
[edited] sorry, there are two issues here, possibly colliding. You suggestion hinted me to try anew with a smaller subset to isolate the problem. So I got to the point of requesting:
staging.ride4.me staging.mmuuv.me saim-service.com www.saim-service.com postharvest.it www.postharvest.it ozono-natur.vin www.ozono-natur.vin
But now hit:
There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: ride4.me, saim-service.com Also, postharvest.it is generating an error:
postharvest.it uses an invalid security certificate. The certificate is only valid for the following names: saim-service.com, staging.mmuuv.me, staging.ride4.me, www.saim-service.com (Error code: ssl_error_bad_cert_domain)
How can this then be simply expanded.
From the error it sounds as if there is a problem with the A record for one of them. So you can either check them all yourself of list them here so other people can check the A records for all those you added.
full intended list is postharvest.it ozono-natur.vin ozono-sanificazione.comin addition to the aformentioned. both with and without the prefix
For part 1 of your question " Too many certificates already issued" . There is a limit of 5 certificates per domain name per 7 days. You have received certificates for ride4.me on;
2016-03-11 CN=staging.ride4.me
2016-03-11 CN=staging.ride4.me
2016-03-11 CN=staging.ride4.me
2016-03-11 CN=staging.ride4.me
2016-03-11 CN=staging.ride4.me
2016-02-08 CN=staging.ride4.me
2015-11-11 CN=staging.ride4.me
So you will need to wait until the 18th March before getting any further certificates for that domain. âexpandingâ a certificate is essntially just obtaining a new certificate. Also please note revoking certificates does not change the rate limit in any way.
In terms of the âDNS errorâ. that would appear to be with ozono-sanificazione.com as that has invalid DNS, hence Iâd expect the DNS lookup and check to fail.
âToo many certificateâŚâ I used up all my bullets! I guess the trial and error strategy is costly.
I fail to see where the invalidity in the ozono-sanificazione.com DNS entry is. âwww.â and empty are point to the ipv4 address. And it was reaching un-encryptedâŚ
for trial and error testing, you really need to use the testing / staging server - as that doesnât have the same limits.
Check ozono-sanificazione.com with a DNS tool ( such as http://www.intodns.com/ozono-sanificazione.com ). I check with a couple of linux tools, but the results will be similar. The SOA is invalid and the DNS not claiming to be authoritative for the domain - so Iâd be fairly sure thatâs why LE is rejecting it. (They donât want to just believe any old DNS server - so they try and check and confirm with the authoritative nameservers for your domain )
So after a 7-day hiatus, I relaunched both with a certonly command, then a renewal with [edited to show only problematic domains] ./letsencrypt-auto certonly -a standalone -d postharvest.it -d www.postharvest.it -d ozono-natur.vin -d www.ozono-natur.vin --server https://acme-v01.api.letsencrypt.org/directory --agree-dev-preview
To the interactive dialog I respond "Expand"
In both cases, I get `IMPORTANT NOTES:
But the aforementioned domains are not being served via https: examining the cert itself, these domains are not in the list of DNS names. Firefox returns (Error code: ssl_error_bad_cert_domain) the .conf file does not include them.
Where is this going wrong?
Hello @dvo,
Today you have created 2 certs with just 1 different domain so take care or you could reach the rate limit.
As far as I can see, for domain postharvest.it you are serving the cert that you created on 11th March at 15:44 UTC that includes these domains:
saim-service.com
staging.mmuuv.me
staging.ride4.me
www.saim-service.com
So, you are not serving the right certificate. When you get the message Congratulations! Your certificate and chain have been saved at after the âatâ you should see the path where the new cert is located so you should change your nginx conf to point to the new fullchain.pem and privkey.pem and restart/reload nginx.
Also, check the dir /etc/letsencrypt/live/ because Iâm afraid that after adding/removing domains you could get dirs whit yourdomain-000x where x is a number, so you should tweak your nginx conf to modify the path to your certs.
Good luck,
sahsanu
Luck had little to do with it⌠Your comment resolved the issue 
. I was wondering about that suffix and had not let the coffee kick inâŚ
To anybody reading this for their own purposes, naturally EACH nginx configuration file associated with the expanded certificate in the sites-enabled directory needs to be adjusted for the certificate version.
Ah, that is exactly what I was looking for. That's rather a bother, isn't it? I currently have only five domains in a cert, but given the theoretical limits (2000, isn't it?) that could potentially be quite a lot of work every time you add a subdomain.
Isn't the point of extending an existing cert to UPDATE the existing certificate (yes, really replacing the file)? And yes, I understand the underlying point is to limit the number of certs per tld. I just don't see the reasoning behind incrementing, especially since old certs get archived anyway.
You can use --expand to replace existing certificates if they cover a subset of the domains youâre requesting.
The limit of domains per certificate is 100.
I just tested that, and it works as expected. Was this behaviour different in an earlier version? I distinctly remember it spawning a new iteration.
Oh well, works now. Thank you for the quick response.
@vegivamp, you might have seen --expand fail if the new list isn't a strict superset of an existing cert's coverage (if the old cert has even a single name, like www. or something, that isn't in the new list, a separate certificate lineage will be created).