Skip to content
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

Update haproxy deploy hook #1591

Merged
merged 25 commits into from May 1, 2019

Conversation

Projects
None yet
5 participants
@andrewheberle
Copy link
Contributor

commented May 10, 2018

Updated version of the haproxy deploy hook.

This version differs from the initial version as follows:

  1. Requires specifying the PEM filename rather than a path
  2. Supports creating a ".ocsp" file to support OCSP stapling in HAProxy
  3. Supports creating a ".issuer" file, which is the issuing CA's certificate (this is needed for the OCSP support)
  4. Corrects the order of key, certificate, issuer in the PEM file in the initial version (although HAProxy does not seem to care)
  5. Supports mulit-cert bundles to allow HAProxy to serve RSA or ECC certificates on the same listener/frontend. This creates the above ".pem", ".issuer" and ".ocsp" files with a ".rsa" or ".ecc" suffix depending on the type of the certificate. This does require HAProxy was compiled against a version of OpenSSL that supports this though.

dwatrous and others added some commits May 3, 2018

implement basic haproxy deploy
HAProxy requires the certificate chain and key to be concatenated and placed somewhere (can be anywhere). This script expects a single environment variable with the path where the concatenated PEM file should be written
Merge pull request #1 from dwatrous/patch-2
add docs for HAProxy deployment
Merge pull request #1584 from dwatrous/patch-1
Add HAProxy deploy implementation and documentation
Update haproxy deploy hook
Add functionality to add OCSP stapling info (.ocsp file), issuer (.issuer file) and multi-cert bundles (suffix on pem file based on key type).

This also corrects the order of key, certificate and intermediate in the PEM file, which although HAProxy does not seem to care, was incorrect in the prior version.
Support HAPROXY_DEPLOY_PEM_PATH
Adds compatibility to original haproxy deploy hook while still allowing custom PEM file name (via HAPROXY_DEPLOY_PEM_NAME)
@andrewheberle

This comment has been minimized.

Copy link
Contributor Author

commented May 10, 2018

I've made some changes so the initial haproxy deploy hook variable of "DEPLOY_HAPROXY_PEM_PATH" can be used.

This defaults to "/etc/haproxy" in this version, and the name of the PEM file is set via the "DEPLOY_HAPROXY_PEM_NAME" env var (defaults to ".pem" as per the initial hook by dwatrous).

The above makes all values have some sort of "sane-ish" default. The only part I'm not sure of is my default for the reload command (DEPLOY_HAPROXY_RELOAD) being "systemctl reload haproxy".

Ideally some heuristics here to divine the init system in use may be useful, or alternatively have the default as "/bin/true" so it is a no-op by default which requires the user to set the relevant env var to define the reload action.

andrewheberle added some commits May 14, 2018

@smeijer

This comment has been minimized.

Copy link

commented Jul 27, 2018

Or document that the reload cmd should be specified with --reloadcmd when auto reload is required / wished for

acme.sh --issue --reloadcmd "systemctl reload-or-restart haproxy"

There already is a reload flag, so why introduce another one?

@andrewheberle

This comment has been minimized.

Copy link
Contributor Author

commented Jul 29, 2018

Deploy hooks are expected to work independently of the reloadcmd option based on a comment by @Neilpang in pull request #1584

andrewheberle added some commits Sep 28, 2018

@lapo-luchini

This comment has been minimized.

Copy link

commented Apr 29, 2019

Since HAProxy 1.8 (and 1.9):

With BoringSSL and Openssl >= 1.1.1 multi-cert is natively supported, no need to bundle certificates. ECDSA certificate will be preferred if client support it.

Which makes part of the "bundle" support unnecessary (with very recent installations), but still the current version of the deploy hook writes RSA and ECC on the same target file, overwriting each other so some part of this PR would still be very nice to have.

@Neilpang

This comment has been minimized.

Copy link
Owner

commented Apr 29, 2019

sorry, for the delay.
but please fix the conflicts first.

Thanks.

@andrewheberle

This comment has been minimized.

Copy link
Contributor Author

commented Apr 30, 2019

I have resolved the conflicts in this PR (from the README file only).

I am happy to submit changes to the deploy hook Wiki page to reflect the changes in this PR if it's merged.

@lapo-luchini As far as the usefulness of the "bundle" support...we use it internally here with CentOS 7 which includes a version of openssl is too old for this...but for newer systems? Agreed, it's not particularly useful apart from ensuring RSA and ECC certs don't clobber each other

@Neilpang Neilpang merged commit b28835a into Neilpang:dev May 1, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.