3 ms·
It's not hard to convert to HTTPS and it doesn't cost a lot. I have to disagree. Certificates are still a pain in the butt. The reason is that the only fr
by TekMol 3y ago
It's not hard to convert to HTTPS
and it doesn't cost a lot.
I have to disagree. Certificates are still a pain in the butt.
The reason is that the only free and "easy" solution is Let's Encrypt. And they make it a pain in the butt.
You can get a certificate for domain.com by putting a file into domain.com/.well-known/ - so far so good.
But you cannot get a wildcard certificate for domain.com this way.
For no reason as far as I know. Who owns domain.com but not bla.domain.com?
And I don't want all my subdomains listed in a public directory. So only a wildcard cert makes sense for me.
Which means fiddling with DNS entries every 3 months. Or setting up some complex, brittle scheme to automatically update those every 3 months. Which then depends on the API of some name server provider. Which will work differently for every provider.
- woodruffw 3y agoThere's general consensus in the Web PKI world that wildcards in certificates were a mistake. RFC 6125 has an entire section dedicated to security considerations[1]. > For no reason as far as I know. Who owns domain.com but not bla.domain.com? Many, many services[2]. DNS is fundamentally hierarchical, but not in a way that implies authority or control: the owners/operators of `com.` should not be able to obtain a wildcard certificate for `*.com.` and thereby read the traffic of `google.com`, `facebook.com`, etc. [1]: https://datatracker.ietf.org/doc/html/rfc6125#section-7.2 https://datatracker.ietf.org/doc/html/rfc6125#section-7.2 [2]: https://en.wikipedia.org/wiki/Public_Suffix_List https://en.wikipedia.org/wiki/Public_Suffix_List