Remove domain not required from cert


#11

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.


#12

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 :grin:


#13

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 )


#14

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:

  1. 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.
  2. 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-names flag 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.


#15

@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!


#16

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!


#17

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!


#18

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.


#19

I guess I could remove the domain from the apache config … if I refresh my understanding of that …


#20

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).


#21

I’ve chosen to do the following:

  • which allows creation of individual certificates one per domain. This means that when you view the certificate via the padlock next to the URL in the browser, you will now only see the domain for that certificate listed, instead of a list of all the domains that are using a single certificate as before (which could have privacy implications)
  • using the above approach does mean having to start again and discarding the previous certificate. If you have a large number of sites to do in this way, bear in mind if there is a limit to how many certificates that let’s encrypt will issue in a certain space of time, so it would be best to stagger i.e. do a few domains each week, for example.

#22

There are a simple way to do "certbot remove domain" when the domain is secondary (is an alternative name)?

PS : how to list main and alternative domains, to check it after remove?


#23

In more recent versions of Certbot, you can use certbot certificates to view what certificates you have and the names that Certbot uses to refer to them.

You can then also use --cert-name example.com to select a particular certificate. This is the only way to remove names, because you can then give a new list of the desired names with -d, which may be shorter than (or totally different from) the existing list of names.

Without --cert-name, or in older versions of Certbot that don’t understand it, there is no way to do this; Certbot will always create a separate certificate alongside the existing one.


#24

Thanks (!). I try sudo certbot certificates that shows

  • Certificate Name: xxxxx.org
  • Domains: xxxxx.com, yyyyy.org, yyyyy.com,

So I try sudo certbot --cert-name xxxxx.com and shows

Saving debug log to /var/log/letsencrypt/letsencrypt.log
No certificate found with name xxxxx.com 
  (expected /etc/letsencrypt/renewal/fabrincantes.com.conf).

PS: and I not understand the answer, can I delete an item from “Domains” list?


#25

The --cert-name can only be the name shown on the “Certificate Name:” line. It can’t be any other name. That is the single name that Certbot uses to refer to the certificate in question.

You can delete an item from the Domains list by running certbot --cert-name xxxx.org -d xxxxx.com -d yyyy.org -d yyyy.com and omitting the item that you want to delete from the -d list.

The effect of this command is to replace the existing certificate by a new certificate containing only the domains specified by -d options, and no others. So if you don’t mention one with -d here, it will not be included in the new version of the certificate.


#26

I found the command above was missing one tiny detail… certbot certonly --cert-name xxxx.org -d xxxx.org.

Adding the certonly command, allowed certbot to run fine and remove the domain from the certificate


#27

Thanks for the correction, that’s quite right! I’m glad it worked for you.


#28

The easiest solution, that worked well for me is this command:

sudo certbot renew --allow-subset-of-names

I think the --allow-subset-of-names flag is new. People looking for a solution and finding this thread may find this useful.


#29

However, people just reading this last post should read back over the thread to learn about caveats using this flag as a rule. Specifically how intermittent failures of a single SAN authorization during renewal will cause that name to be dropped from the certificate silently, when this may not have been the desired or expected outcome.


#30

… And about “purge” a cert-name, preserving other?

The command certbot certificates at my server show something as:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Found the following certs:
  Certificate Name: MyDomain1
    Domains: ...
    Expiry Date: 2017-10-24 10:22:00+00:00 (VALID: 73 days)
    Certificate Path: /etc/letsencrypt/live/MyDomain1/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/MyDomain1/privkey.pem
  Certificate Name: MyDomain2
    Domains: ....
    Expiry Date: 2017-11-10 02:22:00+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/MyDomain2/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/MyDomain2/privkey.pem

The first, MyDomain1 is rubbish! (use a subset of MyDomain2 domains and removed-from-server domains), nobody using it… And not make sense a cert-name about domain that not exist.

The second is in production, I am using it (!).

How to delete only MyDomain1?


PS: Hi @schoen, some direct and reliable command? some clues for a reliable procedure?