Hiya, On 15/07/2019 18:30, Jacob Hoffman-Andrews wrote: > This seems like a clever idea! As Ted said, .well-known probably isn't > the right directory for it. If you put something in .well-known, that > suggests you plan to standardize it and register it with IANA.
Sure, I'm not scared of .well-known or IANA:-) IIUC, the .well-known registry rule is specification required, so it'd not have to be a standard. Clearly though, if nobody else wanted to use it, there's not much point in having it in the registry. > I'll also note that you may have a bootstrapping problem: Assuming that > you verify certificates on those polling requests to your web server, > this solution won't work before you've actually issued your first > certificate. Similarly, if there's every a problem that results in your > live certificate expiring, this process would fail. Yes. For me, that's ok as I can sort both manually. I'm not sure if it'd be worth trying to automate those, as people for whom those are big issues are (I'm guessing, but don't know), likely to have a DNS API to use. But I'd be fine with adding some way to handle bootstrap and expiry if there's something reasonable that can be done there. >> It's also worth noting that Let's Encrypt requires DNS challenges for > wildcards because they demonstrate more control over the domain > namespace, and are less vulnerable to temporary hacks of the web server. > You fully control the namespace, so you definitely have the ability to > delegate that control in any way you see fit. Just keep in mind that > this allows someone with temporary access to your nameserver to get a > more powerful wildcard certificate than they otherwise would be able to. Yep, in my case the zone factory is in total control of the zones. I didn't say earlier but the script I run on the zone factory knows the exact names that'll be handled in this manner, won't poll for (challenges for) any other names, and hence I think it's ok in that respect. > > If you wanted to add some more security, you could narrow the scope of > accepted certificates on the polling connection to your web host, or > (even better) have some file-level signing of the fetched JSON. Since > you control both sides, an HMAC (rather than a public key signature) > would suffice. Ack. > > Lastly, have you seen acme-dns? This might be another way to accomplish > the same thing, and has the advantage that more people are using it and > therefore more likely to find bugs. https://github.com/joohoi/acme-dns I hadn't seen that, no. Don't think it'd work for me, as we have an existing DNS setup that we'd like to keep using. Cheers, S. >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
