You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To add a simpler option to creating a TLS enable RPC server, where the current options are discussed here, kwild's RPC servers can incorporate an ACME client for automatic x509 certificate management (think Let's Encrypt).
This handles the case where there is a FQDN and the operator wants to enable HTTPS (TLS) for their RPC service but does not want to either deal with self-signed certificates or a reverse proxy + certbot to do this outside of kwild.
This will require a small amount of research to choose the best ACME client that fits into our application most naturally: https://go-acme.github.io/lego/
The text was updated successfully, but these errors were encountered:
I know we talked in-person, but just for completeness:
I think this is pretty outside the scope of Kwil, and the maintenance burden we should take on. I think it would be much simpler to provide a suggested nginx configuration (as you suggested), and expecting users to manage their own reverse proxy.
To add a simpler option to creating a TLS enable RPC server, where the current options are discussed here, kwild's RPC servers can incorporate an ACME client for automatic x509 certificate management (think Let's Encrypt).
This handles the case where there is a FQDN and the operator wants to enable HTTPS (TLS) for their RPC service but does not want to either deal with self-signed certificates or a reverse proxy + certbot to do this outside of kwild.
This will require a small amount of research to choose the best ACME client that fits into our application most naturally: https://go-acme.github.io/lego/
The text was updated successfully, but these errors were encountered: