On Tue, Jul 19, 2016 at 11:49:06AM +0100, Paul Jakma wrote: > On Tue, 19 Jul 2016, David Lamparter wrote: > > Thanks; the problem there is a different one though - my hosting setup > > has a separate reverse proxy doing all TLS handling; i.e. the > > patchwork setup can't access its own certificates. I'm using the ACME > > DNS method to get my LetsEncrypt certificates for my own domains > > (which the TLS box handles perfectly on its own, and I like the clear > > security zoning with that); on the other hand the HTTP method becomes > > very cumbersome to use since I'd need to push either the auth-tokens > > or certificates around between zones. > > Ah, ok. > > > For now I'm very tempted to not sink additional time into it and leave > > it as https://patchwork.diac24.net -- is there a real demand/need to > > have https://patchwork.quagga.net too? > > I don't know! I guess HTTPS-by-default is better, if easy to do, but > probably not important enough for this. > > There apparently is a way to do the LetsEncrypt validation via DNS > records, but I don't know if ACME clients support that (the ACME client > I use does not). If that was a fairly static key to setup and your > client worked with that, could try that.
That's what my setup uses for everything else; my ACME client writes to my zonefiles through a small script. The solution with minimal total sum of work for both of us is probably if you change the dns record for patchwork.quagga.net to: patchwork.quagga.net. IN NS ns.diac24.net. so I can put the acme challenge there and get the certificate. (My DNS server already serves the zone, set that up in the past 5 min) -David _______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
