I changed the configuration of the domain to forward to another address, at the DNS.
When attempting to renew, this fails for that domain.
How do I stop the renew for specific domains?
Looked at:
- but couldn't see a definitive answer here.
1 Like
My understanding is that this is being worked on and the ability to remove a domain from your cert will be included in a future version of the client. The client currently allows you to add a domain to a certificate but doesn’t allow you to remove one.
In the meantime, is it possible to avoid renew errors by manually removing the unwanted domain from the renew conf file?
The only other option I can think of is to simply delete the cert you have (along with it’s archive, renew config, and symlinks) and recreate it without the unwanted domain. It’s not elegant, and the new cert will count against your weekly limit, but the unused domain will be gone for good.
1 Like
Thanks @DarkSteve It's good to know what is and is not available in the current release as it can save me time.
"In the meantime, is it possible to avoid renew errors by manually removing the unwanted domain from the renew conf file?"
Do you know how this would be done - would this be the missing feature to be able to remove domains - which isn't there yet?
In another thread, removal of the entire cert, to recreate it, doesn't appear to be straightforward, according to:
You may be right, and I haven't edited my renewal conf, but looking at my renewal conf file I can see that the lines starting with "domains", "webroot_path", and the section "[[webroot_map]]" contain my three domains. It seemed pretty straight forward to remove the unwanted domain from each. But then again, I've never tried, and maybe webroot is different than standalone or other plugins.
When I first started playing with Let's Encrypt, I created three separate certs for my three domains. When I realised what I'd done, and that I'd prefer to have a single cert with multiple domains, I deleted everything but the "accounts" directory and started again. The creation of my new cert went flawlessly.
I'm definitely not advocating rampant deleting, but I wanted to convey my experiences. Taking off and nuking the site from orbit worked for me, and it's the only way to be sure 
1 Like
@DarkSteve thank you, that’s certainly encouraging. I’ll give it a go.
Right now, the procedure for that would probably be something like this:
Before you start, create a backup of /etc/letsencrypt just in case, i.e. cp /etc/letsencrypt/ /etc/letsencrypt.backup -r
Let’s say you have two certificate lineages, foo.example.com and bar.example.com.
The certificates for foo.example.com are stored in /etc/letsencrypt/live/foo.example.com, for bar.example.com in /etc/letsencrypt/live/bar.example.com.
If you’re unsure which lineage contains which domains, try this for all subdirectories in /etc/letsencrypt/live:
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem -text -noout | grep DNS
If you want to remove everything in the bar.example.com lineage (that is, bar.example.com and any other domains covered by that certificate), you can delete the following files:
rm -rf /etc/letsencrypt/live/bar.example.com/
rm -rf /etc/letsencrypt/archive/bar.example.com/
rm /etc/letsencrypt/renewal/bar.example.com.conf
That’s it.
If you just want to remove one (or a couple) of domains that were included in the bar.example.com - let’s say you don’t want sample.bar.example.com, but still need othersample.bar.example.com and bar.example.com - you can use the same rm commands, and afterwards request a new certificate using only the domains you want to keep. Full example (with webroot, but you can of course use whatever you initially used to get the certificates):
rm -rf /etc/letsencrypt/live/bar.example.com/
rm -rf /etc/letsencrypt/archive/bar.example.com/
rm /etc/letsencrypt/renewal/bar.example.com.conf
# this will install a new certificate in bar.example.com, excluding sample.bar.example.com
./letsencrypt-auto certonly --webroot -d bar.example.com -d othersample.bar.example.com -w /var/www/html/
If anything goes wrong while you’re doing this, run mv /etc/letsencrypt /etc/letsencrypt.broken && mv /etc/letsencrypt.backup/ /etc/letsencrypt and you’re back where you started. 
Hope this helps!
11 Likes
Thanks very much pfg too. I’ll give that a go.
Just before I asked the original question, I was looking at the folders /etc/letsencrypt/live/ and I could not see the file for the domain that it errored about (the one I had set up to be forwarded in my registar DNS control panel). So I could not delete the files for this particular domain, in order to start again, as it wasn’t there. My deduction was therefore that it was somehow embedded in the file(s) of one of the other domains. But I will look at the other points you made where I could do something. I’m not able to work on it, not until I finish work, so possibly this evening. later on. Thank you.
@bmw, could you chime in on this?
One thought: If you run the client again with the new, smaller list of domains, and --force-renewal, will that adjust the lineage so that only the smaller list of domains gets renewed in the future?
1 Like
One thought: If you run the client again with the new, smaller list of domains, and --force-renewal, will that adjust the lineage so that only the smaller list of domains gets renewed in the future?
@jsha This will actually create a new lineage. There is currently code to detect if the requested domains is a superset of the domains you have a certificate for, but not a subset.
In general, the whole process of selecting a lineage that doesn't contain the exact domain names you requested is somewhat nuanced and you can read more about it here. We plan to fix the problem in the future though.
@therobyouknow, everything pfg said is correct and is a valid way to fix the problem.
Another option that was recently added to the client is the --allow-subset-of-names flag. When using this flag, the client will only request a certificate for domains you successfully completed domain validation challenges for.
For example, suppose you're trying to renew a certificate that contains example.com and other.example.org, but you can no longer pass challenges for example.com because you changed the DNS record. If you provide --allow-subset-of-domains on the command line when you renew the certificate, the client will drop the name for example.com, leaving you a valid lineage for other.example.org with example.com removed.
3 Likes
@pfg Thanks for that. I basically did what you described second, and it worked for me. Good to know I was on the right track!
Ah, that's damn-near ideal. When was that flag introduced? 0.5? I was expecting a "shrink" command or something (to complement the existing "expand"), but I guess renewal is really the only time it's important. You can expand the certificate with new domains whenever you want, and just let unwanted domains die once they are no longer reachable.
I'm assuming in your example, the renewed cert would contain only "other.example.org", it wouldn't still contain an expired "example.com"? (Stupid question I know, just making sure I properly understood you.)
Also, a hyperthetical error scenario. If I have domain1.org, domain2.org, and domain3.org all in one certificate, and only domain2.org is up for renewal, but Apache is down when the client tries to renew, what happens? Does the client create a new cert with only domains 1 and 3, or does the cert remain untouched? Does the cert remain untouched but the renewal conf has domain2 removed?
What happens if all three domains are up for renewal, but Apache is down?
So many variables.... I guess you'll be tweaking the client as real-world feedback comes in! (But I love the idea at this stage, hopefully it will work well in practice, too 
)
1 Like
I don't understand this situation. If they are all in a single certificate then it only has 1 expiry date - so either none or all will be up for renewal.
You wouldn't want to auto-renew with the --allow-subset-of-names flag, otherwise if a domain was down at that stage it would be missed off the certificate, however for those occasions when you wanted to change the domains on the certificate it would be really useful.
1 Like
If I create a certificate, but then a month later add domains to the cert using -expand, I assumed that there would be multiple expiries?
I'm still learning about how all this works, so I wouldn't be surprised to find out I'm wrong 
1 Like
when you "expand" the certificate you essentially create a new certificate with the modified list of domains which it is valid for. That new certificate has a single expiry date associated with it ( 90 days in the future from when you did the -expand and created it )
2 Likes
Ah, that's damn-near ideal. When was that flag introduced? 0.5? I was expecting a "shrink" command or something (to complement the existing "expand"), but I guess renewal is really the only time it's important. You can expand the certificate with new domains whenever you want, and just let unwanted domains die once they are no longer reachable.
Yes, this was introduced in the 0.5.0 release last week. We will likely implement a --shrink flag at some point (#2071), but the problem with flags like --shrink/--expand is it can be ambiguous which cert should be modified.
I'm assuming in your example, the renewed cert would contain only "other.example.org", it wouldn't still contain an expired "example.com"? (Stupid question I know, just making sure I properly understood you.)
Correct. The new certificate would not contain example.com. Also, not a stupid question at all. This stuff is confusing and complicated, hence Let's Encrypt and its clients trying to simplify the process.
Also, a hyperthetical error scenario. If I have domain1.org, domain2.org, and domain3.org all in one certificate, and only domain2.org is up for renewal, but Apache is down when the client tries to renew, what happens? Does the client create a new cert with only domains 1 and 3, or does the cert remain untouched? Does the cert remain untouched but the renewal conf has domain2 removed?
serverco correctly answered this question. There is no expiration on individual domains in a certificate. The expiration is on the certificate as a whole.
The one thing I will clarify is that some people may want to configure automatic renewal with the --allow-subset-of-names flag. If you can no longer get a certificates for one of your domains, which is worse:
- Renewal fails because the client can't get a certificate for all requested domains. This means your certificate expires for all of your domains instead of the one you can no longer get a cert for. This makes a lot of noise and is more likely to get your attention so you can fix the problem, however, the problem affected more domains than it really had to.
- Renewal succeeds, but one of your names was dropped. This may have been the correct behavior if the domain is no longer hosted on that server. On the other hand, there may have been a temporary outage for the dropped domain. Depending on how often you automatically run
letsencrypt renew, the renewal would have failed during the temporary outage but succeeded later, potentially before expiration. Using the--allow-subset-of-namesflag would have caused problems you otherwise would have avoided.
The behavior you want depends on the individual/server configuration.
What happens if all three domains are up for renewal, but Apache is down?
If you ran the client with --allow-subset-of-names and you couldn't complete the challenge for any requested domains, the client will exit with an error as if you didn't even provide the --allow-subset-of-names flag. At least one domain must succeed for the new certificate to be created.
2 Likes
@serverco D’oh! I guess it’s true what they say about when you assume…
Thanks for clearing that up. That makes pretty much all my other questions and concerns go away!
1 Like
That's very good. Now that I understand a cert can't have different expiries for it's domains, I can't imagine people having many problems with this.
Thanks for the excellent breakdown, both you guys rock.
Here's why I've been so interested on possible issues. I run my server out of my spare bedroom, and for years I've had no issues. This February just gone (two months ago) was the hottest February on record in Australia, and my air conditioner inconveniently chose to die that same month. The room where my server sits got over 40 degrees Celsius, and my hardware started to get flaky and write crap to the FS and corrupt files.
I'm still fixing issues introduced to the system from Feb, and as I type both my ownCloud and Roundcube domains aren't functioning (I think my PHP is pooched). Of course, I'm not using the --allow-subset-of-names flag at this stage, but if I was and the client tried updating now, I'd probably lose two of my three domains.
This is an extreme example and hardly representative, I just wanted to make sure I had an accurate picture of the new flag in my head before I considered using it in the future!
1 Like
DarkSteve, pfg, jsha, bmw, serverco thank you all very much for your time and input. I’ve had a quick read through and it looks like there is at least one approach to solving my problem - thank you very much. Also, several pieces of insight into how some main concepts work - thanks also for that. I will have another read in more depth to see which one would be closest to my needs. Thanks again!
Not quite. With my setup, after deleting the files as above, a dry run of renewal now fails for all domains, not just the one that is obsolete and has no DNS record! I am using apache:
2016-08-03 17:31:32,096:ERROR:certbot.util:Error while running apache2ctl configtest.
Action 'configtest' failed.
The Apache error log may have more information.
AH00526: Syntax error on line 30 of /etc/apache2/sites-enabled/bar.example.com.conf:
SSLCertificateFile: file '/etc/letsencrypt/live/bar.example.com/cert.pem' does not exist or is empty
2016-08-03 17:31:32,098:WARNING:certbot.renewal:Attempting to renew cert from /etc/letsencrypt/renewal
/foo.example.com.conf produced an unexpected error: The apache plugin is not working; there may be problems
with your existing configuration.
etc...
For now I will restore the backup (good tip!) and just renew & ignore the failure of the obsolete domain.
I guess I could remove the domain from the apache config … if I refresh my understanding of that …
Indeed, for setups that use the automatic installation provided by the apache plugin, you’d have to restore your configuration to the state it was in before the client enabled SSL for the domain (i.e. get rid of the SSL vhost, possibly make changes to the HTTP vhost if it was changed by the client). Then the client would re-create the configuration (like during the initial installation).
1 Like