Yow indeed.
בתאריך יום ג׳, 27 ביוני 2023 ב-17:15 מאת Charles Mills :
> Yow!
>
> https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html
>
> CM
>
> On Tue, 27 Jun 2023 16:59:23 +0300, ITschak Mugzach
> wrote:
>
> >Surprise... Although the server certificate SHOULD be verified, IBM
Yow!
https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html
CM
On Tue, 27 Jun 2023 16:59:23 +0300, ITschak Mugzach wrote:
>Surprise... Although the server certificate SHOULD be verified, IBM did not
>perform this check until APAR OA63164...
Surprise... Although the server certificate SHOULD be verified, IBM did not
perform this check until APAR OA63164...
ITschak
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon *
On Tue, Jun 27, 2023 at
The check is "optional" on the application's part for z/OS System SSL:
https://www.ibm.com/docs/en/zos/2.5.0?topic=reference-gsk-validate-server
I use optional in quotes because the TLS protocol has two main purposes:
encryption (which is not under discussion here) and preventing a
In my limited (non-mainframe) experience with OpenSSL, I think it's up
to the application to decide whether to check the common name in a
validated cert with, say, a URL or IP address string. So it could be an
older application didn't bother, and a newer one does. Just guessing.
On
Ah, it's connecting by IP address. That's.ugly. Most CAs apparently won't issue
a cert for an IP. So I guess I'm not surprised it won't connect-I'm more
surprised it would before!
I hate it when people ask this, but: why are you doing it this way?
Maybe the DNS would work
On Mon, Jun 26, 2023, 5:00 PM Itschak Mugzach <
0305158ad67d-dmarc-requ...@listserv.ua.edu> wrote:
> IP. I thing changed until Friday's IPL.
>
> בתאריך יום ג׳, 27 ביוני 2023 ב-0:58 מאת Shawn Prenevost <
> shawnprenev...@gmail.com>:
>
> > Is the cert for a DNS and
IP. I thing changed until Friday's IPL.
בתאריך יום ג׳, 27 ביוני 2023 ב-0:58 מאת Shawn Prenevost <
shawnprenev...@gmail.com>:
> Is the cert for a DNS and not an IP address?
>
> On Mon, Jun 26, 2023, 4:48 PM Itschak Mugzach <
> 0305158ad67d-dmarc-requ...@listserv.ua.edu> wrote:
>
> > We use
Is the cert for a DNS and not an IP address?
On Mon, Jun 26, 2023, 4:48 PM Itschak Mugzach <
0305158ad67d-dmarc-requ...@listserv.ua.edu> wrote:
> We use htwtconn and the message is returned during handshake. It is also
> written to trace if running in verbose mode.
>
>
> בתאריך יום ג׳, 27
We use htwtconn and the message is returned during handshake. It is also
written to trace if running in verbose mode.
בתאריך יום ג׳, 27 ביוני 2023 ב-0:38 מאת Phil Smith III :
> Itschak Mugzach wrote:
> >The error msg says "certificate is not valid for IP address". It worked
> >until Friday
Itschak Mugzach wrote:
>The error msg says "certificate is not valid for IP address". It worked
>until Friday before fixes applied.
That's an error from gsk? Or what? What's the return code? I don't see that
error in the doc.
Phill,
The error msg says "certificate is not valid for IP address". It worked
until Friday before fixes applied.
*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **| *
*|* *Email**:
Itschak Mugzach wrote:
>Since the last ptfs applied last weekend, The server certificate CN is now
>verified by Z/oS (the client). I know it is a normal behaviour of TLS, but
>it has never been performed by z/os before.
Eh? What you're saying makes no sense. Of course the server cert is
Since the last ptfs applied last weekend, The server certificate CN is now
verified by Z/oS (the client). I know it is a normal behaviour of TLS, but
it has never been performed by z/os before.
Does anyone know which PTF made the change?
*| **Itschak Mugzach | Director | SecuriTeam Software
14 matches
Mail list logo
