Re: self signed certs and api calls

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

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