Unfortunately, I don’t have our preferred process for generating RSA keys and certificates ready for publication, but I’ll keep working on it. I should have something in the next few days.
Meanwhile, here are two observations:
Self-signed certificates
The process at the start of this topic generates a self-signed certificate. A self-signed certificate provides privacy in the HTTPS connection, but it doesn’t provide authentication, so a user cannot be certain that he/she is connected to the genuine ODU. It might be possible to restore the authentication function by adding the certificate to the browser’s trusted certificate store but that would be a cumbersome solution in a network with several ODUs and several management platforms.
Self-signed certificate normally trigger browser warnings. It’s never a good idea to ignore browser warnings, because they’re trying to tell us something important.
Instead, we prefer to create a local Certificate Authority and then use this CA to sign the individual certificates. In this case, we only need to add one Root CA certificate to the browser’s trusted certificate store. Of course, there are a few more Open SSL commands needed.
Subject Alternative Name
Until recently, browsers were able to process the subject of the certificate (in this case the IP address or DNS name) from the Common Name field, even though this has not been a part of the Internet standards for a long time.
Now browsers have tightened up here, and will only read the subject from the Subject Alternative Name (SAN) field. Browsers reject the certificates that we have previously been using.
It’s possible to create an X.509 with IP address in the SAN field using Open SSL. In fact, it got a great deal easier to do this in Open SSL 1.1.1. This is chiefly where I need to do a bit more work.