`certbot-auto` can't find certificates after obtaining (a working) one (Debian 8, Tomcat 9)



I recently obtained a LetsEncrypt certificate for my Tomcat 9 server via certbot-auto and it worked flawlessly.

After I configured my Tomcat 9 with the certificate and checked that it works (via Firefox) I issued the following command:

sudo ./certbot-auto certificates

with the following result:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
No certs found.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I wanted to test the renewal, which didn’t work, so I asked certbot-auto which certificates it knows. I first wanted to ask why the renewal does not work, but it seems to me that the root cause is, that certbot-auto can’t find the certificate.

So my question is: How can it be, that right after obtaining a (working) certificate via certbot-auto, it does not know about it? Is there any configuration that must be done here?

Some info on the environment:

OS: Debian 8 Jessie
Root access: yes
Web-Server: Tomcat 9, running on port 80 and 443 as root (I know this is bad, it is just for some testing, not production)

I following these steps to create a keystore, obtain the certificate and import it:

Creating a keystore:

keytool -genkey -alias server -keyalg RSA -keysize 2048 -keystore my_example_net.jks -dname "CN=my.example.net, OU=IT, O=EXAMPLE, L=City, ST=State, C=DE"

Convert the format to pkcs12:

keytool -import -srckeystore my_example_net.jks -destkeystore my_example_net.jks -deststoretype pkcs12

Creating a CSR:

keytool -certreq -alias server -file my_example_net.csr -keystore my_example_net.jks

Running certbot-auto:

sudo ./certbot-auto certonly --csr my_example_net.csr

How would you like to authenticate with the ACME CA?
-> "1: Spin up a temporary webserver (standalone)"

After that, certbot-auto printed the following result:

Performing the following challenges:
http-01 challenge for my.example.net
Waiting for verification...
Cleaning up challenges
Server issued certificate; certificate written to /srv/ssl/certbot/0000_cert.pem
Cert chain written to <fdopen>
Cert chain written to <fdopen>

 - Congratulations! Your certificate and chain have been saved at:
   Your cert will expire on 2019-02-25. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Lastly, I imported the certificate chain into my keystore:

keytool -import -trustcacerts -alias server -file 0001_chain.pem -keystore my_example_net.jks

I could now configure my Tomcat 9 to use the keystore and everything worked.


Directly after that, I tried:

sudo ./certbot-auto certificates

and certbot-auto printed the following

Saving debug log to /var/log/letsencrypt/letsencrypt.log
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
No certs found.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

With the /var/log/letsencrypt/letsencrypt.log file containing:

2018-11-27 12:33:21,065:DEBUG:certbot.main:certbot version: 0.28.0
2018-11-27 12:33:21,065:DEBUG:certbot.main:Arguments: []
2018-11-27 12:33:21,065:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2018-11-27 12:33:21,077:DEBUG:certbot.log:Root logging level set at 20
2018-11-27 12:33:21,078:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log

The directory contents may also be of help. I have these directories and files right after obtaining the certificate:




So, why can’t certbot-auto find any certificate, although the certificate itself is working without any problems? Or is this a misunderstanding on my side, that the way I obtained a certificate does not support certificate managing by certbot-auto?


Any help is much appreciated!

Thanks a lot!

Kind regards


Perhaps it was the certonly parameter…


Certbot’s --csr argument makes it behave very differently than usual. Normally Certbot generates its own private key and saves the the key, certificate and automatic renewal settings in /etc/letsencryot/. When using --csr, it doesn’t. The certificates command pulls from that information, so it doesn’t see certificates issued using --csr.

The certificate file was saved in the current directory, at the path Certbot displayed.

You can inspect it with a non-Certbot tool like “openssl x509 -noout -text -in /srv/ssl/certbot/0001_chain.pem”, if you want to.

I’d really suggest you avoid using --csr if you can. Some ACME clients let you specify a custom CSR and access all of their features, but Certbot doesn’t.

I don’t use Tomcat, so I can suggest what not to do, but don’t know much about what you should do.

You can use a Certbot --deploy-hook to have Certbot generate files in the format Tomcat wants. (And also reload or restart Tomcat.) This thread covers some of it:

(A relatively recent Certbot feature that won’t be covered in older tutorials is the --reuse-key option. That causes Certbot to generate a private key the first time you create a certificate, but reuse the same key when renewing it in the future. However, as the link above shows, you don’t need to do that.)


Thanks a lot for your answers - especially to you, @mnordhoff.

I now understand why certbot-auto does not “see” the certificates and I will try and do it without --csr.