Re: self signed certs and api calls

Scott,

thanks - I'm just totally butchering the terminology...
Based on your response...

yes, the "lpar designation", was meant to refer to the actual tcp/ip
hostname of that lpar.
And this is exactly where I thought the problem was too, but here is the
strange thing.

the CN for the lpar cert that gives us no problem, the CN is definitely not
the tcp/ip host name...
its alternative name DOES have the tcp/ip hostname
But the lpar that gives us the certificate warning, that certificates CN
does indeed have the lpars tcp/ip hostname.
The alternative name was not specified - we did specify it, but we still
got the same cert warning.

(Hey I don't think he restarted the http server after the alternative name
update - would that have made a difference, or does it not even matter
since the CN actually has the correct tcp/ip hostname specified anyways?)

so wth?

Jay

On Tue, Jun 18, 2024 at 9:53 PM Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
wrote:

Interesting that the name of the thread mentions "self-signed certs" and
yet you didn't mention them at all in the body of the email, and the
symptom doesn't seem to be related to self-signed certs. (But perhaps
there are symptoms yet to be discovered?)

Inside the certificate is a field called "cn" or "common name". For
SSL/TLS to accept the certificate, many applications the cn (or one of
the "alternative names") to match the host you are connecting to.

So if you are connecting to https://www.example.com, then the cn or an
alt needs to be "www.example.com". (Or if wildcard certs are enabled,
it could be *.example.com)

You mentioned in one of the messages that it matches your LPAR
designation. That is irrelevant, it needs to match the TCP/IP host name
you are connecting to. You also said something about it being the same
for two LPARs... that's possible if you are using wildcards or
alternative names, but not possible with an ordinary cn... but if
you're just using an ordinary cn, then you'd have to have the exact same
TCP/IP host name for both LPARs, which doesn't make a ton of sense if
you're not using a wildcard or alt name.

On 6/18/2024 12:56 PM, Jay Vaughn wrote:

So we have an off platform gui application that calls a rest api on the

IBM

i.

On one lpar, the api is consumed fine with no certificate error.

On the other lpar, the api is consumed and we see in developer tools...
net::ERR_CERT_COMMON_NAME_INVALID

However the cert on both lpars is the same cert.

what could be going on here?

tia

jay

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.