[CONFIG] Traefik

[boomam]

Hi, Unless im misunderstanding the purpose of CertHub, can we expect a HTTP01 challenge, from an internal service like Traefik to work?

For example, i have a test traefik config set to use certhub as a resolver, like so -

      - "--certificatesResolvers.certhub.acme.email=me@myemail.com"
      - "--certificatesResolvers.certhub.acme.storage=/etc/traefik/acme.json"
      - "--certificatesResolvers.certhub.acme.httpChallenge=true"
      - "--certificatesResolvers.certhub.acme.httpChallenge.entryPoint=http"
      - "--certificatesResolvers.certhub.acme.caserver=http://certhub.domain.com"

Where 'certhub.domain.com' is an internal only routable DNS address.

Is this an expected use case for this app?

Thanks!

[gregtwallace]

Hello, I haven't used Traefik but I looked at the docs. It looks like the "caserver" param you cited is looking for an ACME CA provider (like let's encrypt). This is not what this software provides.

To use this with Traefik, you'd want to look at the user defined option: https://doc.traefik.io/traefik/https/tls/#user-defined Essentially LeGo would make the keys/certs and traefik would need to import them. This adds another layer of complexity and may not be worth it to you depending on your use case.

Hope this helps.

[boomam]

That's a shame - I was hoping it would be compatible in that regards as that could have been a game-changer.

To ask, are there any plans for like-functionality?

I query, as like a lot of setups, having lots of LE requests from different proxies creates a lot of public records and unnecessary requests - having a centralized source of truth, managed in this way would be amazing for a variety of scenarios.

[gregtwallace]

Based on that response, I think it already does what you want.

Essentially you setup Lego. You make the cert(s) you want for your apps (e.g. Traefik) in LeGo. Then you write a script on the client (e.g. Traefik) to fetch the certificates from LeGo with a simple curl. You'd point the Traefik "user defined" cert to where the script is saving the cert.

I'm planning to make a docker container for clients that use LeGo to make this process simpler, but I haven't even started work on it yet, so bash scripts are the best option. See example for docker host: https://github.com/gregtwallace/certificate-scripts/blob/master/lego-docker.sh

I then mount the host path as ro to containers that use the certs: -v /persist/lego/certs:/opt/lego/certs:ro

Many containers need a restart (as done in the example script) to pickup the new certs. You might be able to hot swap them though -- you'd have to test.

[boomam]

I'm not sure relying on scripting is a great idea to expect of end users. It's too easy to get wrong, and brittle to config issues.

Whereas relying on a native methodology of most cert request compatible systems is a much more scalable way to do things, whilst also reducing the potential for support issues - you specify "this is how you connect" in an industry standard way, and that's all the app would need to do, or would need to support.

Opens the door to much more use cases too, without any additional work on your part.

If not planned though, to each their own. Thanks for responding!

[gregtwallace]

The app is essentially an interface to translate between the acme server and cert users that don’t implement the acme protocol.

Originally I was thinking this suggestion isn’t possible because there is no way to provide a trusted CA without a remote acme server. However, it did just dawn on me that I suppose I could implement essentially a shim to wrap the remote acme server which would probably pretty easy without authenticating users. I’m not really sure how I’d authenticate users of the shim though.

Edit: I suppose I could use EAB.