New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bundle cert and privkey (lighttpd) #1201

Open
kuba opened this Issue Oct 29, 2015 · 44 comments

Comments

Projects
None yet
@kuba
Contributor

kuba commented Oct 29, 2015

#1190 (comment) - apparently lighttpd requires single file with both private and public key...

@pde pde added this to the Nice for 1.0 milestone Oct 30, 2015

@kuba kuba changed the title from Provide publicprivatekey.pem (lighttpd support) to Provide certkey.pem (lighttpd support) Oct 30, 2015

@kuba kuba changed the title from Provide certkey.pem (lighttpd support) to Provide cert_and_key.pem (lighttpd support) Oct 30, 2015

@kuba

This comment has been minimized.

Show comment
Hide comment
@kuba

kuba Oct 30, 2015

Contributor

Reporter was wrong. According to http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL#Configuration it's a "PEM file for SSL support (Should contain both the private key and the certificate)".

Contributor

kuba commented Oct 30, 2015

Reporter was wrong. According to http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL#Configuration it's a "PEM file for SSL support (Should contain both the private key and the certificate)".

@kuba

This comment has been minimized.

Show comment
Hide comment
@kuba

kuba Nov 1, 2015

Contributor

I find docs pretty confusing:

ssl.pemfile path to the PEM file for SSL support (Should contain both the private key and the certificate)
ssl.ca-file path to the CA file for support of chained certificates

What goes where?

Contributor

kuba commented Nov 1, 2015

I find docs pretty confusing:

ssl.pemfile path to the PEM file for SSL support (Should contain both the private key and the certificate)
ssl.ca-file path to the CA file for support of chained certificates

What goes where?

@kuba kuba changed the title from Provide cert_and_key.pem (lighttpd support) to Bundle cert and privkey (lighttpd) Nov 1, 2015

@kuba

This comment has been minimized.

Show comment
Hide comment
@kuba

kuba Nov 1, 2015

Contributor

Me thinks ssl.pemfile == cert.pem + privkey.pem, ssl.ca-file == chain.pem

Contributor

kuba commented Nov 1, 2015

Me thinks ssl.pemfile == cert.pem + privkey.pem, ssl.ca-file == chain.pem

@kuba kuba referenced this issue Nov 1, 2015

Open

pfx bundle #1276

@tohn

This comment has been minimized.

Show comment
Hide comment
@tohn

tohn Nov 2, 2015

@kuba That's correct :)

tohn commented Nov 2, 2015

@kuba That's correct :)

@charno

This comment has been minimized.

Show comment
Hide comment
@charno

charno Nov 4, 2015

FYI: My workaround is simple: $ cat /etc/letsencrypt/live/<domain>/privkey.pem /etc/letsencrypt/live/<domain>/cert.pem > /etc/letsencrypt/live/<domain>/combined.pem, lighttpd.conf is
ssl.pemfile = "/etc/letsencrypt/live/<domain>/combined.pem" ssl.ca-file = "/etc/letsencrypt/live/<domain>/chain.pem"

charno commented Nov 4, 2015

FYI: My workaround is simple: $ cat /etc/letsencrypt/live/<domain>/privkey.pem /etc/letsencrypt/live/<domain>/cert.pem > /etc/letsencrypt/live/<domain>/combined.pem, lighttpd.conf is
ssl.pemfile = "/etc/letsencrypt/live/<domain>/combined.pem" ssl.ca-file = "/etc/letsencrypt/live/<domain>/chain.pem"

@josch

This comment has been minimized.

Show comment
Hide comment
@josch

josch Nov 4, 2015

pound and ejabberd also require private key and cert in the same file

josch commented Nov 4, 2015

pound and ejabberd also require private key and cert in the same file

@bwesterb

This comment has been minimized.

Show comment
Hide comment
@bwesterb

bwesterb Nov 4, 2015

How to fix this? Add a fourth file managed by letsencrypt.storage?

bwesterb commented Nov 4, 2015

How to fix this? Add a fourth file managed by letsencrypt.storage?

@kuba

This comment has been minimized.

Show comment
Hide comment
@kuba

kuba Nov 5, 2015

Contributor

Simplest solution is add a fourth file. However, I don't think we should do that, because there are more configurations that we need to support (we now know of at least #1250, #1276) and managing all those will be a nightmare. My idea was to create a new installer plugin that does that instead. Design decision needs to be taken before any work on those issues is started.

Contributor

kuba commented Nov 5, 2015

Simplest solution is add a fourth file. However, I don't think we should do that, because there are more configurations that we need to support (we now know of at least #1250, #1276) and managing all those will be a nightmare. My idea was to create a new installer plugin that does that instead. Design decision needs to be taken before any work on those issues is started.

@nitmir

This comment has been minimized.

Show comment
Hide comment
@nitmir

nitmir Nov 5, 2015

pure-ftpd (like ejabberd as @josch said and like #1250 ) need one single file contening key + cert + chain
Using cat to build it is only prone to forget to do it again at each auto renewal.

nitmir commented Nov 5, 2015

pure-ftpd (like ejabberd as @josch said and like #1250 ) need one single file contening key + cert + chain
Using cat to build it is only prone to forget to do it again at each auto renewal.

@nitmir

This comment has been minimized.

Show comment
Hide comment
@nitmir

nitmir Nov 5, 2015

As a small hack, I put the code below in a daily cron :

#!/bin/bash
for dir in $(ls -d /etc/letsencrypt/live/*); do
    cat $dir/privkey.pem $dir/fullchain.pem > $dir/fullkeychain.pem
done

nitmir commented Nov 5, 2015

As a small hack, I put the code below in a daily cron :

#!/bin/bash
for dir in $(ls -d /etc/letsencrypt/live/*); do
    cat $dir/privkey.pem $dir/fullchain.pem > $dir/fullkeychain.pem
done
@cweiske

This comment has been minimized.

Show comment
Hide comment
@cweiske

cweiske Nov 8, 2015

courier-imapd-ssl also requires the public key and the private key in a single file.

cweiske commented Nov 8, 2015

courier-imapd-ssl also requires the public key and the private key in a single file.

@mjrider

This comment has been minimized.

Show comment
Hide comment
@mjrider

mjrider Nov 10, 2015

haproxy also likes to have a combined file with the contents of fullchain.pem and privkey.pem
@kuba a 'custom' installer plugin which runs a (in the config ) provided script could fix the whole everybody has a different environment problem. And would make installation automation easier to integrate mass hosting configurations where generic apache/nginx configuration mutations are not an option.

mjrider commented Nov 10, 2015

haproxy also likes to have a combined file with the contents of fullchain.pem and privkey.pem
@kuba a 'custom' installer plugin which runs a (in the config ) provided script could fix the whole everybody has a different environment problem. And would make installation automation easier to integrate mass hosting configurations where generic apache/nginx configuration mutations are not an option.

@pde

This comment has been minimized.

Show comment
Hide comment
@pde

pde Nov 11, 2015

Member

I fear that despite the inelegance of adding four more files in the live/ directory, perhaps we should do that (and also make sure we add a README file at the same time, saying which ones are appropriate for which software).

Part of the reason is that rather than stub installers that spit out certs and chains in funny formats, what we really want is installer plugins for haproxy, courier-imapd-ssl, pure-ftpd etc. And we'll be happier if in general those installers don't need to be re-run with full force at renewal time; there's a lower probability of things going wrong if (say) the haproxy daemon can just be reloaded to pick up a new cert file from /etc/letsencrypt/live/ directory. But that's only possible if the client handed the haproxy plugin a set of files that are sufficient for filling all the necessary lines in the haproxy conf file. We don't currently have a way to run two installers let alone two in a particular order (stub installer to make a special file, haproxy installer to use it).

On the other hand, it will suck to have private keys in any of the files in /etc/letsencrypt/live. So maybe this can only work if the formats that have keys in them can go in /etc/letsencrypt/keys :(

Member

pde commented Nov 11, 2015

I fear that despite the inelegance of adding four more files in the live/ directory, perhaps we should do that (and also make sure we add a README file at the same time, saying which ones are appropriate for which software).

Part of the reason is that rather than stub installers that spit out certs and chains in funny formats, what we really want is installer plugins for haproxy, courier-imapd-ssl, pure-ftpd etc. And we'll be happier if in general those installers don't need to be re-run with full force at renewal time; there's a lower probability of things going wrong if (say) the haproxy daemon can just be reloaded to pick up a new cert file from /etc/letsencrypt/live/ directory. But that's only possible if the client handed the haproxy plugin a set of files that are sufficient for filling all the necessary lines in the haproxy conf file. We don't currently have a way to run two installers let alone two in a particular order (stub installer to make a special file, haproxy installer to use it).

On the other hand, it will suck to have private keys in any of the files in /etc/letsencrypt/live. So maybe this can only work if the formats that have keys in them can go in /etc/letsencrypt/keys :(

@pde

This comment has been minimized.

Show comment
Hide comment
@pde

pde Nov 11, 2015

Member

A third option: we make all the keyless file formats by default. For the ones that contain keys, there is an authenticator ("certonly") flag to request the extra format from storage.py. Those can have warnings on them saying that they leave keys lying around in /etc/letsencrypt/live. When there's an installer for haproxy, using it with letsencrypt run can imply the appropriate authenticator setting.

Member

pde commented Nov 11, 2015

A third option: we make all the keyless file formats by default. For the ones that contain keys, there is an authenticator ("certonly") flag to request the extra format from storage.py. Those can have warnings on them saying that they leave keys lying around in /etc/letsencrypt/live. When there's an installer for haproxy, using it with letsencrypt run can imply the appropriate authenticator setting.

@pde

This comment has been minimized.

Show comment
Hide comment
@pde

pde Nov 11, 2015

Member

I like option 3. @kuba, wdyt?

Member

pde commented Nov 11, 2015

I like option 3. @kuba, wdyt?

@kuba

This comment has been minimized.

Show comment
Hide comment
@kuba

kuba Nov 11, 2015

Contributor

We probably do want haproxy, courier-imapd-ssl, pure-ftpd installers. However, there is no time to implement them now. Having a "swiss-army" installer that spits out various cert/chain/key combinations is the best temporary solution IMHO.

Your third option still seems to require users to manual concat/split files, which is really suboptimal.

Contributor

kuba commented Nov 11, 2015

We probably do want haproxy, courier-imapd-ssl, pure-ftpd installers. However, there is no time to implement them now. Having a "swiss-army" installer that spits out various cert/chain/key combinations is the best temporary solution IMHO.

Your third option still seems to require users to manual concat/split files, which is really suboptimal.

@mjrider

This comment has been minimized.

Show comment
Hide comment
@mjrider

mjrider Nov 11, 2015

fourth option:
having a exec installer which calls a external command in my usecase, it would concat 2 files and place them in /etc/ssl/haproxy/10-domainname.pem and trigger a reload of haproxy, no custom haconfig file changes needed, because haproxy load all the certs in that folder.
a simple plugin for the installer which just exec's a command and checks if the exit code is 0 shouldn't be that much work

something like:
exec /path/to/script /path/to/cert.pem /path/to/chain.pem /path/to/privkey.pem

mjrider commented Nov 11, 2015

fourth option:
having a exec installer which calls a external command in my usecase, it would concat 2 files and place them in /etc/ssl/haproxy/10-domainname.pem and trigger a reload of haproxy, no custom haconfig file changes needed, because haproxy load all the certs in that folder.
a simple plugin for the installer which just exec's a command and checks if the exit code is 0 shouldn't be that much work

something like:
exec /path/to/script /path/to/cert.pem /path/to/chain.pem /path/to/privkey.pem

@NEOatNHNG

This comment has been minimized.

Show comment
Hide comment
@NEOatNHNG

NEOatNHNG Nov 11, 2015

I would propose that we go for the first option and add more files but modify the code so that it is not so cumbersome to add more formats. This has the advantage that auto-renewal also works for these more exotic formats.

What is the problem with formats containing private keys in /etc/letsencrypt/live? We already do that with the privkey.pem and it doesn't get worse just because there are multiple files instead of one. If we expect that we will have custom installers for most of the popular software anyway at some time then the additional number of formats is also not a big problem because then the installer would just fill in the right file name.

If we have a swiss-army installer command one would still have to execute that manually on every renewal, right? That doesn't sound like the user friendliest solution to me. On another thought: how do we handle running daemons on certificate renewal anyway? Is there some logic to send a reload to the daemon if it was set up via an installer command?

@mjrider: would haproxy also accept a symlink from /etc/ssl/haproxy/10-domainname.pem to /etc/letsencrypt/live/chainprivkey.pem assuming chainprivkey.pem was a file in the right format?

NEOatNHNG commented Nov 11, 2015

I would propose that we go for the first option and add more files but modify the code so that it is not so cumbersome to add more formats. This has the advantage that auto-renewal also works for these more exotic formats.

What is the problem with formats containing private keys in /etc/letsencrypt/live? We already do that with the privkey.pem and it doesn't get worse just because there are multiple files instead of one. If we expect that we will have custom installers for most of the popular software anyway at some time then the additional number of formats is also not a big problem because then the installer would just fill in the right file name.

If we have a swiss-army installer command one would still have to execute that manually on every renewal, right? That doesn't sound like the user friendliest solution to me. On another thought: how do we handle running daemons on certificate renewal anyway? Is there some logic to send a reload to the daemon if it was set up via an installer command?

@mjrider: would haproxy also accept a symlink from /etc/ssl/haproxy/10-domainname.pem to /etc/letsencrypt/live/chainprivkey.pem assuming chainprivkey.pem was a file in the right format?

@mjrider

This comment has been minimized.

Show comment
Hide comment
@mjrider

mjrider Nov 13, 2015

@NEOatNHNG srry for the delay, the answer is yes

mjrider commented Nov 13, 2015

@NEOatNHNG srry for the delay, the answer is yes

@martinburger

This comment has been minimized.

Show comment
Hide comment
@martinburger

martinburger Dec 12, 2015

Note: For haproxy, it would be sufficient to have a combined file with the contents of privkey.pem and cert.pem. It does not require the contents of file fullchain.pem.

martinburger commented Dec 12, 2015

Note: For haproxy, it would be sufficient to have a combined file with the contents of privkey.pem and cert.pem. It does not require the contents of file fullchain.pem.

@shinji257

This comment has been minimized.

Show comment
Hide comment
@shinji257

shinji257 Dec 20, 2015

ZNC actually needs this arrangement. For that matter I think this may apply to any server coded in python.

shinji257 commented Dec 20, 2015

ZNC actually needs this arrangement. For that matter I think this may apply to any server coded in python.

@Wolf480pl

This comment has been minimized.

Show comment
Hide comment
@Wolf480pl

Wolf480pl Feb 18, 2016

@shinji257 ZNC actually requires privkey, fullchain, and dhparam PEMs all catted together in that order into the znc.pem

Wolf480pl commented Feb 18, 2016

@shinji257 ZNC actually requires privkey, fullchain, and dhparam PEMs all catted together in that order into the znc.pem

@shinji257

This comment has been minimized.

Show comment
Hide comment
@shinji257

shinji257 Feb 18, 2016

@Wolf480pl It is recommended but not required. The current pem I'm using doesn't include the dh params section although I did generate one on the side when I was working on it at first.

shinji257 commented Feb 18, 2016

@Wolf480pl It is recommended but not required. The current pem I'm using doesn't include the dh params section although I did generate one on the side when I was working on it at first.

@kousu

This comment has been minimized.

Show comment
Hide comment
@kousu

kousu Feb 19, 2016

@shinji257 , any server? Not true, the core python SSL library uses the split file setup that's easier to handle:

import ssl
t = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)
t.load_default_certs()
t.load_cert_chain("localhost.crt","localhost.key")

I second that ZNC is not picky: I am using cat fullchain.pem privkey.pem > /etc/znc/cert.pem, so that's fullchain, privkey, an no DH params, in that order.
If software is picky about order then we're probably entirely lost. Doesn't everyone just call out to OpenSSL? So it's handling teasing apart the sub-pieces and will do it the same everywhere.

kousu commented Feb 19, 2016

@shinji257 , any server? Not true, the core python SSL library uses the split file setup that's easier to handle:

import ssl
t = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2)
t.load_default_certs()
t.load_cert_chain("localhost.crt","localhost.key")

I second that ZNC is not picky: I am using cat fullchain.pem privkey.pem > /etc/znc/cert.pem, so that's fullchain, privkey, an no DH params, in that order.
If software is picky about order then we're probably entirely lost. Doesn't everyone just call out to OpenSSL? So it's handling teasing apart the sub-pieces and will do it the same everywhere.

@shinji257

This comment has been minimized.

Show comment
Hide comment
@shinji257

shinji257 Feb 19, 2016

@kousu I'll accept the correction on that. I've worked with many python based servers that only accepted one file so I made a general educated assumption about it.

shinji257 commented Feb 19, 2016

@kousu I'll accept the correction on that. I've worked with many python based servers that only accepted one file so I made a general educated assumption about it.

@kousu

This comment has been minimized.

Show comment
Hide comment
@kousu

kousu Feb 19, 2016

Well that just proves the bigger point: its so much easier to take one file even when the underlying library can take two that we will never convince everyone to adapt, so letsencrypt must.

On February 19, 2016 3:47:38 AM EST, Robert Pendell notifications@github.com wrote:

@kousu I'll accept the correction on that. I've worked with many
python based servers that only accepted one file so I made a general
educated assumption about it.


Reply to this email directly or view it on GitHub:
#1201 (comment)

kousu commented Feb 19, 2016

Well that just proves the bigger point: its so much easier to take one file even when the underlying library can take two that we will never convince everyone to adapt, so letsencrypt must.

On February 19, 2016 3:47:38 AM EST, Robert Pendell notifications@github.com wrote:

@kousu I'll accept the correction on that. I've worked with many
python based servers that only accepted one file so I made a general
educated assumption about it.


Reply to this email directly or view it on GitHub:
#1201 (comment)

@jmtd

This comment has been minimized.

Show comment
Hide comment
@jmtd

jmtd Apr 18, 2016

I've started working on this.

jmtd commented Apr 18, 2016

I've started working on this.

jmtd added a commit to jmtd/letsencrypt that referenced this issue Apr 18, 2016

WIP: write out a combined privkey + cert
This is WIP, hasn't been tested and this branch will be rebased.

This is to resolve #1201 (Bundle cert and privkey (lighttpd))
@jmtd

This comment has been minimized.

Show comment
Hide comment
@jmtd

jmtd Jun 17, 2016

Ok, I've finally tested what I did in https://github.com/jmtd/letsencrypt/commits/1201-bundle-cert-and-privkey and fixed the test file too. It appears to have worked, at least for how I use certbot (certonly plugin). It is rough around the edges and suggestions for improvement and testing (especially other usage scenarios) would be very welcome

jmtd commented Jun 17, 2016

Ok, I've finally tested what I did in https://github.com/jmtd/letsencrypt/commits/1201-bundle-cert-and-privkey and fixed the test file too. It appears to have worked, at least for how I use certbot (certonly plugin). It is rough around the edges and suggestions for improvement and testing (especially other usage scenarios) would be very welcome

@jmtd

This comment has been minimized.

Show comment
Hide comment
@jmtd

jmtd Jun 17, 2016

...tests don't actually pass yet though, will keep plugging away

jmtd commented Jun 17, 2016

...tests don't actually pass yet though, will keep plugging away

@jmtd

This comment has been minimized.

Show comment
Hide comment
@jmtd

jmtd Jun 23, 2016

OK the tricky part now is to handle renewals gracefully, where the old bundle didn't have "privkeyandcert". Is there any precedent for this already -- managing a situation where the configuration (dictionary) differs?

I might special-case privkeyandcert so that it doesn't cause a failure if it does not exist, going to see how messy that looks.

jmtd commented Jun 23, 2016

OK the tricky part now is to handle renewals gracefully, where the old bundle didn't have "privkeyandcert". Is there any precedent for this already -- managing a situation where the configuration (dictionary) differs?

I might special-case privkeyandcert so that it doesn't cause a failure if it does not exist, going to see how messy that looks.

@schoen

This comment has been minimized.

Show comment
Hide comment
@schoen

schoen Jul 7, 2016

Contributor

@jmtd, it's not clear whether we want to continue to track all of the associated archive objects in the renewal configuration file if we add a whole bunch of them (although it does raise a question of how code that uses a certificate lineage should be able to figure out exactly which kinds of objects are being managed by and existing within that lineage). This applies to questions about new private key types too, for example.

Contributor

schoen commented Jul 7, 2016

@jmtd, it's not clear whether we want to continue to track all of the associated archive objects in the renewal configuration file if we add a whole bunch of them (although it does raise a question of how code that uses a certificate lineage should be able to figure out exactly which kinds of objects are being managed by and existing within that lineage). This applies to questions about new private key types too, for example.

@jmtd

This comment has been minimized.

Show comment
Hide comment
@jmtd

jmtd Jul 7, 2016

@schoen, thanks for the comment. To get this (back) into a working state, I think I'm going to try and make it so that the various consistency checks are permitted to fail for this new archive object if it doesn't exist in a lineage, and see where that leaves us.

jmtd commented Jul 7, 2016

@schoen, thanks for the comment. To get this (back) into a working state, I think I'm going to try and make it so that the various consistency checks are permitted to fail for this new archive object if it doesn't exist in a lineage, and see where that leaves us.

@rimas-kudelis

This comment has been minimized.

Show comment
Hide comment
@rimas-kudelis

rimas-kudelis Oct 4, 2016

@JTMD: is there any progress with this?

rimas-kudelis commented Oct 4, 2016

@JTMD: is there any progress with this?

@jmtd

This comment has been minimized.

Show comment
Hide comment
@jmtd

jmtd Oct 6, 2016

Hi @rimas-kudelis, sorry no, no progress since July. I've gone a bit cold on this, as (IMHO) the certbot code is really hard to work on, and I've "solved" this locally with a shell wrapper, and I might move away from lighttpd anyway... but I haven't completely given up. I'll see if I can pick this back up this week.

jmtd commented Oct 6, 2016

Hi @rimas-kudelis, sorry no, no progress since July. I've gone a bit cold on this, as (IMHO) the certbot code is really hard to work on, and I've "solved" this locally with a shell wrapper, and I might move away from lighttpd anyway... but I haven't completely given up. I'll see if I can pick this back up this week.

@rimas-kudelis

This comment has been minimized.

Show comment
Hide comment
@rimas-kudelis

rimas-kudelis Oct 6, 2016

Actually, I'm more interested in a "full" file (#1250).
Anyway, isn't it possible to work around both of these issues with a renew-hook? If it is, I wonder if anyone could give me an example of one.

rimas-kudelis commented Oct 6, 2016

Actually, I'm more interested in a "full" file (#1250).
Anyway, isn't it possible to work around both of these issues with a renew-hook? If it is, I wonder if anyone could give me an example of one.

@bmw

This comment has been minimized.

Show comment
Hide comment
@bmw

bmw Oct 14, 2016

Contributor

@rimas-kudelis, yes it is possible to work around this issue with a renew-hook. Such a script might look something like:

#!/bin/sh
for domain in $RENEWED_DOMAINS; do
    if [ "$domain" = example.org ]; then
        cat "$RENEWED_LINEAGE/privkey.pem" "$RENEWED_LINEAGE/fullchain.pem" > /desired/path/to/server.pem
        service lighttpd reload
    fi  
done

To use this script with Certbot, you'd change your renewal command to something like certbot renew --quiet --renew-hook /path/to/above/script.sh. You can include other if/elif branches if you want to perform other actions when renewing a different certificate.

Contributor

bmw commented Oct 14, 2016

@rimas-kudelis, yes it is possible to work around this issue with a renew-hook. Such a script might look something like:

#!/bin/sh
for domain in $RENEWED_DOMAINS; do
    if [ "$domain" = example.org ]; then
        cat "$RENEWED_LINEAGE/privkey.pem" "$RENEWED_LINEAGE/fullchain.pem" > /desired/path/to/server.pem
        service lighttpd reload
    fi  
done

To use this script with Certbot, you'd change your renewal command to something like certbot renew --quiet --renew-hook /path/to/above/script.sh. You can include other if/elif branches if you want to perform other actions when renewing a different certificate.

@GigabyteProductions

This comment has been minimized.

Show comment
Hide comment
@GigabyteProductions

GigabyteProductions Apr 18, 2017

I'm currently using this method to concatenate the files for ejabberd. I think it would help if there was an option to run renew-hook on initial issuance. I'm avoiding an unnecessary --force-renewal by running my hook manually after a certonly call, but it'd suck if I didn't notice a failure in production renewal right away when issuing multiple certificates in different environments like this.

GigabyteProductions commented Apr 18, 2017

I'm currently using this method to concatenate the files for ejabberd. I think it would help if there was an option to run renew-hook on initial issuance. I'm avoiding an unnecessary --force-renewal by running my hook manually after a certonly call, but it'd suck if I didn't notice a failure in production renewal right away when issuing multiple certificates in different environments like this.

@moneytoo

This comment has been minimized.

Show comment
Hide comment
@moneytoo

moneytoo Apr 18, 2017

In my cron.daily:

certbot renew --quiet --renew-hook 'systemctl reload nginx postfix dovecot ; chmod 755 /etc/letsencrypt/live && for dir in $(ls -d /etc/letsencrypt/live/*); do cat $dir/privkey.pem $dir/fullchain.pem > $dir/privkeyandcert.pem; done && systemctl restart ejabberd'

moneytoo commented Apr 18, 2017

In my cron.daily:

certbot renew --quiet --renew-hook 'systemctl reload nginx postfix dovecot ; chmod 755 /etc/letsencrypt/live && for dir in $(ls -d /etc/letsencrypt/live/*); do cat $dir/privkey.pem $dir/fullchain.pem > $dir/privkeyandcert.pem; done && systemctl restart ejabberd'
@GigabyteProductions

This comment has been minimized.

Show comment
Hide comment
@GigabyteProductions

GigabyteProductions Apr 18, 2017

I have a renew hook working. I was just adding that there's no option to run the hook on the first run of certbot.

GigabyteProductions commented Apr 18, 2017

I have a renew hook working. I was just adding that there's no option to run the hook on the first run of certbot.

@jmtd

This comment has been minimized.

Show comment
Hide comment
@jmtd

jmtd Apr 19, 2017

@moneytoo you rotate your LE certs daily?

jmtd commented Apr 19, 2017

@moneytoo you rotate your LE certs daily?

@moneytoo

This comment has been minimized.

Show comment
Hide comment
@moneytoo

moneytoo Apr 19, 2017

@jmtd

certbot renew

This command attempts to renew any previously-obtained certificates that expire in less than 30 days.
...
Since renew only renews certificates that are near expiry it can be run as frequently as you want - since it will usually take no action.

moneytoo commented Apr 19, 2017

@jmtd

certbot renew

This command attempts to renew any previously-obtained certificates that expire in less than 30 days.
...
Since renew only renews certificates that are near expiry it can be run as frequently as you want - since it will usually take no action.
@ethaniel

This comment has been minimized.

Show comment
Hide comment
@ethaniel

ethaniel Nov 3, 2017

Need this in haproxy!

https://www.digitalocean.com/community/tutorials/how-to-secure-haproxy-with-let-s-encrypt-on-ubuntu-14-04

Combine fullchain.pem and privkey.pem
When configuring HAProxy to perform SSL termination, so it will encrypt traffic between itself and the end user, you must combine fullchain.pem and privkey.pem into a single file.

ethaniel commented Nov 3, 2017

Need this in haproxy!

https://www.digitalocean.com/community/tutorials/how-to-secure-haproxy-with-let-s-encrypt-on-ubuntu-14-04

Combine fullchain.pem and privkey.pem
When configuring HAProxy to perform SSL termination, so it will encrypt traffic between itself and the end user, you must combine fullchain.pem and privkey.pem into a single file.

@indrora

This comment has been minimized.

Show comment
Hide comment
@indrora

indrora May 3, 2018

Bumping this. I'd suggest we add in renewal.conf a means to provide specific combinations of cert, key, chain, etc.

indrora commented May 3, 2018

Bumping this. I'd suggest we add in renewal.conf a means to provide specific combinations of cert, key, chain, etc.

@Harvie

This comment has been minimized.

Show comment
Hide comment
@Harvie

Harvie Jun 2, 2018

Same problem with courrier... Currently i use this workaround:

renew_hook = cat /etc/letsencrypt/live/testmail.arachne.cz/privkey.pem /etc/letsencrypt/live/testmail.arachne.cz/fullchain.pem > /etc/letsencrypt/live/testmail.arachne.cz/combined.pem ; systemctl reload-or-try-restart postfix courier-imap-ssl

Harvie commented Jun 2, 2018

Same problem with courrier... Currently i use this workaround:

renew_hook = cat /etc/letsencrypt/live/testmail.arachne.cz/privkey.pem /etc/letsencrypt/live/testmail.arachne.cz/fullchain.pem > /etc/letsencrypt/live/testmail.arachne.cz/combined.pem ; systemctl reload-or-try-restart postfix courier-imap-ssl

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment