opnsense
security/acme-client: Expand DNS lexicon support for providers which don't use username/token
The problem:
While DNS lexicon supports a lot of providers that aren't otherwise supported by the acme-client plugin (and even some that are =]) the assumption written into the plugin's dns lexicon support is that all of the providers use the same parameters. Sadly, this is not the case, so there are a number of providers which could work except that they expect the parameters to be named differently.
In my case I specifically needed support for dns.he.net (the henet provider in DNS lexicon).
This solution is not fully ideal -- in an "ideal world" we would change the visible fields based on exactly what fields are expected by each DNS lexicon provider and display the correct fields, etc etc -- and then probably allow custom environment variables to be passed in as well to catch anything added later or which we missed. I don't have time for that, so instead I went this route.
Potential risk:
For any provider which could accept the default "username/token" combination which the plugin has used up to this point I just left it how it was with the assumption that you will just use that, so this should not break anything which currently works unless I've misread or miscopied something. Someone could go over my mappings (compare to the docs linked above) to make sure I didn't mix anything up, but assuming I didn't there should be no real risk because nothing which currently works should be affected.
Non-intuitive mappings:
Some of the providers did take two parameters but they weren't fully a "username / password" mapping; in those cases if it seemed plausible I still mapped something to allow you (if you know what you are doing / read the source) to use the provider. I haven't tested that in the slightest, but since they don't work now I don't expect any real issues if they don't work later either... I figure a non-intuitive workaround is better than no workaround.
What still doesn't work:
There are a number of providers which need more than two parameters and/or can take different combinations; I did not make any attempt to support that. The "easy" way to support it would be to provide a way for the user ("advanced options"?) to manually type in environment variables which would get passed into acme.sh and should let them support anything, but to really fix it elegantly you'd have to do a fair bit more work with the UI, which is outside of my experience.
I have tested this with he.net and it works great; I haven't tested it with anything else because I don't have anything else that I can test it with =] Feedback would be appreciated, my PHP is beyond rusty.
... and yes after doing this I realized that there is a real Hurricane Electric entry which I just overlooked. Ahh, well. this should still make some otherwise unsupported ones work which otherwise wouldn't have =]
Well... this may come as a surprise (sorry), but I thought about dropping support for DNS lexicon altogether. This idea is not new, I actually though about doing it last year, but I couldn't find time to work on this.
Of course, when doing this I would add some code to convert all (supported) lexicon configurations to native os-acme-client configs. The goal would be to take away some of the complexity that was added by introducing lexicon to os-acme-client (and probably also to encourage contributions to acme.sh).
As you've already stated, DNS lexicon partially duplicates what acme.sh already provides. My gut feeling tells me that most DNS lexicon providers are already supported by acme.sh. (At least the ones that are currently available in os-acme-client). Using DNS lexicon also introduced severel new (python) dependencies, and more would probably follow in the future.
Any thoughts on this? Are there any providers that are crucial but not supported by acme.sh?
Currently namecheap support on haproxy if you have ipv6 enabled only works with dns lexicon (there is an open issue for this) and constellix support is only available through dns lexicon. I can't speak to any others since I haven't tried them, but those definitely I would be DOA without dns lexicon support right now.
Hmm; I referenced an issue but after looking again I realized it's the wrong one. I'll have to look again to find it when I have time, but namecheap doesn't work if you have ipv6 on your box unless it's been fixed maybe in acme.sh? not sure. IIRC it was because it used curl ifconfig.co to determine the ip address which would return an ipv6 address which namecheap wouldn't accept.
Hi @taxilian, FYI, in the upcoming os-acme-client 4.0 most lexicon providers will be migrated to acme.sh DNS APIs: https://github.com/opnsense/plugins/pull/3751/commits/c856f6e5d26937fb99fc406db86291758cf19f40
This includes namecheap. I would appreciate if you would be able to test namecheap with acme.sh DNS API again. os-acme-client 4.0 is still in development, so I may remove the namecheap migration if it causes trouble for you.
Note that although I'll deprecate lexicon in os-acme-client 4.0 and most DNS providers will be unsupported from that point, there's no removal date yet. (I don't plan to remove functionality without offering a replacement – a few DNS providers are still not supported by acme.sh.)
I'll close this PR now, because I want to focus efforts on native acme.sh DNS APIs. Anyway, thanks for the effort that you've put into this PR – I know it can be frustrating when it's not getting merged. Sorry that I've failed to communicate my plans for lexicon upfront.
I'm actually not using namecheap DNS for anything anymore, so I can't really test that. This is no longer affecting me, so I'll just say kudos on improving things and I'll let you know if I have further issues in the future =]