Adding certificate authentication for users might be a neat feature, but I don’t see why it would be limited to the MWS. This could live alongside the existing HTTP Basic authentication and Header authentication methods (https://tiddlywiki.com/#WebServer%20Authentication).
Typically, the service would trust a particular CA root for authenticating clients and any valid certificate that is rooted in a chain from that trusted CA would be allowed. Then, the service can perform authorization (ie: what the user is allowed to access) based on the principal identified in the valid certificate. There are two separate concepts, although they are often bundled together into a single logical step.
ACME is an automated method for issuing certificates typically used by servers, not for end-user applications like web browsers. So integrating ACME into TiddlyWiki could allow it to automatically request and renew certificates (versus using the tls-cert
and tls-key
parameters to the web server). However, there would still need to be a way to get user certificates into the web browser.
Although user authentication is certainly within the scope of mTLS, the “clients” in most mTLS discussions are usually other servers. If I’m setting up a “server” that’s actually multiple Node.js processes, a database, a Redis instance, etc., then adding mTLS means that each of these components are using TLS (EDIT: and using certificates on both the “client” and “server” side of the connection) when they talk to each other.
Running TiddlyWiki as a single-wiki Node.js server or as the MWS is only a single Node.js instance, so there aren’t any other components for which we would need an encrypted communication channel. In MWS, the database is embedded, so even that doesn’t required a network connection. The place I could see mTLS being relevant is to protect communication between a reverse proxy like caddy or nginx to a TiddlyWiki instance. ACME support isn’t necessary for that, although it could certainly make automating the certificate management more simple.
I see two separate but related ideas here:
- User authentication via client certificates.
- Server certificate automated request and renewal via ACME
#1 would be an interesting new feature. It could especially be useful in corporate or government environments, where it’s slightly more likely that end-users will have some form of PKI loaded into their web browser. For general public use, I’m not aware of any simple, user-friendly way of getting certificates for the masses.
For #2, there are already some ways this could be implemented without needing to actually make changes to TiddlyWiki. ACME command line tools like certbot or amce.sh could be used to request and renew certs programmatically, while TiddlyWiki is configured to point to the certificates those tools output.