Add option for SSL cert algorithm in DuckDNS addon

[tux2000]

• Add optional parameter lets_encrypt.algo in config.json
• Use parameter in run.sh as commandline option to dehydrated
• Update documentation
• Bump version

Closes #2183

[sstefanowski]

I vote for this pull request :)
It will also fix problems with Alexa playback of MP3s stored in HA (exposed via HTTPS and played using SSML Audio tag).
Currently, Alexa cannot access MP3 as it cannot make a handshake with HA secured by a certificate generated with the default algorithm.

@ludeeus
Hi, Could you please consider the approval of this pull request?
I checked the commit history... and it looks like in July you have committed the change including an upgrade of the dehydrated version from 0.6.5 to 0.7.0.
Dehydrated 0.6.5 used rsa as the default "certificate algorithm". Dehydrated 0.7.0 uses secp384r1.
Since that time some HA clients (also important like Amazon Alexa SSML engine) cannot do the HTTPS handshake. It can be successful if a certificate could be generated using another algorithm (e.g. rsa)

[teknomar7]

The "algo" parameter does not appear to be optional as indicated in the documentation. When I updated this morning, duckdns would not start back up without defining an algo k/v.

This was seen in the logs prior to defining the k/v in the configuration (token and dns names have been redacted):

21-09-27 08:30:30 ERROR (MainThread) [supervisor.addons.addon] Add-on core_duckdns has invalid options: Missing option 'algo' in lets_encrypt in Duck DNS (core_duckdns). Got {'lets_encrypt': {'accept_terms': True, 'certfile': 'fullchain.pem', 'keyfile': 'privkey.pem'}, 'token': '<redacted>', 'domains': ['<redacted>'], 'aliases': [], 'seconds': 300}

[btehan]

Same as @teknomar7.

[tux2000]

The changes in dac5764 made the option non-optional.
Not sure what works best, updating the documentation or making the option optional again. I guess forcing all users out there to manually update the configuration will not be optimal...

[teknomar7]

I would think you'd want to have the default value set if not specified. It lists the default value in the documentation as secp384r1, so it seems like not having a default value was the mistake here (not the incorrect documentation). Furthermore, this wasn't a major version bump, which would imply it's not a breaking change per semantic versioning, when this does break functionality without some type of human interaction.

[tux2000]

Yes, this was exactly my reasoning when implementing this parameter as optional. Not sure if something with the implementation as it was in b2f282c did not work or what the reason was that @pvizeli changed the behavior but not the version bump or the documentation prior to merging this to main.

[esenterre]

Well. I had the problem with the upgrade that "algo" is not optional. I don't care adding line to teh config. But I don't know what (sorry for being dummy :) )

For now, I added :
algo: secp384r1
But should it be
algo: rsa
?

[teknomar7]

For now, I added :
algo: secp384r1
But should it be
algo: rsa
?

There isn't a right or wrong answer here. I'd go with the default secp384r1, but if you have some client devices that call your https URL that stop working, see if there are any SSL handshake issues in the logs... which might mean you'd need to switch to RSA. The default secp384r1 is ECC and is supposed to improve performance over RSA from my understanding, but might not work on older devices that never got upgraded to work with that encryption type. Most people probably won't notice the difference between any of the options to be honest.