> SSH

Still requires a passphrase or initializing a keypair on the client & server.

> HTTPS

HTTPS requires user interaction when a site forgets to renew a certificate.

Also SSH and HTTPS don't compare well. One does client authentication, the other doesn't.

You absolutely can do client authn in HTTPS, but it's rarely done outside intranet apps and high-security banking.

Your complaint about a login system is about its authentication, in a discussion on encryption and key exchange?

The obvious point being made is that going from SMS -> E2E should be as seamless as from telnet -> ssh.

SMS and messaging systems generally do require some level of authentication so you're making a ridiculous comparison.

auth_pam/auth_basic in the nginx config and the http/https does authentication.

And far less space to mess things up than with coding a fancy login page.

Counterpoint: I work for a company that sells software to mostly big companies. Sometimes they want to host it themselves. Creating valid certificates usable for HTTPS is a never-ending support issue.

Someone else suggested acme. What about SCEP (aka Microsoft NDES)?

There are a number of ways to cut certs internally.

Looks promising. I hadn't heard of it before. Although I'm not super close to the operational/deployment side of things.

You should support ACME.

Doesn't help on the intranet that easily, when the application runs on a domain not on public DNS. Also ACME can be problematic from policy POV.

My working theory is that the Venn diagram of organizations self-hosting software on an intranet with private DNS and organizations that don't have an internal CA is almost entirely disjoint.

Are the policy concerns you raise related to the above, or something else?

Your diagram is wrong tho.

Some of our customers have no trouble with certificates. The others have never heard of ACME.

But they shouldn't have to have heard of ACME to use it. If they're hosting your software on a publicly-accessible server, the UX should be roughly:

- user checks box that says they want certs issued automatically.

- your software handles the rest.

Of course there are plenty of details for the engineers to work out, but the end user shouldn't need to know any of them.

The ones that are self-hosting are more-or-less doing it specifically so that they can use non-publicly-accessible servers. So I guess that won't work.

I was thinking that you were imagining that they would need to set up some kind of internal ACME infrastructure or something. Now I see you were just imagining certbot. Maybe half the domains I've seen used aren't actually publicly resolvable. Once I saw one that was, but was actually owned by someone else.

Anyway, there is no easy way out.