Scattered certificates and keys

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:
sudo certbot install -d -d -v --preferred-challenges http

It produced this output:
Root logging level set at 10
Saving debug log to /etc/apache2/sites-available/~/.certbot/logs/letsencrypt.log
Requested authenticator None and installer None
Apache version is 2.4.18
Single candidate plugin: * apache
Description: Apache Web Server plugin
Interfaces: IAuthenticator, IInstaller, IPlugin
Entry point: apache = certbot_apache.entrypoint:ENTRYPOINT
Initialized: <certbot_apache.override_debian.DebianConfigurator object at 0x7fcf411286a0>
Prep: True
Selected authenticator None and installer <certbot_apache.override_debian.DebianConfigurator object at 0x7fcf411286a0>
Plugins selected: Authenticator None, Installer apache

Which certificate would you like to install?


Select the appropriate number [1-4] then [enter] (press ‘c’ to cancel): 3
Created an SSL vhost at /etc/apache2/sites-available/
Creating backup of /etc/apache2/sites-available/
Deploying Certificate to VirtualHost /etc/apache2/sites-available/
Enabling available site: /etc/apache2/sites-available/
Deploying Certificate to VirtualHost /etc/apache2/sites-available/

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.

1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you’re confident your site works on HTTPS. You can undo this
change by editing your web server’s configuration.

Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2
Creating backup of /etc/apache2/sites-enabled/
Redirecting vhost in /etc/apache2/sites-enabled/ to ssl vhost in /etc/apache2/sites-available/
Already enabled redirect for this vhost

My web server is (include version):
Server version: Apache/2.4.18 (Ubuntu)
Server built: 2019-04-03T13:34:47

The operating system my web server runs on is (include version):
Ubuntu 16.04

My hosting provider, if applicable, is:
Running on a self managed VPS hosted by

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

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
NO (ssh to a terminal interface)

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

Problem does not appear in ‘/etc/letsencrypt/live’ which is where I thought all letsencrypt generated certificates and keys were stored.

A number of my certs and keys are stored in:

and some in:

and there are even some in:

Is it something that I’m doing that is scattering certificates all over the place?

Also when trying to access:

it goes to: which creates a “SSL_ERROR_BAD_CERT_DOMAIN” error” which is the default server listed by “sudo apache2 -S” it’s also the first site listed in /etc/letsencrypt/live.

I don’t know what’s causing certs and keys to be scattered all over the file system? Could it be the phase of the moon?

When I try to access

Hi @renopete

checking your first domain I don't see a problem.

Instead, you have a Grade B, that's very good ( ):

The certificate:
expires in 90 days, - 2 entries

And all 4 standard checks are fine, two correct redirects http -> https, one correct not-preferred-version -> preferred version:

Domainname Http-Status redirect Sec. G 301 0.240 A 301 0.240 A 301 1.817 B 200 1.697 B

Grade B is really good. Looks like you have fixed the problem.

Or it's a local caching problem, so only you see the wrong data.


You were right. I checked late this evening on:

And it does not report a name mismatch. Am going to have to reboot my systems to see if
I can clear the browser caches of bad data.

Thanks for the quick response. As for letsencrypt storing all certificates and keys in
/etc/letsencrypt/live, I guess that’s not longer the case.



Certbot does normally store everything in /etc/letsencrypt.

Check /etc/letsencrypt/cli.ini (ironically) and ~/.config/letsencrypt/cli.ini to see if there are settings telling it to put stuff elsewhere?

It sounds like perhaps something is configured to put things in “~/.config/certbot” but the “~” isn’t being expanded.

1 Like

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