search

opendata-stuttgart / sensors-software

sourcecode for reading sensor data
566 stars 307 forks source link

Replace DST Root CA X3 with ISRG Root X1 #1015

Closed Phaze-III closed 3 months ago

Phaze-III commented 3 months ago

The LetsEncrypt DST Root CA X3 expired in 2021 and was replaced with the ISRG Root X1 CA. The DST Root CA X3 was still a working trust anchor but using it will stop working in 2024. The ISRG Root X1 CA is the preferred one and should be good until 2035.

See also #1013. This PR is against master.

hunter86bg commented 3 months ago

@Phaze-III , OTA update is also failing and the firmware doesn't have a way to "downgrade" to http.

trekawek commented 3 months ago

Hello sensor.community, greetings from the aqi.eco maintainer.

I had similar problem with our API server. As a temporary mitigation, I used the previous certificate, which was still signed by the DST Root CA X3 and valid until April. I don't know your setup, but you may be able to do the same, to allow the OTA update. In Let's Encrypt it was as easy as using older files from the /etc/letsencrypt/archive/...

Phaze-III commented 3 months ago

At this moment it looks like the SC-servers are indeed using a previous certifcate which is cross-signed and should work for a few weeks. For the next few months it is also possible to force a certificate renewal using the 'old' cross-signed chain. With certbot that would be something like:

certbot --force-renewal --preferred-chain 'DST Root CA X3'

That would buy some extra time (a few months) to release new firmware for OTA upgrades.

Phaze-III commented 3 months ago

The server(s) also need a RSA key-type instead of the current ecdsa type. With certbot that would be:

certbot --force-renewal --preferred-chain 'DST Root CA X3' --key-type rsa

MichaelDvP commented 3 months ago

Thanks to @Phaze-III for this solution. Meanwhile the https connections to madavi and opensensmap are also broken. For madavi we can disable https, but opensensmap is fixed in code. This PR is working and solve the issue for all connections. I've updated my sensor at home, but for some others i have no physical access and need OTA-Update. Is there a way to wake up the maintainers. There is not a single response in forum, issue-tracker, here, etc.

Please maintainers: Merge this commit and trigger OTA update!

hunter86bg commented 3 months ago

I hope we get an OTA update as thousands of devices need a simple way to be updated.

compidev commented 3 months ago

Is this project dead? How comes there hasn't been a fix in two weeks or at least a statement?

ricki-z commented 3 months ago

Because this is a voluntered project and we may not have the spare time to answer to all requests on all channels. Most users asked for help by email, while we tried to find a solution. To answer all these request was very time consuming.

At the moment the certificates for our sites are working again (also for api-rrd.madavi.de, where the certificate was renewed yesterday). And now we can work on a solution for the firmware. @MichaelDvP thanks for testing the firmware. But the OTA process is another topic. If this doesn't work correctly we will have more than 10.000 devices not working anymore.

OpenSenseMap is completely independent from us, so we can't answer questions regarding their sites. Beside this they got millions of EU fundings for their project, but are unable to tell the people that most of the devices shown on their map are build following our instructions and running with our firmware (1300 daily active devices at the moment, 4300 a month before) ... So our motivation to further support this project is very low.

hunter86bg commented 3 months ago

@ricki-z , I would like to become more actively involved. Anything I can help ?

ricki-z commented 3 months ago

@Phaze-III and @hunter86bg Is there a way to check https against 2 certs? We will have a phase where th active devices will connect to servers with X3 and X1 certs. I.e. i can switch to ISRG Root X1 on the firmware server when mostly all devices have updated.

And just a thought: Would it help to add an 'alpha build' version, where the last merged version is available? This version would be very(!) alpha and should be used only by users able to reflash their device ;-)

hunter86bg commented 3 months ago

According to https://arduino-esp8266.readthedocs.io/en/3.1.2/esp8266wifi/bearssl-client-secure-class.html BearSSL::X509List can contain only 1 cert. I guess it can be done with defining extra logic.

ricki-z commented 3 months ago

Seems like this would work only with BearSSL_CertStore. So we would need to 'copy' the certs to a file at startup (in a next step only when new firmware is active or certs have changed...).

Phaze-III commented 3 months ago

Hi @ricki-z : There is no need to store two root certs for Let's Encrypt. The ISRG Root X1 in the firmware will handle both connections to servers with the 'old' (X3 cross-signed) certificate and connections to servers with the 'new' certificate (those without the X3 cross-signing). Basically the 'old' certificates on servers were signed by both DST Root CA X3 and ISRG Root X1. So firmware with just the ISRG X1 root installed will connect to any server with a Let's Encrypt certificate, both 'old' and 'new'.

Phaze-III commented 3 months ago

And just a thought: Would it help to add an 'alpha build' version, where the last merged version is available? This version would be very(!) alpha and should be used only by users able to reflash their device ;-)

That sure would help in getting more people involved in testing. For now the current github actions actually do provide (for a limited time period) 'alpha' builds triggered by a pull-request or by a push. People can download those for flashing to test a specific PR. For example for this PR builds are available on https://github.com/opendata-stuttgart/sensors-software/actions/runs/8350876571/artifacts/1340730722

ricki-z commented 3 months ago

@Phaze-III thank you for this information. It's too long that I've worked on this...