Don Grinsell wrote: 

>In my experience (ACF2) intermediate certs are also inserted using
CERTAUTH.  Essentially anything in the certificate chain for a SITECERT or
USER cert is a CERTAUTH item.

 

As I read and learn more about this, I'm convinced that the above is
incorrect. My understanding is that any intermediates will be returned as
part of the handshake process, and that you thus don't need them to be
CERTAUTH for an outbound connection and, in fact, don't want them there.

 

Why? Because if they're there, they MAY get used, and MAY expire. Consider a
chain like this:

 

S = server cert (leaf)

C, B, A = intermediates

R = root cert

 

Normal case:

Client connects to server. Server sends back S, C, B, A. S points to C, C
points to B, B points to A, A points to R, R is self-signed. Client side
verifies this chain, gets to the root, root is trusted, connection is
allowed, all is good.

 

Your case:

Client connects to server. Server sends back S, C, B, A. S points to C, C
points to B, B points to A, A points to R, R is self-signed. BUT C, B, A are
trusted. Client side MAY look at C, find it in trust store, say "OK, good",
and allow connection; all SEEMS good.

 

BUT six days/weeks/months/years from now, C expires. It's not a root, so
nobody thinks about it expiring-well, the server side does, but updating it
there is normal, so that happens. But now a client tries to connect. Server
sends back S, C, B, A. If client side looks at C and finds a
mismatch/expired cert, the connection fails, EVEN THOUGH R MAY HAVE BEEN
UPDATED as part of normal certificate maintenance. So now it's a mystery and
a fire-drill that could/should have been avoided.

 

But this only even makes any difference if *AUTH* is the key ring in use.
And since a connection can only specify up to one key ring, having an
intermediate as CERTAUTH does NOTHING for a connection that specifies *SITE*
or a user key ring, right?

 

In fact, if a z/OS-based server needs that intermediate, then since its
server leaf cert will presumably be in *SITE*, it will have a problem - it
won't be able to return that intermediate that's in *AUTH*. 

 

And if a user client connection needs the intermediate, sure, it can add a
*AUTH* cert to a personal key ring, but it can also do the same for a *SITE*
cert.

 

So my conclusion is that both server (leaf) certs and intermediates should
always be SITE, not CERTAUTH.

 

Make sense? FTW, I'm just trying to grok in fullness, not pick a fight-I
started this discussion with my own ignorant question, am learning as I go
along here!

 

.phsiii


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to