A naïve proposal to propagate server-certs (NOT CAs!) between Friendica/Red instance
This is probably un-doable and/or unsecure as hell. But if it works, it could be a sweet way to deal with the "no self-signed certs" rule on the Free Social Web.
The big picture
Every instance publishes her own certificate (self-signed or not) in a special place, referenced from .well-known. Servers discovers (but don't validate, more on that later) certificates from one another as messages go between them (probably in the same time they discover themselves through webfinger).
If they feel it's adequate - and verified and so on - server admins can chose to review and re-publish remote certs as being "verified". Users will then have access to a page showing every cert "trusted" by their Friendica's host, maybe with some information about it (expiration date, maybe a trick - https-hosted picture? - to show if it's already verified by the browser or not, etc.).
That way, people who can trust (for they already added its cert) ServerA might be able to see (and add) cert from ServerB, who AdminA chose to trust. If cert is "natively" (... show moreThis is probably un-doable and/or unsecure as hell. But if it works, it could be a sweet way to deal with the "no self-signed certs" rule on the Free Social Web.
The big picture
Every instance publishes her own certificate (self-signed or not) in a special place, referenced from .well-known. Servers discovers (but don't validate, more on that later) certificates from one another as messages go between them (probably in the same time they discover themselves through webfinger).
If they feel it's adequate - and verified and so on - server admins can chose to review and re-publish remote certs as being "verified". Users will then have access to a page showing every cert "trusted" by their Friendica's host, maybe with some information about it (expiration date, maybe a trick - https-hosted picture? - to show if it's already verified by the browser or not, etc.).
That way, people who can trust (for they already added its cert) ServerA might be able to see (and add) cert from ServerB, who AdminA chose to trust. If cert is "natively" (because CA is already present on the browser, for instance), the user won't even have to bother.
The details
There's obviously devil in there. First of all, it doesn't address the SNI problem : there's still no way to efficiently Virtual Host with such setting.
Then does trusting an admin to host our private date mean we trust him to have sane judgement on certs validity? This is mitigated by the fact users would have to add the certificates themselves, but presenting them to a suspect cert could be problematic.
Next?
What to do with that? Is this complete rubbish, or is there something to salvage from that short thought?