My reading of this is, the certificate sent *from the client *(not sent down from the server) does not have Client set in the EKU. I blogged <https://colinpaice.blog/2020/01/17/understanding-the-tls-concepts-for-using-certificates-to-authenticate-in-mqweb/> on TLS, and said
The Extended Key Usage (EKU) indicates the purpose, or what the certificate public key can be used for. - A client certificate needs extendedKeyUsage = clientAuth - A server certificate needs extendedKeyUsage = serverAuth. Check which certificate has the problem, Colin On Mon, 28 Feb 2022 at 14:55, Michael Babcock <[email protected]> wrote: > To all you certificate experts out there: > > We have z/OS Connect EE (ZCEE) installed and are running into an issue > with our CICS SITE certificate. We are getting the following during a > handshake from CICS to ZCEE: > > "Extended key usage does not permit use for TLS client authentication" > > The CICS certificate is a SITE cert and has the extKeyUsage extension > defined with serverAuth and the criticality flag set to false. What the > message is indicating is that we need to have > clientAuth as well as serverAuth in the extKeyusage field. I understand > that part. > > My question is "since the criticality flag is set to false" should ZCEE > honor that extension and enforce the restriction?" Or is it up to the > application to honor that particular extension and enforce > the restrictions even though the criticality flag is false? I > understand that if the flag is true the application MUST honor/enforce > the restrictions. > > Can someone enlighten me? > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
