Other benefits of creating my certificate authority aside from the firefox issue and centralized management of certificates?
I've been trying to read more about self-signed SSL certificates versus creating my own certificate authority to sign SSL certificates. I am still not completely clear on this.
I'll start by explaining my use case: I have customers that want to buy something from me called the HelloWorld Platform. Each HelloWorld Platform consists of 3 RaspberryPi units:
1 RaspberryPi that acts as the "hub" for the platform (can be accessed at the FQDN
hello.world.com). This RPI has a NodeJS application that serves up a REST API and Administrative Web Interface on port 443, a Mosquitto broker exposed on port 1885, and MongoDB exposed on port 4201. I use TLS/SSL to encrypt traffic on ports 443, 1885 and 4201.2 RaspberryPi that act as sensors. They gather data from the physical world and then use a combination of Python scripts and bash curl statements to ship data to any of the ports of the "hub" RPI.
A single customer may ask for more than 1 HelloWorld platform in a single order. Customers will then install HelloWorld in their own laboratories which is not connected to the Internet. Each component of HelloWorld communicate with each other over Wifi.
When it comes to the TLS/SSL, everything works fine if I create a certificate authority and create SSL certificates that are signed by the same authority. Specifically, I would make SSL certificates with these commands:
openssl genrsa -out root.key 2048
openssl req -x509 -sha256 -nodes -key root.key -subj "/C=US/ST=NY/O=HelloWorld/CN=hello.world.com" -days 3650 -out root.crt
openssl genrsa -out hello.key 2048
openssl req -new -sha256 -nodes -key hello.key -config leaf.cnf -out hello.csr
openssl x509 -req -in hello.csr -CA root.crt -CAkey root.key -CAcreateserial -out hello.crt -days 500 -sha256 -extensions v3_req -extfile leaf.cnf
The hub RPI will have all four files: root.crt, root.key, hello.crt, hello.key.
Next, all client applications will have a copy of the root.crt file. As long as every client application references the root.crt when trying to connect to port 443, 1885 or 4201 of the hub RPI, then the client applications do not experience any warnings and do not experience any errors. For example, an employee will manually import the root.crt into his FireFox browser's list of trusted Certificate Authorities, and now he can see https://hello.world.com/dashboard. Or as another example, an RPI Sensor can execute shell commands like curl --cacert=/etc/certs/ca/root.crt https://hello.world.com:443/api/server-status, the presence of the --cacert remove any errors/warnings.
Great! I have a functioning prototype!
Next, let's try to simplify the setup. I wondered what would happen if I made self-signed certificates without a certificate authority. I tried this command:
openssl req -x509 -newkey rsa:4096 -keyout hello.key -out hello.crt \
-sha256 -days 3650 -nodes \
-subj "/C=US/ST=NY/L=NewYork/O=HelloWorld/OU=Dev/CN=hello.world.com" \
-addext "subjectAltName = DNS:hello.world.com"
Then I had all client applications reference hello.crt as the certificate authority. For example, other devices were able to run this command successfully:
curl --cacert=/etc/certs/hello.crt https://hello.world.com:443/api/server-status
Also, when I import the hello.crt as a trust certificate authority in to Google Chrome and MS Edge, those browser also immediately trusted the url https://hello.world.com/dashboard. The "Lock" icon in the address bar was green, just as if it were a certificate signed by a public CA.
However, even though I imported hello.crt into FireFox, Firefox would not trust https://hello.world.com/dashboard. And even if I click through the Advance>Accept Risk on port 443, I have to repeat this for port 1885...which is not a good user experience for our customers. A user named toraritte tried to explain why FireFox has this issue in this question here:
https://stackoverflow.com/questions/59738140/why-is-firefox-not-trusting-my-self-signed-certificate
As I understand it, FireFox does not allow a certificate to be both an end-client certificate and a CA.
I haven't fully tested if my self-signed certificate will cause trust issues with the other client applications that must connect to the hub RPI. Before I do, I have a question...
My question is within my use cases, what are the most notable points of using a CA to sign a certificate vs self signing a certificate? So far, it seems like I'm only aware of two:
- CA's let me get around the issue where FireFox won't let end-client certificates also be a CA (I'm not entirely sure about this yet, just want some confirmation if I've mis-understood something)
- Useful if I want a more centralized mechanism to manage end-client certificates
Is there something else? And if I completely mis-understood anything, I welcome corrections
