On 9/2/23 11:41 AM, Peter Sylvester wrote:
Hi,
Hi,
I do not really know what I am trying to explain, but anyway.
I've found that sharing what I understand something to be beneficial for
multiple reasons:
1) articulating it often helps clarify what I'm trying to articulate
2) it gives others more in the know an opportunity to see what I'm
thinking and hopefully correct me if I'm wrong
Ibm has made a kind of minimal security approach to access an HMCusing
https, i.e. a self signed cert.
It's not just IBM.
Using self-signed certificates is sort of the minimum bar for entering
the TLS / encrypted HTTPS ecosystem. A minimum if you will.
Hopefully there are supported and easily accessible ways to change and
use the TLS certificate provided by the end user and / or (re)generate a
new self-signed certificate.
I'm simplifying by eliding the associated key which should also be
changed from factory default.
If TLS / encrypted HTTPS is enabled by default -- something that I would
hope is the case in 2023 -- I hope that it is generated upon first power
up. As in if it doesn't exist (in the distribution image) one is
automatically generated on IPL.
Ibm also documents how one can change this,i.e. generate a key pair,, a
csr, get certified by "some" CA, then upload the key and cert. Example
uses openssl on windows :-)
:-)
Who cares
More people than you might realize. Probably for different reasons.
You need to have the cert chain as trusted in your browser, so far, pure
technical.
which "PKI" to select? The global web pki, probably not, at least not
necessary/, the HMCis in some intranet, or so.
There is a decent chance that you can't use a public CA / public PKI
because of restrictions on externally unique names. This extends into
problems with private IP addresses.
A company PKI (intranet). Yes, if it exists. The first thing iIMO is to
find out if there is a company PKI or at least policy etc.
Agreed.
Tom went for the "minimal" solution, create a minimal dedicated "PKI" :
:-)
Technically, take whatever vanilla pc, create a root, create a cert,
take the server key end cert and CA cet to an USB and the delete the
content of the PC. Lifetime long enough so either the HMC or you can
retire :-) Well, I'm provoking.
Agreed, some technical minutia not withstanding. The CA doesn't need
and shouldn't have access to the HMC's key.
On linux you could use "script" to have log.
Upload the server cert/key to the HMC, and delete them.
Ideally, the HMC will (re)generate it's own key and CSR. Take /just/
the CSR and have it signed by the CA.
install the CA cert on any PC that needs access to the HMC.
Yep.
This is what Tom has done, at least some parts.
Thus, there is only one certificate created by the CA.
Technically, there are two, the CA's (self-signed) certificate used to
sign CSRs and the HMC's cert.
All this documented but maybe not necessarily using the IETF text as
template, it is very detailed, and if you understand it at once, I'll
kill myself :-) or not.
Ya.... I've been less than thrilled with IETF working groups more times
than I can remember. The process leaves me wanting.
Anyway, validate the procedure with the company CISO.
Ya. That could be an interesting conversation. Probably educational.
What's better overall security posture?
- Using self-signed certificates and teaching employees to ignore
certificate warnings?
- Installing a bunch of certificates in the client systems?
- Installing one certificate from the Enterprise CA in the client systems?
- Exposing internal system names via Certificate Transparency when
using a public CA / public PKI?
If the company has a "company" PKI, and is able to make server certs,
well, do this.
I largely agree. But depending on how old said PKI is, it might not
generate certificates up to contemporary standards.
One usual question? Who is generating the server private key? IBM could
have made an HMC function to generate it and create a CSR to download btw.
That's a very good question.
Have fun
:-)
You too.
--
Grant. . . .
unix || die
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
