On 8/28/23 6:23 PM, Tom Brennan wrote:
Does that work? In the past when I created a self-signed cert (for
Apache on Linux), adding it to the trusted certs didn't work (at least
in Chrome). I still got the evil warnings.
I've been running into this with many self-signed certs at work.
One of the primary problems is the use of a mixture of unqualified host
names, qualified host names, and IP addresses. Often, self-signed
certificates that equipment generate only use one of the forms of
identification. They tend to not play well with a mixture of them.
This is where the Subject Alternate Name field comes into play in the
certificate.
I ended up creating my own CA, used that to sign the web cert, and
then copied the CA to the trusted certs in Chrome. Then I gave out
the CA to the folks I work with who needed to access the web page,
and they did the same. That was easy and cheap for a small group of
known users.
This is the route that I'm doing background research about the
environment (I've been there a few months and don't know all the
history) before standing up a CA explicitly for this reason.
I want to do the following things:
1) Create an Enterprise Certificate Authority. (More comments about
this in my forthcoming reply to Charles about trust.)
2) Create Certificate Signing Requests which use the following forms of
identification:
- IP address
- Fully Qualified Domain Name (full host name)
- Short host name (no dots)
3) Sign said CSRs to generate certificates
4) Install said certificates in equipment.
Why am I planing on going this route? I have (at least) 33 devices
currently using self-signed certificates with a single name exclusive or
IP address that we interact with which on the near weekly basis. We are
constantly dealing with should I use the FQDN, UQDN, or IP for this
particular device type issues. We have multiple people on our team. We
collectively use multiple jump servers. This culminates in a lot of
maintenance for each self-signed certificate to be able to consume it.
Even with that maintenance, the FQDN vs UQDN vs IP tends to cause problems.
Ultimately we end up in what I think is a poor -- at best -- security
posture that encourages, if not requires, that users push past security
warnings from web browsers about untrusted certificates.
I think we will end up in a much better security posture if we (I) take
the time to stand up an Enterprise Certificate Authority and install
it's root (or chained) public certificate on client systems.
This should mean that we have much less maintenance to in that we only
need to install the root public certificate on client systems and they
will inherently trust what said ECA signs. No need to install many
self-signed certificates. 1 vs 33 type thing.
I also think the FQDN vs UQDN vs IP will help things considerably.
--
Grant. . . .
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
