This Connection Not Private

I need to access my domain using multiple different names:,, and I recently needed to use so I added it to my renewals file (listed below) and forced a renew. my original names still work but the m1 i added receives a "This connection not private" error.

My domain is:

I ran this command: certbot renew --force-renewal

It produced this output:
Congratulations, all renewals succeeded:

/etc/letsencrypt/live/ (success)
/etc/letsencrypt/live/ (success)

My web server is (include version): Apache 2.4.51

The operating system my web server runs on is (include version):
Gentoo Linux 5.4.97

My hosting provider, if applicable, is:

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): certbot 1.20.0

contents of /etc/letsencrypt/renewal/

renew_before_expiry = 30 days

version = 1.20.0
archive_dir = /etc/letsencrypt/archive/
cert = /etc/letsencrypt/live/
privkey = /etc/letsencrypt/live/
chain = /etc/letsencrypt/live/
fullchain = /etc/letsencrypt/live/

Options used in the renewal process

authenticator = web-root
account = c4ff050123493ace71750be523a80c66
server =
[[webroot_map]] = /vhosts/ = /vhosts/ = /vhosts/ = /vhosts/

That's because you shouldn't edit the renewal configuration file to add additional hostnames to the certificate. Certbot takes the hostnames from the original certificate when renewing, not the renewal configuration file.

That said, certbot does not offer an easy way to add or remove hostnames from a certificate unfortunately. And it seems this isn't going to change soon, as the issue on Github to improve this hasn't seen any action for two years now and is labeled as "wishlist", which makes it the lowest priority...

Currently, the only way to add or remove hostnames from a certificate is to use --cert-name in combination with all the options you've used to create the certificate the previous time, but now with the modified hostnames (i.e.: add or remove a -d option).


Thanks for the quick reply. If I read you correctly I should use this:

certbot renew --force-renewal --cert-name -d -d -d -d

Just out of curiousity I was hoping I could generate a certificate for any subdomain of with this command:

certbot renew --force-renewal --cert-name -d dvss,org

but that didn't work either.

Thanks again.

1 Like

The option --cert-name expects a value: the name of the certificate. Otherwise you might end up with a new cert next to your previous one.

You could also use a wildcard certificate, but that would require using the dns-01 challenge.

1 Like

I'm afraid I'm in over my head here. I entered:

certbot renew --dry-run --cert-name -d -d -d -d

and received this output:

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

Currently, the renew verb is capable of either renewing all installed certificates that are due to be renewed or renewing a single certificate specified by its name. If you would like to renew specific certificates by their domains, use the certonly command instead. The renew verb may provide other options for selecting certificates to renew in the future.

You can't do both.

Thanks to your help I was finally to accomplish what I wanted. The following command worked for me:

certbot certonly  --cert-name -d -d -d -d

As a follow up question, is there anyway I could create a certificate for that would allow for any and all subdomains of

Thanks again for your help.

1 Like

That's called a "wildcard" certificate.
You would request it as:
certbot certonly --cert-name -d -d *
[(pre)defining the cert-name is optional - certbot will make a unique one if not defined]
But wildcard certs require DNS-01 authentication - HTTP-01 authentication won't do.
[You can even process the DNS TXT records requests manually - if you just want to try it out once]
But the idea is to automate the entire certificate (renewal) process.
So you would have to use a DNS Service Provider (DSP) that supports zone updates via API.
And also an ACME client with a DNS plugin for that DSP.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.