Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Pretty common. Let's Encrypt uses it, few other things I've run across, Matrix homeservers, etc.


Not just Let's Encrypt, if you want to demonstrate control over a web server to get your certificates in the Web PKI ("SSL Certificates") rather than doing something with DNS or emails or whatever, both your options are in the well-known registry.

Certificate Authorities doing ACME (like Let's Encrypt) use /.well-known/acme-challenge/ while those who've rolled their own solution or maybe just adapted some manual process for this modern era are required to use paths starting /.well-known/pki-validation/

Previously to this the problem was if you hand roll solutions a customer eventually says "Oh, I can't create http://example.com/proof.txt you asked for because of [some stupid corporate reason] how about if I name it http://example.com/proof.doc ? And also it will be a JPEG screenshot of an Excel spreadsheet with your text file in it". And eventually your frustrated employee says "Fine, fine, whatever it takes" and next thing you know your policies are so relaxed that a bad guy is able to get a certificate for example.com by uploading the proof file to http://pastebin.example.com/XQGBLP. Oops.

So the Ten Blessed Methods fix a bunch of stuff in this space, clearly control over pastebin.example.com shouldn't get you an example.com certificate for example, but also requiring the files go in specified places in /.well-known/ means chances are if other people can create those files you likely also have a dozen other directory traversal type vulnerabilities and maybe you need to check yourself before you wreck yourself.

Such level playing field rules prevent a race to the bottom for CAs because they don't need to worry that their competitors get an edge by being more lenient than they are, if a competitor breaks the rules you can just rat them out.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: