On Fri, 2015-01-02 at 09:40 +0000, David Woodhouse wrote: > > The latter is probably difficult, but printing the hash and key IDs is > > probably a good idea. I'll check it. > Well, if the luci https service is using the *same* cert as ocserv then > presumably it's already been accepted. No it is not. I don't think it is a good idea to mix keys for different services. It will also not bring much benefit since the luci https service is not typically available from the wan side of a router. > It would be nice for openconnect on the desktop to be capable of using > Chrome's? "I have already accepted this cert" trust status. I don't know what is that. The windows client uses trust on first use for server certificates. > While I think about the luci https service sharing a cert with ocserv... > are we capable of having it share a *socket*? Port 443 is very useful > for getting through firewalls/proxies; it would be good to have them > both accessible through it. The methods to share a port are currently pretty primitive and require a service to forward packets like sniproxy does. That would be an overkill in a router environment. A superserver which will transfer the socket descriptors between the processes would have been nice there, but there is no such thing yet. However, since the luci https service is not typically available on the wan side, it wouldn't matter much. I think it would be doable to forward the 443 from the wan side to ocserv (never tried it though). regards, Nikos