Caddy 2 integration about certificates HOT 6 CLOSED

Caddy's http and tls are apps in Caddy 2:
https://github.com/caddyserver/caddy/blob/v2/modules/caddyhttp/caddyhttp.go
https://github.com/caddyserver/caddy/blob/v2/modules/caddytls/tls.go

from certificates.

Feel free to spin out new tickets. Happy to chat on Slack if there are any questions/plans. Awesome integration in Caddy2! Check out https://caddyserver.com/docs/automatic-https

from certificates.

@maraino And this is a good point, maybe a better place to integrate would be within one of the existing apps (probably the tls app) -- definitely up for discussion.

What are some steps to the process that you wish you could eliminate to make this even better? Let's leverage Caddy's strengths with smallstep's and see what is possible.

from certificates.

@mholt I was just adding those links as a reference. I've been looking at those files, and I think the integration would be quite straightforward.

Without taking into account how the password are managed, a simple app would look like:

type App struct {
    *authority.Config
    srv *ca.CA
}

func (a *App) Start() error {
    srv, err := ca.New(a.Config)
    if err != nil {
        return err
    }
    go srv.Run()
    a.srv = srv
    return nil
}

func (a *App) Stop() error {
     return a.srv.Stop()     
}

Things to take into account:

1. How to obtain the passwords? config?, environment variables?
2. Is there any way to support reloads?
3. Instead of using ca.Run() add a new method that receives a net.Listener so we can check that we are able to listen in that port and return an error.
4. ...

from certificates.

That looks like a good start for an app, definitely.

How to obtain the passwords? config?, environment variables?

Sure, either of those is fine -- note that plaintext passwords in the config means that -- in an automated environment -- it's probably stored in plaintext elsewhere, so if the configs are secure, then that shouldn't be a problem for most threat models. Caddy's configs are ephemeral (i.e. there's not necessarily any config files, so config can be POSTed over a secure socket and then is stored in memory only, generally) so storing passwords in them isn't the worst thing.

Env variables are also a possibility of course. In Caddy we prefer to keep the config as consolidated as possible, though: i.e. all together in one place, rather than relying on system environment, CLI flags, or anything outside the JSON config. So I think my vote would be for the JSON document itself. (Maybe wait for a feature request before adding env variables?)

Is there any way to support reloads?

Caddy can manage listeners gracefully through reloads (caddy.Listen), but the specifics of reloads will depend on your app. We can look at this together if you'd like some guidance. (I am not yet familiar with smallstep's internals but I suppose that will change.) These graceful reloads also work on Windows!

Instead of using ca.Run() add a new method that receives a net.Listener so we can check that we are able to listen in that port and return an error.

Yep, ideally, you'd have a way to be passed a listener that is already listening on a port. (You'd get it from caddy.Listen.)

from certificates.

This is still a WIP, but as an update:

• Caddy can issue certificates with proper PKI, including fully-managed CA certs
• Caddy can embed a Smallstep ACME server as of tonight (https://twitter.com/mholt6/status/1243408326311854080)

Still lots to do, but the big pieces are starting to come together.

Next steps, probably:

• Polish current features a bit (will need some help on your end for a few little things, I will open issues about those as needed)
• Enable using ACME to get client certificates (not really Smallstep-specific, but useful for a lot of Smallstep users)

from certificates.