Support certificate and private key PEM in separate files

[rustyx]

Currently HAProxy requires the certificate+private key to be in a single PEM file (the crt option).

This introduces difficulties when integrating with certificate management tools, most of which work with separate certificate/chain and private key PEM files.

A typical example is LetsEncrypt's certbot.

certbot stores the chain in /etc/letsencrypt/live/example.com/fullchain.pem and the private key in /etc/letsencrypt/live/example.com/privkey.pem.

This requires inconvenient and error-prone scripting between the tooling and HAProxy.

Thus hereby a request for a new option privkey, to be able to specify the private key PEM file separately from the certificate.

[wtarreau]

I totally agree on this and remember we've had several discussions in the past about this (one reason being that some people extract the keys from separate archives for example). I believe it is expected to be addressed by William's revamp of the cert loading stuff.

By the way there should be no need for a different option: we can currently look up various extensions (.rsa, .dsa, .ecdsa, .ocsp, and I don't what what else), we'd just need an extra ".key" for example.

[wlallemand]

Agreed, I have an old patch who does that, somewhere on my laptop, but it's not compatible anymore with the changes I made for the SSL.

But indeed it's planned, and I also wanted to use an ".key" extension!

[wlallemand]

Closing as this was implemented in HAProxy 2.2.

[Velociraptor85]

So I was happy to see this feature, BUT.
As @rustyx wrote, the keys are stored in "privkey.pem" files(actually usually referenced to by symlinks) sadly @wtarreau it is not just an additional .key extension.

Additionally as the issue name states the private and the public key are in separate files and apparently haproxy 2.2.0 still expects the fullchain in an file or at least the docker:haproxy:lts-alpine does ... tested it with different global options

• ssl-load-extra-files all
• ssl-load-extra-files bundle
• ssl-load-extra-files none

Each time I receive an error "unable to load certificate from file" or "No Private Key found in xx or yy.key".
You are probably expecting the corresponding private key in a .key file to an public key in an .pem file.

I might be doing something wrong here, still would be nice to get some feedback if someone can reprocude.

[wtarreau]

I must confess I'm really clueless at this level of detail, and I'm afraid we'll have to wait for @wlallemand to be back soon!

[joshxyzhimself]

I think it's currently trying to load the key from fullchain.pem as fullchain.pem.key

/etc/letsencrypt/live/example.com/fullchain.pem
/etc/letsencrypt/live/example.com/fullchain.pem.key (privkey.pem)

[wlallemand]

That's indeed how it works, the same way the bundle, the ocsp and the sctl extension works in HAProxy.
I explained this recently in issue #785

[cmason3]

If I am reading this correctly, @rustyx wanted a way for HAProxy to use "privkey.pem" and "fullchain.pem" separately without combining them (like I do), but the feature deployed doesn't actually allow this as it expects the private key to be in "fullchain.pem.key"? Which means I still need to deploy tooling to convert the output from Let's Encrypt into a format that HAProxy will use - hopefully I have misunderstood as it looks like the issue hasn't been addressed at all?

[wlallemand]

This implementation was the only way to keep the compatibility with how a crt is declared on a bind line, it is explained in bug #785 if you want more details. We are thinking about a new way of configuring this which is not implemented yet if you want to discuss it.

What you can do currently is have 2 files with the same basename, but you can't specify different basename. (so you can have foobar.crt and foobar.key, or foobar.pem and foobar.pem.key). But you don't need to convert anything, you just need to name the files correctly.

[cmason3]

My specific use case was running HAProxy inside Docker with the certs outside - Let's Encrypt handles the renewal and just sends a HUP to HAProxy container if they are updated, but I wanted to avoid the extra step of renaming/combining files, etc. Based on your comments I can create a symlink for the key and that should work.

[wlallemand]

Indeed that would work!

[rustyx]

Yes we also symlink fullchain.pem.key to privkey.pem as a workaround.
It would be nice to be able to specify the key file explicitly, something like crt fullchain.pem key privkey.pem.

[wlallemand]

I understand your concern, please see ticket #785, where it's explained and discussed, your experience could be valuable here.

[huornlmj]

Is this still a thing? Has support for separate private and public keys been added to the roadmap? If someone has already pointed out the security implications of having both in the same place then ignore this section of my comment, if not then there it is. :)
+1

[wlallemand]

@huornlmj the separate .key is already supported since 2.2, however there is still no keyword to specify a customized path, because of the limitation of the bind line, it will be first integrated in the crt-list.