contact-email does not appear to be mutable

[mbruzek]

Hello @cmars I am really interested in this lets encrypt layer because people had suggested this for other applications. Why is this layer tied to nginx so closely? Would it not be useful for other services that need certificates as well?

I took a look at the reactive code and it does not appear that changing the contact-email will trigger a change in the code making it an immutable configuration option.

Looks like you need to check for any changes to the contact-email option in the config-changed method.

[cmars]

@mbruzek Thanks for pointing this out. I can certainly handle config changes on the contact-email.

To answer your first question -- I tied this layer to nginx to keep it simple. I found it difficult to completely decouple the web server from LE. Using the standalone method gets it most of the way there, but you still need to be able to control the service -- shut it down, run standalone, then start it up.

Thinking about it some more.. I could make the controlled service name a layer option. Then it'd be more easily reusable with other services, and I could drop the hard-coded embedding of layer:nginx.

I also considered implementing one of the tls interfaces (forget which one it's called exactly), so it could "just work" with layer:tls-client. That just made my use case more complex than needed, but perhaps with the service name configurable, this layer could be composed into a CA shim for LE?

[jamesbeedy]

@cmars you mean like a drop in replacement for the easyrsa charm, that would basically implement the provides side of the tls-certificates relation?

[jamesbeedy]

@mbruzek, @cmars I'm not seeing how this layer is tied to layer nginx in any way ... am I missing something here?

[cmars]

@jamesbeedy To answer your questions. 1- yes, a drop-in that implements the same endpoints as easyrsa, but only provides certs through LE. I'm still unsure about the precise use case for such a thing, but the idea is interesting.

2- this layer includes layer:nginx. @mbruzek makes a good argument that it doesn't really need to.

[jamesbeedy]

@cmars, @mbruzek here's a use case:

load-balancer (ssl-termination) -> (web-appN (ssl-termination))

I am blocked right now trying to automate the distribution of cert/key pairs to the things that need them, and hence getting my juju deployed apps wrapped up with ssl/tls all the way through. To do this, both the load-balancer, and the N web-apps will all need the same cert/key pair for each application.

Not sure if this constitutes something that could be handled in a generic way, or if I should just continue passing the key/cert through unitdata?

[jamesbeedy]

@cmars, @mbruzek I currently make the leader request the cert/key, and then pass it via custom interface to the subsequent non-master units of the application.

[mbruzek]

@cmars I wrote both the layer:tls and the easyrsa charm and know that they both are not perfect and have room for improvement. I would be willing to collaborate with you on a generic cert/key interface or layer convention so that we can drop in Let's Encrypt or EasyRSA.

@jamesbeedy Helped me on the layer:tls work, for that I thank you.

I'm not seeing how this layer is tied to layer nginx in any way ... am I missing something here?

The reactive code calls service.restart('nginx') beyond importing the nginx layer. My only point here was kubernetes needs certs & keys for its api server that is not nginx powered and I would like to be able to use this layer as an option for the Kuberentes stuff as well.

The easyrsa and the layer:tls do not do key rotation, and invalidation of keys. To my knowledge neither does this layer.

Make no mistake TLS on distributed systems is hard, but if we combine our powers we could create something better than what we could alone.

[cmars]

@mbruzek Quite a derail there. I'd be happy to work on improving the tls layers/interfaces longer term though! I've been wanting to integrate an openvpn charm with easyrsa if it hasn't been done yet -- that'd be some nice VPN agility right there.

Back to the original issue: looked into changing the contact email address, I think LE supports it with letsencrypt register --update-registration. Will need to test this out.

You might also be interested to know that @jamesbeedy and I landed more improvements to layer:lets-encrypt today. It no longer requires layer:nginx, and the README is improved. This might be what you're needing for k8s.

[galgalesh]

@cmars, @mbruzek

I just stumbled upon this. I'm the maintainer of the OpenVPN Charm. The Charm uses the luxflux/openvpn Puppet module that generates certs using easy-rsa.

Feel free to poke around at the Charm to see if it can integrate with the easy-rsa interface, would be cool if that was possible!

[cmars]

@galgalesh That looks really cool! I'll have to try this one out, I like to use disposable VPNs when I travel.

You might find this command useful to automate importing the ovpn file: https://github.com/mattyw/openvpn-charm/blob/master/Makefile#L34

[galgalesh]

Updating email of a cert was introduced in certbot 0.8 (register --update-registration). The version shipped with 16.04 is 0.4.1.

Possible ways forward:

• Install newer version of certbot.
• Wait for 18.04. and document the immutability in the README
• Remove cert and re-register when email changes

Thoughts?

[cmars]

• Wait for 18.04. and document the immutability in the README

I'm inclined toward this solution for now. Maybe certbot 0.8 can be snapped?