How automate the fingerprints updating of Firebase (Arduino-Master-Library)

Question

I have developed a hardware-based project using esp32 board in ARDUINO, I am using firebase to upload data of sensors to the Firebase realtime database. I am using "firebase-arduino-master" library at the hardware side. The project works fines but after few days fingerprints of Firebase changes periodically which causes me to physically reopen the product enclosure to manually update the new fingerprints in the "firebase-arduino-master" library within the hardware code (Arduino). I'm curious if there's a viable solution or method to automate this fingerprint update process, eliminating the need for frequent physical access to the product.

I have attached a screenshot of firebase-arduino-master library, which clearly indicates the fingerprints. Additionally, I have included a screenshot of the website I use to periodically update the fingerprints in the library.

Screenshot1

....................................................................................................................................................................................................................................................................................

Screenshot2

Answer 1

The certificate thumbprint is used to ensure that the database URL you're connecting to really is the legitimate Firebase database that you think it is, and not a different destination (e.g. hosted by a malicious actor that is getting you to share your data and credentials).

Pinning to a single expected certificate's thumbprint is a simple way to skip implementing the more complicated process of following certificate trust chains. However, this strategy relies on the certificate itself never changing, which is unrealistic (and not recommended) for any modern cloud service.

Furthermore, the firebase-arduino library you're using is no longer actively maintained:

This repository is no longer under active development. No new features will be added and issues are not actively triaged.

The last update to the library (as of November 12, 2023) was over three years ago. Looking at the library's open issues and open pull requests, many of them are in reference to the same thumbprint issue you're having, and all of them have been ignored.

All of these are indications that the library is likely abandoned indefinitely, and you shouldn't take a dependency on it.

So, since the open-source library you're using is abandoned and relies on a certificate verification strategy that isn't reliable, I recommend you choose a different library for your project.

Searching for "Firebase" in the Arduino IDE's Library Manager, I see many options. Which one should you choose? Let's take two examples from that list, (these choices were arbitrary, I have no association or prior experience with either of them), and look at how they deal with the certificate question:

• Firebase Arduino Client Library for ESP8266 and ESP32 - This library has been around for about a year (as of November 2023), and appears to be actively maintained. It includes an example for accessing a Firebase real-time database (RTDB) using a trusted root certificate to verify the secure connection. (A root certificate is not expected to be updated frequently at all, the one in the example expires in 2036.) See more details on the README page.

  This library appears to be actively maintained and supports TLS certificate verification, both of which are positive points, and reasons you might want to consider this (or a similar) library for your project.

• (Name omitted) - This library is very new, and the GitHub repo has only been around for a few days. Because it's so new, there are no issues or pull requests yet, so it's difficult to say if it'll be actively maintained. Taking a closer look at how it deals with secure connections, I see... it doesn't. Instead, it simply turns off certificate verification entirely:

  _httpsClient.setInsecure();
  

  The fact the library is so new and the fact that it currently skips certificate validation entirely are both indications that the library is not yet mature, and you may want to hold off on taking a dependency just yet.

  Note: These are point-in-time observations which could very well be resolved in the future. To keep this answer relevant in the future (and to not unfairly ding a library that is clearly new and in-development) I've omitted the library name and links.

IMPORTANT: Many libraries and examples out there disable certificate verification. In general, is NOT a good idea, and risks introducing important security risks. I recommend you take the time to get this part of your project right early on, and avoid deferring this to later (when you will probably have forgotten about the shortcut you took).