Re: CERTAUTH vs SITE vs user certificate

[Wai Choi]

For the validation process, I would agree that putting the whole cert chain in 
the server side's keyring is a better approach so that the client side only 
needs to have the root certificate in its keyring. It is simpler and it can 
avoid the scenario if the client has an expired intermediate cert. 

But whether the certificate is connected with USAGE CERTAUTH, SITE or PERSONAL 
will not affect the validation process. The server's handshake application like 
System SSL goes through all the certificates from the server side's keyring to 
find a chain regardless of the certificates' USAGE. The client validation 
application locates the issuer from the client's keyring first, again not 
looking at the certificates' USAGE, before using those supplied from incoming 
chain from the server.

Retrieving certificate and key is performed by calling the RACF callable 
service R_DATALIB.  The USAGE is more relevant for the server to set up the 
keyring as access to private key is based on the USAGE the certificate is 
connected. The RACF Callable Service book describes the condition in the 
R_DATALIB section.

Wai Choi - RACF/PKI Design and Development

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

Re: CERTAUTH vs SITE vs user certificate

[Phil Smith III]

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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CERTAUTH vs SITE vs user certificate

[Ward, Mike S]

Not true, we have tried it. You need to use the RDATALIB with a site 
certificate. Try it.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rob Schramm
Sent: Wednesday, July 27, 2016 11:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CERTAUTH vs SITE vs user certificate

Actually with RDATALIB, you should be able to share a cert with multiple 
regions as well without using SITE.

Rob Schramm

On Wed, Jul 27, 2016, 12:01 PM Ward, Mike S <mw...@ssfcu.org> wrote:

> I know that a site certificate can b e shared by many CICS regions 
> with different controlling userids. A user certificate requires that 
> each region that is sharing the cert have the same userid. Hope that helps.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Phil Smith III
> Sent: Thursday, July 14, 2016 1:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: CERTAUTH vs SITE vs user certificate
>
> I've never understood how you choose between adding a certificate as 
> CERTAUTH, SITE, or user. And not having a lot of luck Googling for it. 
> Can anyone describe the choice, or point me at something coherent?
>
>
>
> Thanks.
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ==
> This email, and any files transmitted with it, is confidential and 
> intended solely for the use of the individual or entity to which it is 
> addressed. If you have received this email in error, please notify the 
> system manager. This message contains confidential information and is 
> intended only for the individual named. If you are not the named 
> addressee, you should not disseminate, distribute or copy this e-mail. 
> Please notify the sender immediately by e-mail if you have received 
> this message by mistake and delete this e-mail from your system. If 
> you are not the intended recipient, you are notified that disclosing, 
> copying, distributing or taking any action in reliance on the contents 
> of this information is strictly prohibited.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: CERTAUTH vs SITE vs user certificate

[Rob Schramm]

Actually with RDATALIB, you should be able to share a cert with multiple
regions as well without using SITE.

Rob Schramm

On Wed, Jul 27, 2016, 12:01 PM Ward, Mike S  wrote:

> I know that a site certificate can b e shared by many CICS regions with
> different controlling userids. A user certificate requires that each region
> that is sharing the cert have the same userid. Hope that helps.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Phil Smith III
> Sent: Thursday, July 14, 2016 1:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: CERTAUTH vs SITE vs user certificate
>
> I've never understood how you choose between adding a certificate as
> CERTAUTH, SITE, or user. And not having a lot of luck Googling for it. Can
> anyone describe the choice, or point me at something coherent?
>
>
>
> Thanks.
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ==
> This email, and any files transmitted with it, is confidential and
> intended solely for the use of the individual or entity to which it is
> addressed. If you have received this email in error, please notify the
> system manager. This message contains confidential information and is
> intended only for the individual named. If you are not the named addressee,
> you should not disseminate, distribute or copy this e-mail. Please notify
> the sender immediately by e-mail if you have received this message by
> mistake and delete this e-mail from your system. If you are not the
> intended recipient, you are notified that disclosing, copying, distributing
> or taking any action in reliance on the contents of this information is
> strictly prohibited.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 

Rob Schramm

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

Re: CERTAUTH vs SITE vs user certificate

[Ward, Mike S]

I know that a site certificate can b e shared by many CICS regions with 
different controlling userids. A user certificate requires that each region 
that is sharing the cert have the same userid. Hope that helps.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith III
Sent: Thursday, July 14, 2016 1:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CERTAUTH vs SITE vs user certificate

I've never understood how you choose between adding a certificate as CERTAUTH, 
SITE, or user. And not having a lot of luck Googling for it. Can anyone 
describe the choice, or point me at something coherent?



Thanks.




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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: CERTAUTH vs SITE vs user certificate

[Lizette Koehler]

If you have not done so, and you would like to join the RACF List, use this url
RACFhttp://www.listserv.uga.edu/archives/racf-l.html

Lizette

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

Re: CERTAUTH vs SITE vs user certificate

[Wai Choi]

In RACF:
1. Only Certificate Authority(CA) certificate SHOULD issue certificates for 
others - for a user, for a server, for another CA. 

2. For a self-signed CA certificate, we call it a root certificate. 

3. A CA certificate signed by another CA is called an intermediate CA. 

4. CA certificates including root or intermediate are owned by a special ID 
CERTAUTH.

5. User certificates are owned by an ordinary RACF user ID.

6. Server certificates can be owned by an ordinary RACF user ID or by a special 
ID SITE.

7. In the original support when the FACILITY class is used to control the 
access of the private key of the certificate in the keyring, we need the 
certificate owned by SITE in order to share the private key by giving the ID of 
the application CONTROL access to IRR.DIGTCERT.GENCERT. That's the reason of 
having SITE as the owner. But in V1R10 when RDATALIB class was introduced, this 
restriction was lifted, the owner does not need to be SITE. 

8. Having SITE as the owner of a server certificate is logical. Having an 
ordinary ID as the owner of a server certificate has the benefit of enabling 
the same ID to own the key ring. Key ring can not be owned by the SITE ID.

9. In validation process, SITE certificate can be used by a certificate 
validation application that honors it without checking the whole chain of CAs. 
But I don't know if any common certificate validation application running on 
z/OS honors it yet.

10. Go back to #1, I said SHOULD. But RACF supports SITE to issue certificates 
too. I don't find a scenario that needs this support though.

Wai Choi - RACF/PKI Design and Development

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

Re: CERTAUTH vs SITE vs user certificate

[Neubert, Kevin]

Maybe take a look at the Digital Certificate Goody Bags on z/OS presentations 
or something like Security Server RACF Security Administrator's Guide 
(SA23-2289), Using RACF to manage digital certificates:

RACF has three categories for managing digital certificates:

User certificate

A certificate that is associated with a RACF user ID and is used to 
authenticate the user's identity. The RACF user ID can represent a traditional 
user or be assigned to a server or started procedure.

Certificate-authority certificate

A certificate that is associated with a certificate authority and is used to 
verify signatures in other certificates.

Site certificate

A certificate that is associated with an off-platform server or other network 
entity, such as a peer VPN server. This category of certificate can also be 
used to share a single certificate and its private key among multiple RACF user 
IDs. When used for sharing, a certificate might be referred to as a placeholder 
certificate.

Regards,

Kevin

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Phil Smith III
Sent: Monday, July 18, 2016 2:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CERTAUTH vs SITE vs user certificate

>So:

>CERTAUTH - root certs

>SITE - server leaf certs (and intermediates?)

>User - certs used to authenticate users to servers

 

>Anyone want to agree/argue/validate/disprove? 

 

Nobody else has any thoughts on this? Surely we aren't the only ones dealing 
with certificates (well, besides Dave Gibney)?


--
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: CERTAUTH vs SITE vs user certificate

[Grinsell, Don]

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.

--
 
Donald Grinsell, Systems Programmer
Enterprise Technology Services Bureau
SITSD/Montana Department of Administration
406.444.2983 (D)

"Think you can, think you can't, either way you'll be right."
~ Henry Ford

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Phil Smith III
> Sent: Monday, July 18, 2016 3:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CERTAUTH vs SITE vs user certificate
> 
> >So:
> 
> >CERTAUTH - root certs
> 
> >SITE - server leaf certs (and intermediates?)
> 
> >User - certs used to authenticate users to servers
> 
> 
> 
> >Anyone want to agree/argue/validate/disprove?
> 
> 
> 
> Nobody else has any thoughts on this? Surely we aren't the only ones dealing
> with certificates (well, besides Dave Gibney)?
> 
> 
> --
> 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: CERTAUTH vs SITE vs user certificate

[Gibney, Dave]

Cert discussion is more frequent over on RACF-L :)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Phil Smith III
> Sent: Monday, July 18, 2016 2:45 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CERTAUTH vs SITE vs user certificate
> 
> >So:
> 
> >CERTAUTH - root certs
> 
> >SITE - server leaf certs (and intermediates?)
> 
> >User - certs used to authenticate users to servers
> 
> 
> 
> >Anyone want to agree/argue/validate/disprove?
> 
> 
> 
> Nobody else has any thoughts on this? Surely we aren't the only ones dealing
> with certificates (well, besides Dave Gibney)?
> 
> 
> --
> 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: CERTAUTH vs SITE vs user certificate

[Phil Smith III]

>So:

>CERTAUTH - root certs

>SITE - server leaf certs (and intermediates?)

>User - certs used to authenticate users to servers

 

>Anyone want to agree/argue/validate/disprove? 

 

Nobody else has any thoughts on this? Surely we aren't the only ones dealing
with certificates (well, besides Dave Gibney)?


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

Re: CERTAUTH vs SITE vs user certificate

[Phil Smith III]

Dave Gibney wrote:

>I could be wrong and I did use CERTAUTH inappropriately (should have been
SITE) in the past.

>I use:

>CERTAUTH to sign other certs.

>SITE for SERVERS

>User for users :)

 

I like this, Dave-it's certainly coherent and *sounds* logical!

 

So:

CERTAUTH - root certs

SITE - server leaf certs (and intermediates?)

User -certs used to authenticate users to servers

 

Anyone want to agree/argue/validate/disprove? Wai Choi?


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

Re: CERTAUTH vs SITE vs user certificate

[Gibney, Dave]

I could be wrong and I did use CERTAUTH inappropriately (should have been SITE) 
in the past.
I use:
CERTAUTH to sign other certs.
SITE for SERVERS
User for users :)

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Phil Smith III
> Sent: Thursday, July 14, 2016 11:02 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: CERTAUTH vs SITE vs user certificate
> 
> I've never understood how you choose between adding a certificate as
> CERTAUTH, SITE, or user. And not having a lot of luck Googling for it. Can
> anyone describe the choice, or point me at something coherent?
> 
> 
> 
> Thanks.
> 
> 
> 
> 
> --
> 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