Renewal with removal of subdomain

My domain is:

Note that this is an XMPP server, not an HTTP server; we previously hosted two domains here, and, but moved to a separate machine. Now when we try to renew the old certificate, we receive a warning about not being able to contact (see below). We modified a configuration file under /etc/letsencrypt/renewal to remove the webroot for before attempting to renew but that didn't help. Should we request a new certificate instead of attempting to renew?

I ran this command: /usr/local/letsencrypt/letsencrypt-auto --no-self-upgrade renew

It produced this output:

Processing /etc/letsencrypt/renewal/

Cert is due for renewal, auto-renewing...
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
http-01 challenge for
Waiting for verification...
Challenge failed for domain
http-01 challenge for
Cleaning up challenges
Attempting to renew cert ( from /etc/letsencrypt/renewal/ produced an unexpected error: Some challenges have failed.. Skipping.

renew_before_expiry = 30 days

All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/ (failure)

My web server is (include version): apache2

The operating system my web server runs on is (include version): Debian 7.10 (yes, we know this is old)

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): unsure


Welcome to the Let's Encrypt Community, Peter :slightly_smiling_face:

The domain names used for certificate renewal originate from the existing certificate itself. You can modify the certificate configuration using the following command, which will also update your configuration:

/usr/local/letsencrypt/letsencrypt-auto run --cert-name -d "," --no-self-upgrade

Consider using --cert-name instead of --expand, as it gives more control over which certificate is modified and it lets you remove domains as well as adding them.

Current Certificate

Certificate History

You probably want to 301 redirect these to https:

Screenshot_20201013-143714_Samsung Internet


Hi @stpeter,

letsencrypt-auto --no-self-upgrade --expand --cert-name -d

should do the trick to remove the subdomain.

You could also use this flag while renewing:

When performing domain validation, do not consider it
a failure if authorizations can not be obtained for a
strict subset of the requested domains. This may be
useful for allowing renewals for multiple domains to
succeed even if some domains no longer point at this
system. This option cannot be used with --csr.
(default: False)


Two possible solutions to your problem exist, one not so pleasant to hear, the other way more easy, but not without its drawback:

Unfortunately, it isn't straightforward to delete or add a hostname from or to a certificate. There has been ongoing discussion about fixing this on the certbot Github page:

Unfortunately closed "because --cert-name exists".

Later, somebody having issues because all the settings need to be re-entered on the command line opened:

Meanwhile, almost a year ago, another issue was opened because adding and removing domains is very cumbersome:

Unfortunately, these past 11 months, nothing seems to have changed.

So to answer your question with the first option: you could indeed re-request your original certificate, but now without the hostname you'd like to remove from the certificate. Use --cert-name to make sure the previous certificate is overwritten.

Second option: use the --allow-subset-of-names option when renewing. This would allow certbot to continue with getting your cert, but now without any failing hostname(s). Drawbacks: if a hostname fails when it shouldn't, because of for example a temporary issue, this hostname would be removed from the certificate too. Fortunately, you've already tried to renew. And only the non-functional hostname failed, right? If that's the case, the Let's Encrypt validation servers would have a cached valid authorization for the other hostnames, so this wouldn't be an issue. But it could be a theoretical issue nontheless.


As noted, we run an XMPP server at - this is on a separate machine than the web server at Just to be clear about which cert is involved. :slight_smile:


Why is there a redirect from to Is that in case of http requests to I may have answered my own question. :blush:


Hey _az both of these approaches look promising. Unfortunately, when running letsencrypt-auto I now experience a more fundamental problem:

Creating virtual environment...
Installing Python packages...
/opt/ No module named pip.main; 'pip' is a package and cannot be directly executed
Traceback (most recent call last):
File "/tmp/tmp.Ef2tkHKHOw/", line 182, in
File "/tmp/tmp.Ef2tkHKHOw/", line 154, in main
pip_version = StrictVersion(check_output([python, '-m', 'pip', '--version'])
File "/usr/lib/python2.7/", line 544, in check_output
raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['/opt/', '-m', 'pip', '--version']' returned non-zero exit status 1

So I'll need to fix that first! :slight_smile:


Can you please tell us your version?
/usr/local/letsencrypt/letsencrypt-auto --version

You can probably install the latest certbot via snap.

1 Like

I get the same error about "no module named pip.main" when I attempt to run the foregoing command. :-/


Ah... K.

What OS are you using?

I'm blind today. Debian

1 Like

cat /etc/debian_version


1 Like

Thanks for that. :slightly_smiling_face:

You might be able to install the latest via snap using the following link. It requires you to remove your existing version as part of the process.


Yes, we know this is an ancient version of Debian. :slight_smile: We have a server migration in process so that we can upgrade this machine (thus the temporary split of domains causing the original issue).


This error is quite likely due to running letsencrypt-auto without --no-self-upgrade. Unfortunately when it tries to upgrade, it deletes the previous version of itself.

Debian 7, being very EOL, is not capable of upgrading to a recent version of certbot-auto. And you won't be able to use snaps on a kernel that old either.

You may need to restore certbot-auto from an old release like, and then make sure to always use the --no-self-upgrade flag.

You can check exactly what version you had before by looking in /etc/letsencrypt/renewal/*.conf.


Thanks, griffin, for your fast and friendly service. I'll try the snap approach after my next round of meetings. :wink:


Read @_az's response first. His knowledge far exceeds mine here.


Yes, what @_az says makes sense!


You should still include both and on the certificate for your http and redirect and to :grin:

Let us know how things proceed. :slightly_smiling_face:


Thanks for the tip. The version we previously ran was 0.36.0. I downloaded that version from but after typing /usr/local/letsencrypt/letsencrypt-auto --version I still get the error about "no module named pip.main". I suspect package corruption on this ancient Debian OS, from which recovery could be difficult...


Let me know whether it works if you follow this exact process:

  1. Delete the letsencrypt-auto and certbot-auto file.
  2. sudo rm -rf /opt/
  3. wget
  4. chmod +x certbot-auto
  5. ./certbot-auto --no-self-upgrade --version

The deletions are needed to get rid of all of the partially-upgraded software, and --no-self-upgrade is very important, even when doing --version.

Your actual certificate data is stored elsewhere and preserved.