Certbot with csr doesn't put cert in live path

I am trying to move to the usage of csr when requesting certificates and renewing.

I have successfully made a csr and obtained a certificate with it using certbot.

But for some reason the certificate is not put in /etc/letsencrypt/live/$domain as expected and it is named like this: 0000_cert.pem, 0000_chain.pem and 0001_chain.pem

Is this expected behavior when using the certonly --csr option?

Is there a way to make the certbot client still put the files in /etc/letsencrypt/live/$domain structure when using csr?

I used this command to request certificate for my testing subdomain:
/certbot-auto certonly --csr /path/to/letsencryptbyeskilleno.first.csr -d letsencrypt.byeskille.no -d www.letsencrypt.byeskille.no --webroot -w /path/to/webroot/html --expand

The output was like this:

No handlers could be found for logger "certbot.crypto_util"

IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at
    /opt/certbot/0001_chain.pem. Your cert will expire on 2016-09-09.
    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"
  • If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let's Encrypt: Donate - Let's Encrypt
Donating to EFF: Support EFF's Work on Let's Encrypt | Electronic Frontier Foundation

In advance, thanks for all helpful advice!

1 Like

Yep! The --csr option currently assumes that you'll want to take care of certificate storage. One of the files that certbot would manage in /etc/letsencrypt/live would be privkey.pem, but with --csr, the client doesn't generate this file or even know where it's stored. You'd end up with directories in /etc/letsencrypt/live that are different from regular ones (in that the private key is missing), so while it would be possible for the client to kind of keep this structure for --csr, it would get confusing and complex, plus you'd have to manage the private key file on your own anyway.

You can control the output directory for the certificate using --cert-path. I believe there are corresponding --chain-path and --fullchain-path options as well.

1 Like

Thanks!

I managed to control how the output is made when using --cert-path, --chain-path and --fullchain-path options. The command then ended up as:
./certbot-auto certonly --csr /path/to/letsencryptbyeskilleno.first.csr -d letsencrypt.byeskille.no -d www.letsencrypt.byeskille.no --webroot -w /path/to/webroot/html --expand --cert-path /path/to/letsencrypt.byeskille.no/cert.pem --chain-path /path/to/letsencrypt.byeskille.no/chain.pem --fullchain-path /path/to/letsencrypt.byeskille.no/fullchain.pem

But if I try to run certbot-auto certonly again with the same parameters in order to test how it would act in case of automated renewal set up. It then complains the cert.pem file already exists, from the letsencrypt.log:

OSError: [Errno 17] File exists: '/path/to/letsencrypt.byeskille.no/cert.pem'

All of this is part of an effort to find a suitable set up for Let´s encrypt autorenewed certificates by using certbot and CSRs to be able to implement HPKP.

So if anyone have links to good implementations of Let´s encrypt and HPKP that will also be helpful.

1 Like

I see Scott Helme have solved this using another client acme-tiny.

See good blog posts:

Haven’t had time to test it fully myself just yet, but sharing what I find during troubleshooting…

@byeskille, the Certbot client currently doesn’t support automated renewal with a custom CSR at all (at least not using certbot renew). Some people have created custom scripts as a wrapper around certbot certonly --csr to handle renewal for them.

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