Certbot pem Automatic Creation - Create pem file that contains both privkey.pem and fullchain.pem in one?

Feature Requests
1

Maybe certbot can already do this (if it can, please let me know what arguments I should pass to it), but maybe it doesn’t.

Would it be possible for certbot to automatically create a pem certificate file that contains both the privkey and fullchain in one pem file when creating a certificate for the first time or when a certificate is renewed?

Programs like courier and lighttpd want certificates in this format.

Usually, I have to run something like this:

cat /etc/letsencrypt/live/test.com/privkey.pem /etc/letsencrypt/live/test.com/fullchain.pem > /etc/letsencrypt/live/test.com/courier.pem && /usr/sbin/service courier-pop-ssl restart && /usr/sbin/service courier-imap-ssl restart

By default, certbot creates cert.pem, chain.pem, fullchain.pem, and privkey.pem files for each domain. Perhaps another one called mixed.pem could be created (and updated when renewed) by default? This would be ideal and awesome.

1 Like
2

Hi @own3mall,

The first time no, as far as I know certbot doesn't provide any hook when issuing the cert for the first time but it provides a hook --deploy-hook that will be triggered on renewals and you could use it to execute an script to perform the needed tasks.

Following your example, the deploy script could be something like this:

#!/bin/sh
cat ${RENEWED_LINEAGE}/privkey.pem ${RENEWED_LINEAGE}/fullchain.pem > ${RENEWED_LINEAGE}/courier.pem && /usr/sbin/service courier-pop-ssl restart && echo /usr/sbin/service courier-imap-ssl restart

We save this script in for example /etc/letsencrypt/courier.sh (remember to give execution perms)

chmod 750 /etc/letsencrypt/courier.sh

Then, the next time you issue a new cert, you use the certbot certonly -a webroot or whatever are the options and you add --deploy-hook "/etc/letsencrypt/courier.sh" so next time this cert would be renewed it will execute the script.

If you already want to do this for existing certs:

Option 1, the script will be executed when any of your cert is renewed:

1.- Copy the script to /etc/letsencrypt/renewal-hooks/deploy/

or

2.- If you have a cron job issuing the command certbot renew, just edit that cron job and add the deploy hook param... certbot renew --deploy-hook "/etc/letsencrypt/courier.sh"

Option 2, the deploy hook will be used only in specified certs.

1.- Renew and exixting cert appending the deploy hook param, if the cert is not close to expire maybe you want to force the renewal (you should not use this option).

certbot renew --cert-name herethecertnameforthedomainyouwanttorenew --deploy-hook "/etc/letsencrypt/courier.sh" --force-renewal

or

2.- Edit the renewal conf file for your domain /etc/letsencrypt/renewal/yourdomain.conf and append the deploy hook directive (in this file its name is renew-hook) to the section [renewalparams]

[renewalparams]
other options
renew_hook = /etc/letsencrypt/courier.sh

So you have options... the first time you should create the courier.pem by "hand" but in next renewals this will be automatic.

I hope this helps.

Cheers,
sahsanu

3

@sahsanu, thanks for the information.

However, I still think it would be nice if certbot created this mixed.pem file in the directory by default so that I don’t have to do it manually. This would make Let’s Encrypt integration and automation with other applications much more straightforward.

Since that is a common certificate format (the combination of the privkey.pem and fullchain.pem file contents) programs expect, I’d prefer if certbot just created it automatically by default and updated it when renewing domains. It wouldn’t be that hard to add to certbot, and the result is one additional pem file in the directory which could even be symlinked and stored elsewhere like the other pem files.

1 Like
4

@own3mall, and a combination of privkey and cert, and a pfx, and pvk, and why not a keystore, etc. there are a lot of formats used by a lot of applications/services and it would be impossible to cover all of them.

I don't use any service that requires that combination :wink:

Anyway, you could open an issue to certbot's developers just in case the want to add such feature but there are a few issues to create pfx and jks and none of them have been closed... but who knows.

Good luck,
sahsanu

5

The most common formats should be covered. I’d say that what I’m asking for is relatively common.

lighttpd, courier-authdaemon, and vsftpd all use this format from what I’ve seen, and those are pretty important packages.

2 Likes
6

For vsftpd you can use both directives rsa_cert_file pointing to fullchain.pem and rsa_private_key_file pointing to privkey.pem but doesn’t matter, open an issue https://github.com/certbot/certbot/issues and lets see if they want to implement it.

7

Short of PFX files for IIS, I've never had to use both in one (PEM) file.
And I think combining the public and private parts would inherently make that new file confusing for the average person to secure...
Is it public? YES (but only in part)
Is it private? YES (but only in part)
Should I share it? NEVER - but a novice might.

The mixed file example would work well in the hands of an IT/Security pro.
But the counter-example is an IT/Security pro can work with anything.

8

I think it’s a worthy enhancement, especially for a client that aims to do everything for you, like Certbot. haproxy is another very common webserver that uses combined PEM files. I use acmetool specifically because it handles these types of servers.

1 Like
9

I disagree on the grounds that the difference between fullchain, chain, and cert are already confusing enough for new users, adding in another combined file would further that confusion, especially when it’s trivial to combine the parts yourself. Most novice users want to use their certs for Apache or Nginx, so fullchain works, but I’m not sure I agree that needing a combined chain+key file is common enough to warrant another file, or worth the tradeoff in user confusion.

2 Likes
10

That’s a good point, perhaps having more installers (including for those that use combined files) is a better end-game. FWIW acmetool doesn’t create the combined files in the absence of a server that uses them, so the confusion is somewhat mitigated. Even a --combined flag to certonly could help.

1 Like
11

If it’s so trivial as you state, then why don’t we do it?

It’s an extra file. No big deal. Adding this functionality in Certbot would probably take a dev maybe 5 minutes.

It would save server administrators time, remove unnecessary manual tasks, and make a control panel I develop (which ties into Let’s Encrypt functionality) better allowing quicker, seamless Let’s Encrypt integration into everything.

1 Like
12

For the reasons I already stated - given Certbot’s most common use cases, it’s an extraneous file that would generally only serve to further confuse novice users, as it’s not common to have a need for this file (as opposed to fullchain, which is more commonly used than the certificate itself.)

There are a lot of other Let’s Encrypt clients, including ones that do generate this combined file, such as acmetool. Certbot was never meant to be the client for everyone, it was meant to be a client for a lot of people.

That all being said, I do like @_az’s suggestion of another flag for certonly that would specifically request this behavior.

13

Agreed it should NOT be the default.
But allowing it to be requested… that makes more sense.

14

Default behavior should cover as many use cases as possible (including this common format). You’re complaining about having an additional file on the file system. How embarrassing.

15

Hi @own3mall,

We had a long discussion about this on GitHub a while ago. I can try to find it for you. I wouldn’t consider the issue permanently settled one way or another, but it’s a longstanding discussion.

This tradeoff is tricky because lots of users have already been confused between cert.pem and fullchain.pem (using the former where they ought to use the latter). If we do add more files, it seems like it will create new possibilities for confusion for some users, while also being of help to other users.

16

The default behavior should be to ask the end user what they want or automatically search the system for potential uses and then list what it found and ask the end user to enable/disable from that list.
Not stuff the system with more than it can possibly ever use or need… simply because you can.
And, FYI, things are only “common” to those that use them (often).
In all my cases, this format is very “uncommon” and would never get used.

17

I’m not sure if this has already been mentioned yet and I’m not sure what the problem is here since you can easily shell script the process very easily with basic commands. Just create a script which creates the file by appending fullchain.pem to the file containing private key and the full chain upon successful execution of Certbot.

You could do something like:

certbot blah blah && cp /etc/ssl/letsencrypt/{domain}/privkey.pem /destination/path/fullcertchain.pem && cat /etc/ssl/letsencrypt/{domain}/fullchain.pem >> /destination/path/fullcertchain.pem

This also eliminates the possibility of breaking something if “–deploy-hook” is ever deprecated in some future release of certbot. Using hooks looks like it can only complicate things when there are simpler solutions available that don’t depend on software that is continually being updated.

FYI: File extensions .cer, .crt, and .pem are the same format.

18

@travisrunyard

I believe you missed the point. I already am using a script (cronjob) to combine them, but that’s just it, I shouldn’t have to manually do a thing!

Certbot gets and then manages a certificate so whenever it’s renewed / changed / updated it would be nice if Certbot would also create / update / manage the combined certificate format file.

Programs were meant for automation. The less things I have to do manually, the more useful I find a program, and that’s my own approach I use when developing.

1 Like
19

Oh sorry about that. I believe scripting was meant for automation more so than programs though. Anyways I’ve never been issued one combined file that included the private key and full chain by any CA that I have used in the past.

20

We can always change things :smiley: