Technology

A certificate fundamentally only does the following, it binds a name and a public key together and attaches a signature to that binding.

Anyone can make a certificate binding any key to any name and put their own signature on it, they just can't fake others people's signatures. This is also what you do if you self sign a certificate. If you then install the public key of your signing key in your webbrowser you can connect to your own services using your TLS key and your browser will check that the server presents the certificate with a matchign signature proving that it is using the right TLS key.

You can also bind your TLS key to www.wikipedia.org and sign it. However nobody else knows your signing key, and thus nobody would trust the certificate you signed. Which is a good thing, because otherwise it would be easy for you to impersonate Wikipedia's website.

The value of trusted certificates lies in the established trust between the signers (CAs) and the software developers who make browsers etc. The signers will only sign certificates to bind names and TLS keys for the people who actually own the name, and not for third parties.

The validation of ownership is the thing that varies a lot. The simple way is just checking for control of the web server currently reachable under a name, or checking for control of the DNS entries for a name, but the more complicated validations check business records etc.

So when you're asking do they protect better, it's kind of difficult to say.

• If you can validate the signature yourself, say you have control of the browser and the server, then your own signature is fine, and a trusted one wouldn't be any better.
• But if you want third parties, that don't know you, to be able to verify that their TLS session is established to a person who actually owns the domain, rather than a man in the middle, then the only practical solution today is using that established trust system.
• If you are asking about the encryption strength of the TLS session itself, then that's completely independent of the certificate issue, because again the certificate only binds a name to a key with a signature. You can bind an old short key, whose private key has been leaked before to a name, or you can bind a modern long key that is freshly generated to the same name. You can used either key in a good or a bad cryptographic setup. You can use deprecated SSL 3.0 or modern TLS 1.3. Those choices don't depend on who signs the certificate.

I hope that helps, sorry for writing so much

because if you roll your own root cert, nobody's web browsers will see it as trusted, they all will warn the user that something weird is happening and treat the site as if it was plain HTTP. no lemmy server would federate with it for the same reason.