Hi Federico, A lot of good ideas to dig but right now I also need to put my energy on other priorities. I know the problem and will see on time how to address that.
Thanks Le vendredi 17 février 2017 14:54:53 UTC+5:30, Federico Capoano a écrit : > > Hi Xavier > > See inline replies > > On Fri, Feb 17, 2017 at 5:27 AM Xavier Maysonnave <x.mays...@gmail.com > <javascript:>> wrote: > >> Hi Federico, >> >> I was thinking a little deeper about this topic and here are my thoughts. >> >> Originally I started with a crytpic issue I got at the router level a >> curl error code 60 because I didn't thought to use the appropriate >> directive in my playbook. >> Then I started to figure out how to address that. >> >> In my plan I would like to identify my routers with a hostname like >> xx-yy-zz-sequence.mydomain. >> > > Nice! > > >> As LEDE or OpenWRT generates their own self-signed certificates as >> OpenWisp do I started to wonder if the controller could help in that matter. >> The aim of the controller is to control the routers. >> > > It could help. OpenWISP can already automatically generate VPN > certificates for VPN clients so there's a mechanism to deal with this kind > of functionality, although it was designed for VPNs and not for TLS, but it > could be adapted by somebody willing to work on it. > > On the other side such tools are meant to be part of an infrastructure and >> probably not accessible publicly. >> Routers will use a PPTP or an OpenVPN tunnel to talk with servers >> (managers, db, freeradius, controllers, monitoring, etc...) >> This approach limits the needs of a public Letsencrypt system as you >> pointed out. >> > > Cool. If you want to use an OpenVPN tool, OpenWISP2 provides an automated > way to create a VPN template which is bound to a CA and generates client > certificates automatically. > > We haven't built in out of the box support for PPTP yet. > > In my organization we use our own CA and as such only the people who >> manage the servers will need to load the appropriate CA in their browser. >> If the controller can generates certificates with a loaded CA and help to >> deploy the certificates it will be very convenient. >> > > For the long-term, some automated mechanism can be implemented with some > work. But we need to attract more contributors in order to be able to > achieve this. I cannot work on this feature right now because my company > (which runs the public wifi service from which OpenWISP was born) doesn't > need this right now. > > For the short term, you can probably get away by using the same self > signed certificate (maybe a *.mydomain.com?) and putting that certificate > into a template in OpenWISP2, which overwrites the default certificate > auto-generated by luci-ssl. Not 100% sure it would work because I'm not > sure if the browser would complain for some reason anyway, but it wouldn't > cost a lot for you to try. > > >> I would say that from a letencrypt point of view the effort is useless >> however from an infrastructure point of view the appropriate tooling at the >> controller level will be very useful. >> > > Yes. A few months ago I thought about a generic and extensible way to add > this kind of functionality via a concept called "generator templates". > > Immagine it like a template, but instead of putting in static values, the > generator references some kind of generator backend (like a configuration > backend) which takes some parameters as input and returns some output each > time it is associated to a configuration. Here's a few examples of how it > could work. > > Example1: TLS certificate generator > you setup this generator once, setting stuff like CA and other input > parameters, and each time it is associated to a configuration it will > generate a new TLS certificate that will be used by luci > > Example2: Ip address generator > there could be a generator that talks to an external service like > https://phpipam.net/, so you could set in the generator the parameters > for the connection to its API, and the generator could automatically figure > out an ip address to allocate for each configuration > > Example3: VPN client certificate generator > the automatic VPN client feature that is now built with an adhoc > implementation could be implemented with a generator and the adhoc > implementation could be removed. This would be very similar to the TLS > certificate generator. > > This would be a very powerful feature. But let's be realistic: we don't > have enough resources to implement this right now. But I want to keep this > idea for the future. If we can implement this in a year or so, this feature > can really alleviate a lot of pain that small organisations face when > managing networks. They do a lot of stuff by hand that never gets updated > because those who work on it either do not have the time or are terrified > of breaking stuff. > > The other face of the medal is that this kind of automation is hard to > build and hard to use. It would take many iterations and a lot of patience > to get right. > > Federico > -- You received this message because you are subscribed to the Google Groups "OpenWISP" group. To unsubscribe from this group and stop receiving emails from it, send an email to openwisp+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
