[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: SSL certificate problems
From:       Wai Choi <wchoi () US ! IBM ! COM>
Date:       2011-11-30 1:45:07
Message-ID: OF97528761.D0447CB3-ON85257958.000243C8-85257958.00099FBB () us ! ibm ! com
[Download RAW message or body]

Mike,

As long as you add back the certificate from the CA under the same id as
the certificate you GENREQed from, the original certificate will be
"overlay". The new certificate will be added with the label specified or
with the original label if label is not specified. It is not required to
specify the same label. If you add back the certificate under a different
id, the original cert will not be "overlay". You will end up with 2 certs
- the original one with private key associated with it under one id, the
new one without private key associated with it under another id. The
duplication msg won't be issued.

The common mistakes are:
1) The GENREQed certificate was deleted because people think that once the
request was generated from the certificate, the certificate has no use.
2) The returned certificate was added under a different id. Since it
doesn't have an associated private key, it can't be used as the server
cert.

Regards,
Wai

Wai Choi - RACF/PKI Design and Development



From:   Michael Kearney/Bethesda/IBM@IBMUS
To:     RACF-L@listserv.uga.edu
Date:   11/29/2011 02:40 PM
Subject:        Re: SSL certificate problems
Sent by:        RACF Discussion List <RACF-L@listserv.uga.edu>



Hi Breck,

Assuming you created the new certs with a RACDCERT GENCERT, and then used
RACDCERT GENREQ to create the cert requests, and then sent the cert
requests off to the CA for signing, then when you get the signed certs
back from the CA, you have to RACDCERT ADD them back to RACF. This is the
tricky part where things can go wrong.

The signed cert that comes back from the CA has to "overlay" the cert that
you created with the RACDCERT GENCERT command. The easiest way to make
sure that happens is to not specify a LABEL name on the RACDCERT ADD
command. RACF will figure it out and overlay the original cert with the
signed cert from the CA.

If you do specify a LABEL on the RACDCERT ADD command it must be the same
LABEL that you specified when you created the cert with the RACDCDERT
GENCERT command. If you specify a different LABEL name, RACF will tell you
it's a duplicate certificate. This leads many folks to think that the
solution is to DELETE the original certificate from RACF, but that is a
mistake. If you do that the private keys will be gone and you'll get
messages about no private keys found. If you've deleted the original cert,
you'll need to start over again from the beginning. Does that sound like
what might have happened?

Regards,
Mike







"Campbell, Breck" <breck.campbell@STATE.VT.US>
Sent by: RACF Discussion List <RACF-L@listserv.uga.edu>
11/29/2011 01:50 PM
Please respond to
RACF Discussion List <RACF-L@listserv.uga.edu>


To
RACF-L@listserv.uga.edu
cc

Subject
Re: SSL certificate problems






Ahhh,

The Certificates I installed don't have private keys.  Is that something I
have to do after they come back from the CA?

Breck

-----Original Message-----
From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of
Clough III, Harold Mr CIV DISA CD552
Sent: Tuesday, November 29, 2011 8:41 AM
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: SSL certificate problems

Breck,

There are others on this listserv such as Mike Kearney that have helpful
insight into issues such as this.

I think the 1AC refers to TN3270.

Based on this message, I'd do a RACDCERT ID(TN3270) LIST.  Does it show
"Private Key: YES"?

You may have already checked this but:

In the TNPROF member of your TCPPARMS dataset, is the KEYRING statement
pointing to the keyring you expect?

Check the keyring in RACF: RACDCERT ID(TN3270) LISTRING(*).  Is there a
DEFAULT YES certificate and is it what you expect it to be?

Harold

-----Original Message-----
From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of
Campbell, Breck
Sent: Monday, November 28, 2011 15:46
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: SSL certificate problems

Harold,

Excuse my muddle-headedness, but, does the 1AC error message refer to
the z/OS system as the "server"?  Or is the machine running the TN3270
emulator the "server"?

If the z/OS system the server, does this indicate that RACF can't find
the intermediate or root certificate?

Breck

-----Original Message-----
From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of
Clough III, Harold Mr CIV DISA CD552
Sent: Tuesday, November 22, 2011 6:36 AM
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: SSL certificate problems

Breck,

Check out the z/OS 1.11 Comm Server: IP Messages Volume 4

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1D191/SPTW
Q1185

The 1AC indicates:

"No key was found for the server certificate."

Harold

-----Original Message-----
From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of
Campbell, Breck
Sent: Monday, November 21, 2011 16:31
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: SSL certificate problems

Bob suggested that I add the error message from the system log, so here
it is:

0281  EZZ6034I TELNET CONN 00002101 LU **N/A**  ACCEPTED     992 725
0281    IP..PORT: 10.240.33.5..4550
0281  EZZ6035I TELNET TN3270   DEBUG CONN   DETAIL 726
0281    IP..PORT: 10.240.33.5..4550
0281    CONN: 00002101  LU:          MOD: EZBTTSMT
0281    RCODE: 6002-00  SSL/TLS handshake failed.
0281    PARM1: 000001AC PARM2: 00000000 PARM3: GSK_SECURE_SOCKET_INIT
0281  EZZ6034I TELNET CONN 00002101 LU **N/A**  CONN DROP  ERR 6002 727
0281    IP..PORT: 10.240.33.5..4550
EZBTTSMT
0290  -                                                --TIMINGS
(MINS.)--
              ----PAGING COUNTS---
0290  -JOBNAME  STEPNAME PROCSTEP    RC   EXCP   CONN    TCB    SRB
CLOCK
      SERV  PG  PAGE  SWAP   VIO SWAPS
0290  -PASXRJED STEP010              00    707    222 551177    .00
.0
      505   0     0     0     0     0
0281  EZZ6035I TELNET TN3270   DEBUG CONN   DETAIL 731
0281    IP..PORT: 159.105.236.160..1957
0281    CONN: 000020B7  LU: A1IP81B7 MOD: EZBTVXRC
0281    RCODE: 2035-01  UNBIND or CLEAR ended a RECEIVE request.
0281    PARM1: 00000000 PARM2: 00000000 PARM3: 000C0B00
0281  EZZ6034I TELNET CONN 000020B7 LU A1IP81B7 SESS DROP  UNBIND 732
0281    IP..PORT: 159.105.236.160..1957
0281  EZZ6034I TELNET CONN 000020B7 LU A1IP81B7 CONN DROP  UNBIND 733
0281    IP..PORT: 159.105.236.160..1957
0290  -                                                --TIMINGS
(MINS.)--

Breck


-----Original Message-----
From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of
Campbell, Breck
Sent: Monday, November 21, 2011 2:30 PM
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: SSL certificate problems

I tried that, and took the new certs out of the keyrings, but it didn't
seem to work.

As to why the new certs failed; I had the new certs with the
intermediate cert in the keyrings but forgot to install the vendor's
root (I think).

Breck

-----Original Message-----
From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of
Peurifoy, Richard L
Sent: Monday, November 21, 2011 11:09 AM
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: SSL certificate problems

----- "Breck Campbell" <breck.campbell@STATE.VT.US> wrote:

> Over the weekend I discovered that the new certificates I installed
> were not working so I removed them from the affected key-rings, but
> that did not fix the problem.  Do I have to also remove the old
> certificates and reinstall them?  Why did the old certificates, that
> are not expired, not work?
>
> I make the new certificates the defaults.  Did that cause my problem
> with the old certificates not working?

You may just need to make the old certificates the default again.
What is the problem with the new certs?

--
Richard
[prev in list] [next in list] [prev in thread] [next in thread]