Let's encrypt from RSA to ECDSA message in logs - certificate not generated

[jmcollin78]

Describe the issue you are experiencing

While trying to renew the certificate, I've got this message in logs:

[10:45:47] INFO: Selected DNS Provider: dns-ovh
[10:45:48] INFO: Use propagation seconds: 60
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Are you trying to change the key type of the certificate named home.clouderial.fr from RSA to ECDSA? Please provide both --cert-name and --key-type on the command line to confirm the change you are trying to make.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped

EDIT: the new certificates are not generated. This will cause an major issue because the site will not be visible (in one week for my case).

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

Which add-on are you reporting an issue with?

Almond

What is the version of the add-on?

5.0.9

Steps to reproduce the issue

1. just start the addon to generate a new certificate
2. look at the journal logs

System Health information

System Information

version	core-2023.12.4
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.11.6
os_name	Linux
os_version	6.1.58-haos-raspi
arch	aarch64
timezone	Europe/Paris
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
GitHub API Calls Remaining	5000
Installed Version	1.33.0
Stage	running
Available Repositories	1373
Downloaded Repositories	43

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 11.2
update_channel	stable
supervisor_version	supervisor-2023.12.0
agent_version	1.6.0
docker_version	24.0.7
disk_total	457.7 GB
disk_used	18.3 GB
healthy	true
supported	true
board	rpi4-64
supervisor_api	ok
version_api	ok
installed_addons	Home Assistant Google Drive Backup (0.112.1), Samba share (12.2.0), InfluxDB (4.8.0), Glances (0.20.0), Let's Encrypt (5.0.9), NGINX Home Assistant SSL proxy (3.6.0), SQLite Web (4.0.0), AppDaemon (0.16.0), Piper (1.4.0), Whisper (1.0.0), Mosquitto broker (6.4.0), Zigbee2MQTT (1.33.0-1), Studio Code Server (5.14.2)

Dashboards

dashboards	7
resources	24
views	43
mode	storage

Recorder

oldest_recorder_run	27 décembre 2023 à 21:17
current_recorder_run	2 janvier 2024 à 10:08
estimated_db_size	570.98 MiB
database_engine	sqlite
database_version	3.41.2

Sonoff

version	3.5.3 (a8c6d45)
cloud_online	9 / 9
local_online	9 / 9
debug	failed to load:

Anything in the Supervisor logs that might be useful for us?

-

Anything in the add-on logs that might be useful for us?

[10:45:47] INFO: Selected DNS Provider: dns-ovh
[10:45:48] INFO: Use propagation seconds: 60
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Are you trying to change the key type of the certificate named home.clouderial.fr from RSA to ECDSA? Please provide both --cert-name and --key-type on the command line to confirm the change you are trying to make.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped

Additional information

No response

[jmcollin78]

Switching from ECDSA to RSA in the configuration page have resolve the issue.
Maybe one explication line in the README should be important for others.

[supersebbo]

Just had the exact same issue. This is going to catch a lot of people out, especically those who rely on an automation to renew their certs and don't routinely monitor the logs.

[burntoc]

I had this issue as well. Toggling to rsa fixed it. On a whim, I decided to change it back to ecdsa and tried again and it seems that works now, too.

[supersebbo]

I had this issue as well. Toggling to rsa fixed it. On a whim, I decided to change it back to ecdsa and tried again and it seems that works now, too.

Interesting, I wonder why that works. At a guess the latest version of Lets Encrypt defaults to ECDSA but won't auto convert unless explicitly instructed with the right parameter. Probably the new type switch setting in the add-on doesn't get applied until you set it in the settings screen.

[W90W2A]

It shouldn't work for a key renewal. cerbot requires explicit user inputs to change key type, it's called out in the code and has been this way since 2.0 changed the default cert to P-256:

This function ensures that the user will not implicitly migrate an existing key from one type to another in the situation where a certificate for that lineage already exist and they have not provided explicitly --key-type and --cert-name.

I've tried to toggle between RSA and ECDSA in the add-on to see if I could replicate what @burntoc observed and the add-on will not issue an ECDSA based cert no matter how many times I toggle back and forth. Seems explicit migration code will need to be added for key renewals (or folks wanting to switch will have to figure out some workaround for the initial migration).

Also, I'm not sure that the add-on modifying the configuration of existing installs is the best approach given that ECDSA certs are still not universally supported. Even if the renewal issue is resolved, there's still a strong potential to break existing systems in a way that could be hard to diagnose.

[burntoc]

I thought it was odd it would work as well. I can only go by what the logs indicate, which lacked any errors, and the ceritificate issuance notification. I'd guess more than likely it is still an RSA key used instead the indicated selection of ECDSA.

[hgy59]

I had this issue as well. Toggling to rsa fixed it. On a whim, I decided to change it back to ecdsa and tried again and it seems that works now, too.

Are you sure it works now? IMHO you have to wait until the certificate is renewed to ensure it works.

[jmcollin78]

Are you sure it works now? IMHO you have to wait until the certificate is renewed to ensure it works.

I have generated a new certificate with success after setting the option to rsa.

[burntoc]

You can force an update, IIRC. In any case, I changed my cert from a hostname cert to wildcard at the same time. The certificate info is showing the wildcard cert now, and the public key info shows Elliptical Curve (which is ECDSA), 256 bit.

[hgy59]

Are you sure it works now? IMHO you have to wait until the certificate is renewed to ensure it works.

I have generated a new certificate with success after setting the option to rsa.

my comment was related to the change back to ecdsa that works now too

[matthewpucc]

As others are indicating, switching ecdsa -> rsa -> ecdsa does not work for me for renewals.

[joachimcarrein]

EDCSA gives the same notice for me.
Changing to RSA renews perfectly.

Changing back to EDCSA gives the same notice again.

[samyun]

+1, was on ECDSA, got the error. Switched to RSA, renewed successfully. Switched back to ECDSA, got the error.

Checking the old cert in the browser (before reloading nginx), it's RSA based, which tells me that perhaps there was a change or update somewhere to make the default ECDSA.

It seems to me that the plugin should set the default type to ECDSA for new installations only - if the existing base is all RSA, it should remain RSA for them, since doing the upgrade could be breaking.

Either that or update the plugin to explicitly include both of the inputs it's asking for (with the caveat that this means that users can switch between RSA and ECDSA with no explicit warning).

[lukasmalkmus]

Was caught of guard here, as well. That new option was introduced and defaulted to.