I had created a certificate on z/OS, signed it with a CA, and it seemed that I could use in in some scenarios, but not when Java was involved. Sometimes when Java was involved, the Java program just hung!
The short answer.
After several weeks on and off, I found a reference saying an EC curve needs a CA which is also an EC. Having a EC certificate with an RSA certificate in the chain can cause problems!
I changed my CA, (and distributed it to all my clients) and it worked!
I also had to increase the length of the key…
The medium length answer
The definition which worked
RACDCERT ID( IZUSVR ) GENCERT +
SUBJECTSDN(CN('CONN2') O('IBM') OU('C2PDFLT')) +
ALTNAME(IP(10.1.1.2))-
WITHLABEL('CONN2.IZUDFLT'), +
NISTECC SIZE(521) +
SIGNWITH(CERTAUTH LABEL('DOCZOSCAEC' )) NOTAFTER(DATE(2026/01/01))
RACDCERT ALTER(LABEL('CONN2.IZUDFLT')) ID(IZUSVR) TRUST
With a CA
RACDCERT GENCERT -
CERTAUTH -
SUBJECTSDN(CN('DocZosCAECC')-
O('ECC') -
OU('CA')) -
NOTAFTER( DATE(2027-07-02 ))-
KEYUSAGE( CERTSIGN ) -
NISTECC SIZE(521) -
WITHLABEL('DOCZOSCAEC')
The long and interesting answer
My debug trail was along the path of taking a System SSL trace, formatting it, and looking at the return code – to find a blog post I had written about the same return code.
With the chrome browser you can give a url chrome://net-export, and chrome will trace the flow.
You
- start the trace
- run the workload
- stop the trace and save the file
- use “The log file can be loaded using the netlog_viewer.” Click on the link.
- drop your file onto the tools.
- pick events
- I found the last line of output to my server. It was like
- 2222 SOCKET https://10.1.1.2:7557 <https://10.1.1.2 same_site>
- Tick the box at the front of the line.
This gave me
2222: SOCKET
https://10.1.1.2:7557 <https://10.1.1.2 same_site>
Start Time: 2025-02-04 08:49:00.638
t=10890 [st= 0] +SOCKET_ALIVE [dt=128]
--> source_dependency = 2213 (SSL_CONNECT_JOB)
t=10890 [st= 0] +TCP_CONNECT [dt=8]
--> address_list = [
"10.1.1.2:7557"
]
--> aliases = []
t=10890 [st= 0] TCP_CONNECT_ATTEMPT [dt=8]
--> address = "10.1.1.2:7557"
t=10898 [st= 8] -TCP_CONNECT
--> local_address = "10.1.0.2:51284"
--> remote_address = "10.1.1.2:7557"
t=10898 [st= 8] +SSL_CONNECT [dt=119]
t=10900 [st= 10] SSL_HANDSHAKE_MESSAGE_SENT
...
t=11016 [st=126] SSL_HANDSHAKE_MESSAGE_RECEIVED
--> bytes =
... 1]T
--> type = 15
t=11016 [st=126] SSL_CERTIFICATES_RECEIVED
--> certificates =
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
t=11017 [st=127] SOCKET_BYTES_SENT
--> byte_count = 30
t=11017 [st=127] SSL_ALERT_SENT
--> bytes =
02 2F ./
t=11017 [st=127] SSL_HANDSHAKE_ERROR
--> error_lib = 16
--> error_reason = 245
--> file = "../../third_party/boringssl/src/ssl/extensions.cc"
--> line = 451
--> net_error = -107 (ERR_SSL_PROTOCOL_ERROR)
--> ssl_error = 1
This lead me to Feature: Deprecate TLS SHA-1 server signatures. This says Chrome is removing support for signature algorithms using SHA-1 for server signatures during the TLS handshake. This does not affect SHA-1 support in server certificates, which was already removed, or in client certificates, which continues to be supported.
This didn’t help me, but a link from a link from one hit mentioned the CA also needs to be an Elliptic Curve.
ColinPaice 