In February 2023 (so, a year before this feature request!), I had made the suggestion for LL to get a free certificate from CAcert — but on the SL Wiki where nobody reads it :)

The theory behind that was the following...

LL requires some agility in generating lots of certificates in a short time (as soon as servers boot up, I believe). That makes the process difficult, since CAs may take too long to respond for each individual instance. Therefore, the only alternative would be for LL to get one of those one-size-fits-all certificates, the kind that would cost an arm and a leg. Let's Encrypt (LE) would be a possible alternative, but back then LE didn't offer so-called wildcard certificates.

Thus, CAcert. They have been around for eternities (I mean... since 2003). When it became obvious that to really get a security certificate, you'd need a second mortgage on your home (or your business!), they tried to become what Let's Encrypt is today. Unfortunately, they're underfunded (academics...) and understaffed, and, as a consequence, they are unable to meet the 2020s "golden standards" of certificate authorities, imposed by Mozilla (and adopted by all others in the CA/B Forum, the authority body deciding what certificate authorities root certificates ought to be included in their browsers or not).

To be fair to CAcert... they tried. Every few years or so, a few volunteers grab all their documentation, and knocks at the CA/B Forum's door to present their case. They're familiar faces there — CAcert even got "observer's status" (non-voting) at some stage and contributed to lots of information to make the certification process to be what it is today (and were credited — and thanked! — for their participation).

Unfortunately for them, they also got involved in a polemic, a decade ago or so, where they automatically signed "fake" certificates in good faith, creating havoc with some Very Naughty Scammers now suddenly getting the clean green lock icon when browsing to their scamming/phishing site. The CA/B Forum immediately revoked all root certificates from CAcert and expunged them from all browsers, which, at the time, all got a "mandatory upgrade", so to speak. Needless to say, this didn't happen to CAcert, of course. The difference is that others which have long ago been expelled were malicious; CAcert was naïve and careless. As a consequence, Mozilla stepped up their requirements for CA authorities, and excluded CAcert for not meeting the minimum requirements — at that time, all that was required was to check that the alleged domain owner could, in fact, create mailboxes under that domain, which they didn't bother to check (as said, naïve...).

Anyway. This is just for historic reasons. CAcert is cool, but their root certificate is not trusted beyond a very limited Web of Trust (which is actually how X.509 certificates are to work), and, as such, it would require interested parties to download CAcert's root certificate and install it locally. But to do that, we can use LL's own pseudo-CA-root instead, and the results will be essentially the same. The difference between accepting a LL-self-signed root certificate and one from CAcert is that , so there is a risk. By contrast, nobody can forge CAcert's own self-signed root certificate, nor any certificates emitted by CAcert. Their problem is that too few people actually have root certificate installed, so, any certificate emitted by CAcert will, on a "default installation", include their root certificate.

I'd say that all the above is moot — to a degree. Firstly, because Let's Encrypt allows wildcard domains, so LL just needs to acquire one of those for free, and basically install them everywhere. This is less secure and also has the disadvantage that LL gets no control over each individual certificate — all servers would have the exact same one. If you wish to revoke the certificate on just server, you need to revoke it for . It's a bit more cumbersome but certainly doable!

Plan B would be to get each LL server to connect to Let's Encrypt and retrieve their own, personalised, unique certificate. That works as well, it's just a level of more complexity for LL's system administrators. I'm not sure if, these days, Amazon cannot handle such things as well via their own private certificate authority service. As far as I can see, the costs are not overwhelmingly high, and what essentially happens (if I understood everything properly!) is that Amazon acts as a root certificate authority (which they are!) and signs LL's own root certificate as an "intermediate" authority, which, in turn, allows LL to emit as many certificates as they want — for a small fee (less than 1 USD) each time they do that.

In essence, the effect would be the same if LL's current root certificate was signed by Amazon. They wouldn't need to do anything else except start paying Amazon :)

Note that those certificates are legitimate, even if they don't automatically turn Linden Lab into a certificate authority — Amazon restricts the certificates it signs to domain names owned by Linden Lab. But being an "intermediate" authority a big deal. In fact, until very recently, Let's Encrypt merely an intermediate authority — they just had two (or three?) top certificate authorities (the kind that will be pre-installed in every browser, server, desktop, laptop, mobile device, or IoT device out there...) sign certificate, which states that Let's Encrypt was authorised to emit certificates of their own. They issued millions and millions of certificates that way — all of which were perfectly valid and legitimate. Over the years, of course, Let's Encrypt acquired a level of confidence and good reputation that allowed them to knock at the CA/B Forum's doors and petition to be accepted as a root authority, instead of "merely" an intermediate one. And they got accepted (unlike CAcert!). That means that every browser out there now also includes a Let's Encrypt root certificate. The real advantage is a bit more obscure — because LE signs the certificates, as opposed to relying upon a complex Web of Trust where they merely acted as an intermediate, the certificates are . And that counts, when you want to open gazillions of TLS connections simultaneously and need to send them all your certificate — the shorter you can make it, the better.

Incidentally, this recognition as a top root certificate authorities allowed Let's Encrypt to start provisioning their vast user base with those wildcard domain certificates. As a fully-fledged certificate authority, Let's Encrypt can now do pretty much what they want :) (so long, of course, that they behave within the strict rules of the Mozilla guidelines for accreditation of certificate authorities, of course).

So... to conclude...

All the above is moot. LL, get a Let's Encrypt wildcard certificate, and save us from the chore of using self-signed certificate, which can be easily abused/forged. Or, if you wish to do it properly, buy into the AWS Private CA service — it's not astronomically expensive, and you'll get everything you have now, managed through Amazon's own web services, with the difference that all those certificates (under control!) will be , certificates, which will be able to accept in absolute safety.

Make it so.

Even creating content from web is problems now with new CEF and CORS issues as rest of the world is SSL now. This is a must. At very least CA should be added to CEF's trust store for llRequestSecureURL

Or, at the very least, provide LL's internal CA to be added to whoever wants to access the endpoint securely.