Webinar on Different Approach to Certificate Problem Resolution

[Charles Mills]

Something of a plug; hit delete if you wish. X-Posted RACF-L and IBM-MAIN.

I have been reading and sometimes responding to various people’s “help me with 
my certificate problem” posts here for years. I have been kicking around 
various approaches to certificate problem resolution with my friend Paul 
Robichaux at NewEra. Most add-on certificate tools are what I would call 
“static” – they essentially front-end the various RACF commands and/or database 
and display certificate information in various more user-friendly formats, and 
front-end the RACF commands to make administration easier.

We got the idea of a “dynamic” approach: a tool that given a keyring and the 
address of a server would actually attempt a connection and tell you everything 
it learned doing that connection: all about the protocol and certificates if 
the connection succeeded; every detail of the failure if it failed. Among other 
features, it fully automates the production and formatting of the GSK trace. 
Just about every possible detail of the configuration is specifiable in a Web 
interface, and every detail of the session or attempted session is reported.

Anyway, I am going to do a Webinar and demo the tool this coming Tuesday. I 
will demo the resolution of two real-world certificate problems. Free. Minimal 
registration. No salesman will call you – I promise. Truly a demo, not a sales 
pitch. I would be honored if any of our associates here could attend.
https://events.r20.constantcontact.com/register/eventReg?oeidk=a07ejrm7u2yeb142c9b===
 

Charles 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Certificate problem

[Phil Smith III]

Colin Paice replied, basically confirming what I'd found. In retrospect it
all feels silly but ain't that usually the case? Thanks again!


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Certificate problem

[Colin Paice]

Going back to the first message...

I'm getting this trying to use a self-signed certificate. I put it into
gskkyman and when I try to connect (outbound from z/OS) I get

Certificate validation error

from GSK_SECURE_SOCKET_INIT. Running a gsktrace shows:
09/07/2022-17:30:14 Thd-1 ERROR check_cert_extensions_3280_and_later():

*Basic Constraints extension must be critical for CA Certificate*

For my CA with OPENSSL  I have openssl-ca.cnf file with


[ req_extensions ]

subjectKeyIdentifier   = hash
authorityKeyIdentifier = keyid:always ! issuer:alwaysz
*basicConstraints   = critical,CA:TRUE, pathlen:0*
keyUsage   = keyCertSign, digitalSignature,cRLSign

It looks like you may not have this,

On Linux I use

openssl x509 -in cs256.pem -text -noout|less

and it gives me

X509v3 extensions:
X509v3 Subject Key Identifier:
58:30:AF:55:C7:
X509v3 Authority Key Identifier:
keyid:58:30:...






*X509v3 Basic Constraints: criticalCA:TRUE, pathlen:0
  X509v3 Key Usage: Digital Signature,
Certificate Sign, CRL Sign*


Display your certificate, and check it.

Colin

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Certificate problem

[Phil Smith III]

Charles Mills wrote:
>Where did this self-signed certificate come from? What tool generated it?

 

It was internally generated. That's all I know. It's a test system.

 

>Case should not be a problem in a self-signed certificate. Technically I
guess it is possible but you would almost have to do it on purpose.

>I think the trace is pretty clear. I don't fully understand the big
picture, but I think the trace is pretty clear as to what it is objecting
to. Perhaps this is a tightened requirement in 1.3?

 

Well, I think you're right-it's perfectly clear *once you understand the
terms it uses*. This is sort of a classic software problem, eh? The
"obvious" message that means nothing to you when you receive it!

 

It's saying:

*   X509v3 Basic Constraints is/are set in this certificate, per RFC
3280*
*   But the Basic Constraints is NOT defined as Critical
*   This is a requirement per that RFC (odd IMHO: if it's only
meaningful if you set that, then why bother?)
*   And yes, I think this is new as of TLS 1.3

 

We regenerated a new cert with Critical and it works. Hopefully this thread
will help the next person who gets
ERROR check_cert_extensions_3280_and_later(): Basic Constraints extension
must be critical for CA Certificate

!

 

Thanks to all for your help. This wound up sorta being a rubber duck
debugging exercise, but ya got me there!

 

...phsiii

 

*Not the coder's fault that "3280" makes me think of a terminal


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Certificate problem

[Charles Mills]

Where did this self-signed certificate come from? What tool generated it?

Case should not be a problem in a self-signed certificate. Technically I guess 
it is possible but you would almost have to do it on purpose.

I think the trace is pretty clear. I don't fully understand the big picture, 
but I think the trace is pretty clear as to what it is objecting to. Perhaps 
this is a tightened requirement in 1.3?

CM

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Certificate problem

[Carmen Vitullo]

Phil,

Yes, it's TLSv1.3:

sorry I missed this.

You mean the label in the gskkyman entry?

I was thinking the entry, Cert that was added to RACF, that's where I had 
similar issues.
sorry I could not be more help
Carmen

On 9/8/2022 10:31 AM, Phil Smith III wrote:

Yes, it's TLSv1.3:


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Certificate problem

[Phil Smith III]

Carmen Vitullo asked:

>Phil, was this output from an SSL trace?

 

Yes.

 

>IIRC there's usually more data related to a cert error,  it's been 7, or

>8 years since I ran the trace but usually the trace data

>shows the TLS version also, it's a stretch but are you running TSL 1.1

>or higher?

 

Yes, it's TLSv1.3:
09/07/2022-17:30:14 Thd-1 INFO read_v3_server_hello(): Using TLSV1.3
protocol

 

>I'd agree with Attila also, I've had my security team load a cert for me

>that required mixed case, and they defined the LABEL with all caps

 

You mean the label in the gskkyman entry? I did that, no change. I also
tried it in RACF, via the *AUTH*/* virtual key ring; also same error:
09/08/2022-09:53:50 Thd-1 ERROR check_cert_extensions_3280_and_later():
Basic Constraints extension must be critical for CA Certificate

09/08/2022-09:53:50 Thd-1 EXIT check_cert_extensions_3280_and_later(): <---
Exit status 0x03353071 (53817457)

09/08/2022-09:53:50 Thd-1 ERROR validate_certificate_basics(): Unable to
verify certificate extensions: Error 0x03353071

09/08/2022-09:53:50 Thd-1 ERROR get_issuer_certificate(): Unable to validate
CA certificate: Error 0x03353071

09/08/2022-09:53:50 Thd-1 ERROR validate_certificate(): Unable to get issuer
certificate: Error 0x0335302f

09/08/2022-09:53:50 Thd-1 ERROR validate_certificate_mode(): Unable to
validate certificate: Error 0x0335302f

09/08/2022-09:53:50 Thd-1 ERROR cms_validate_certificate_mode_int(): Unable
to validate certificate: Error 0x0335302f

09/08/2022-09:53:50 Thd-1 EXIT cms_validate_certificate_mode_int(): <---
Exit status 0x0335302f (53817391)

09/08/2022-09:53:50 Thd-1 ERROR read_tls13_certificate(): Unable to validate
peer certificate: Error 0x0335302f

09/08/2022-09:53:50 Thd-1 ERROR send_tls13_alert(): Sent TLS 1.3 alert 42 to
140.236.144.55[443]

 

I'm 100% not trying to be one of those "No, your helpful advice can't be
right" people here! I just don't know how to apply it.

 

Thanks,
...phsiii 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Certificate problem

[Carmen Vitullo]

Phil, was this output from an SSL trace?

IIRC there's usually more data related to a cert error,  it's been 7, or 
8 years since I ran the trace but usually the trace data


shows the TLS version also, it's a stretch but are you running TSL 1.1 
or higher?


I'd agree with Attila also, I've had my security team load a cert for me 
that required mixed case, and they defined the LABEL with all caps


Carmen


On 9/7/2022 5:51 PM, Phil Smith III wrote:

I'm getting this trying to use a self-signed certificate. I put it into
gskkyman and when I try to connect (outbound from z/OS) I get

Certificate validation error

from GSK_SECURE_SOCKET_INIT. Running a gsktrace shows:
09/07/2022-17:30:14 Thd-1 ERROR check_cert_extensions_3280_and_later():
Basic Constraints extension must be critical for CA Certificate

09/07/2022-17:30:14 Thd-1 EXIT check_cert_extensions_3280_and_later(): <---
Exit status 0x03353071 (53817457)

09/07/2022-17:30:14 Thd-1 ERROR validate_certificate_basics(): Unable to
verify certificate extensions: Error 0x03353071

09/07/2022-17:30:14 Thd-1 ERROR get_issuer_certificate(): Unable to validate
CA certificate: Error 0x03353071

  


I find nothing for that error in the doc (either the text or the error
number). https://colinpaice.blog/2021/11/03/using-z-os-ldap-with-tls-1-3/
discusses the error, but I don't know how to check it! Other clients work
but that doesn't prove much-we know z/OS is more stringent about following
the rules than many.

  


Ideas?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Certificate problem

[Phil Smith III]

Attila Fogarasi kindly replied suggesting a case problem, which I'm
perfectly willing to believe but don't have any idea how to verify. Nothing
LOOKS off.

 

Meanwhile, some more digging suggests that it may be that the error message
is actually correct and clear, FSVO clear!

 

If I run
openssl x509 -in voltage-ca.crt -text -noout

against that cert I see:

X509v3 extensions:

X509v3 Basic Constraints:

CA:TRUE

But other reading suggests this should be:
X509v3 extensions:

X509v3 Basic Constraints: critical

CA:TRUE

and that this is therefore an omission in creating the cert. This is an RFC
3280 
requirement, but I strongly suspect that it gets ignored by many stacks. I
find other discussions that support this conclusion indirectly. It certainly
fits with the typical IBM strict interpretation of RFCs, which is hard to
argue with. I have a handful of random certs from past tinkering, and
running that command against them finds most do NOT have the Basic
Constraints set and/or have critical.

 

I'm asking if we can regenerate the cert either without the Basic
Constraints or with critical.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Certificate problem

[Attila Fogarasi]

Gskkyman is case sensitive for issuer name etc. while most other
implementations are case INsensitive.  For the good reason that the world
is filled with wrong-case names.  The RFC standard allows both, and lots of
certificates that work otherwise will fail for Gskkyman until the case is
fixed to be an exact match.  Guessing you have run into this.

On Thu, Sep 8, 2022 at 8:52 AM Phil Smith III  wrote:

> I'm getting this trying to use a self-signed certificate. I put it into
> gskkyman and when I try to connect (outbound from z/OS) I get
>
> Certificate validation error
>
> from GSK_SECURE_SOCKET_INIT. Running a gsktrace shows:
> 09/07/2022-17:30:14 Thd-1 ERROR check_cert_extensions_3280_and_later():
> Basic Constraints extension must be critical for CA Certificate
>
> 09/07/2022-17:30:14 Thd-1 EXIT check_cert_extensions_3280_and_later(): <---
> Exit status 0x03353071 (53817457)
>
> 09/07/2022-17:30:14 Thd-1 ERROR validate_certificate_basics(): Unable to
> verify certificate extensions: Error 0x03353071
>
> 09/07/2022-17:30:14 Thd-1 ERROR get_issuer_certificate(): Unable to
> validate
> CA certificate: Error 0x03353071
>
>
>
> I find nothing for that error in the doc (either the text or the error
> number). https://colinpaice.blog/2021/11/03/using-z-os-ldap-with-tls-1-3/
> discusses the error, but I don't know how to check it! Other clients work
> but that doesn't prove much-we know z/OS is more stringent about following
> the rules than many.
>
>
>
> Ideas?
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Certificate problem

[Phil Smith III]

I'm getting this trying to use a self-signed certificate. I put it into
gskkyman and when I try to connect (outbound from z/OS) I get

Certificate validation error 

from GSK_SECURE_SOCKET_INIT. Running a gsktrace shows:
09/07/2022-17:30:14 Thd-1 ERROR check_cert_extensions_3280_and_later():
Basic Constraints extension must be critical for CA Certificate

09/07/2022-17:30:14 Thd-1 EXIT check_cert_extensions_3280_and_later(): <---
Exit status 0x03353071 (53817457)

09/07/2022-17:30:14 Thd-1 ERROR validate_certificate_basics(): Unable to
verify certificate extensions: Error 0x03353071

09/07/2022-17:30:14 Thd-1 ERROR get_issuer_certificate(): Unable to validate
CA certificate: Error 0x03353071

 

I find nothing for that error in the doc (either the text or the error
number). https://colinpaice.blog/2021/11/03/using-z-os-ldap-with-tls-1-3/
discusses the error, but I don't know how to check it! Other clients work
but that doesn't prove much-we know z/OS is more stringent about following
the rules than many.

 

Ideas?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN