[Go-essp-tech] Call for CA and OpenID Trust root Certificates

Rachana Ananthakrishnan ranantha at mcs.anl.gov
Fri Aug 6 13:24:48 MDT 2010 

Hi Eric,

Comments inline.

On Aug 6, 2010, at 2:08 PM, Eric Nienhouse wrote:

> Hi Rachana, All,
>
> I will do a deeper and more diligent review as to impact of CA DN  
> changes and report back any changes to the below.

That would be useful - thanks.
>
> However in general this includes:
>
> 1) All system trust stores (Java, grid-security)
> 2) All system DN based white lists (which are in development)

The above should be using the central collection that is hosted at the  
end of this exercise. As in, once we have a collection and agreement  
of the CAs and whitelist, all deployers must update their trust roots  
to use that.

> 3) All system user DNs stored at each gateway database as Luca noted.

This would be significant work.

> 4) Short lived user certs as Rachana noted.

This is probably not going to be a specific update, because we have  
short term certificate. As I noted, if the user runs myproxy-logon,  
which they have to 12 hours after the previous one, the new CA issued  
certificate will be provided.

> 5) MyProxy server configuration at each Gateway (specialized ESG  
> plugin scripts.)

> 6) Installation script which produces the current "Simple-CA" based  
> DN.
>

Yes, these will reflect the new CA key.

> This seems like a lot, but our federation is still relatively small  
> which is good.
>
> As Rachana notes, the greatest user impact of this change (at this  
> point) are those doing data publishing and possibly replication.
>

If we have an overlap period of short-term certificate lifetime, there  
will be no user impact. Am I missing some other user impact?

> I'd argue it is best to make this federation wide CA DN change as  
> soon as we can reliably do it based on a recommended name scheme  
> (which I believe we have in emails.)
>
> Rachana, could someone on the ANL team write up a "recommendation"  
> on the CA DN form?
>

Sure, I'll forward along the email thread. I don't know that we want  
to publish any specifications on this.

Rachana

> (I think we're just trying to have them make intuitive sense and not  
> include strings like "simple", "test", etc., however having some  
> clear guidance may be useful.)
>
> Thanks all for the input!
>
> -Eric
>
>
> Rachana Ananthakrishnan wrote:
>> Hi Luca,
>>
>> Good point. Without token-less security, probably publisher is the   
>> only tool that is affected.
>>
>> I'll let Gavin/Eric comment on the transition requirements.
>>
>> Thanks,
>> Rachana
>>
>> On Aug 6, 2010, at 1:18 PM, Cinquini, Luca (3880) wrote:
>>
>>
>>> Hi Rachana,
>>> 	the DN of each user is stored in the gateway database and used  
>>> to  match the DN in the certificate when client authentication is   
>>> required - at this time only when the user uses the PCMDI  
>>> publisher.  So I believe that if the CA DN for a gateway is  
>>> changed, all user  DNs in the database need to be changed -  
>>> although this can be done  by running a script.
>>> thanks, Luca
>>>
>>> On Aug 6, 2010, at 12:02 PM, Rachana Ananthakrishnan wrote:
>>>
>>>
>>>> Neill, thanks for pulling this together!
>>>>
>>>> I second the need for CA name changes. We have had long threads on
>>>> this before, and strongly urged CA with more meaningful DNs. The
>>>> following need to be changed:
>>>>
>>>> 1. pcmdi3.llnl.gov
>>>> 9388e5cb
>>>> CN=Globus Simple CA, OU=simpleCA-pcmdi3.llnl.gov, OU=GlobusTest,   
>>>> O=Grid
>>>> 2. esg2-gw.ccs.ornl.gov
>>>> bd26fc83
>>>> CN=Globus Simple CA, OU=simpleCA-esg2-gw.ccs.ornl.gov,  
>>>> OU=GlobusTest,
>>>> O=Grid
>>>> 3. ipcc-ar5.dkrz.de
>>>> 6263ffd6
>>>> CN=Globus Simple CA, OU=simpleCA-ipcc-ar5.dkrz.de,  
>>>> OU=GlobusTest,  O=Grid
>>>> 4. albedo2.dkrz.de
>>>> cc6a674f
>>>> CN=Globus Simple CA, OU=simpleCA-albedo2.dkrz.de,  
>>>> OU=GlobusTest, / O=Grid
>>>>
>>>> There is no need to have anything Globus or Simple CA in the DN   
>>>> names.
>>>> Globus SimpleCA is a tool that lets you manage a CA, and nothing in
>>>> the certificates needs to use this. Can owners of these CAs please
>>>> make needed changes? Note, this means that you are creating new key
>>>> pairs and such.  I can forward along the thread with suggestions,  
>>>> if
>>>> you need help.
>>>>
>>>> In current deployments, what is the implication of the change.  
>>>> Users
>>>> have short term certificates, so once the CA is changed, they will
>>>> start to receive certificates certificated by the CA in about 12
>>>> hours. So if we keep the old CA around for that transition  
>>>> period, I
>>>> don't expect any disruptions. Please let me know if there are other
>>>> impacts to consider.
>>>>
>>>> One more question, why is this a trusted CA in the federation?
>>>>
>>>> 1. esgdev.ci.uchicago.edu
>>>> ecdb249f
>>>> CN=Globus Simple CA, OU=simpleCA-esgdev.ci.uchicago.edu,
>>>> OU=GlobusTest, O=Grid
>>>>
>>>> Seems like something introduced for testing, and should be removed
>>>> from this list first, and then when this is provisioned will be
>>>> removed from any site that trusts this now.
>>>>
>>>> Rachana
>>>>
>>>> On Aug 6, 2010, at 11:24 AM, Neill Miller wrote:
>>>>
>>>>
>>>>> Hello Alex,
>>>>>
>>>>> It's a good thing to bring up actually.  Each gateway that runs  
>>>>> a CA
>>>>> gets to more or less specify their DN to be anything they want.
>>>>> Going forward, it's important to name them something more
>>>>> appropriate.  I agree that it doesn't look good to have GlobusTest
>>>>> in the DN as well (as we've discussed this before), so there are  
>>>>> at
>>>>> least 2 options to consider here:
>>>>>
>>>>> 1) Allow everyone to get their gateway working as it is now (since
>>>>> it's not a functional thing, but a perception/cosmetic issue), or
>>>>> 2) Request that everyone start over with their CAs in order to fix
>>>>> the DN*.
>>>>>
>>>>> Maybe Gavin (actually, Eric if I'm following correctly) could
>>>>> describe how this step is done and whether or not it's automated
>>>>> away?  If it's automated and hidden from the user in the script,
>>>>> it's likely even starting over won't change anything for most   
>>>>> people.
>>>>>
>>>>> *This is something that can be done without replacing the entire
>>>>> gateway stack.  As a matter of fact, it's just a couple commands  
>>>>> and
>>>>> then tracking the proper certificates from there.  If this second
>>>>> option is chosen, I can document what each Gateway needs to do in
>>>>> order to remedy the situation.
>>>>>
>>>>> But I'd still like to know how this is done at the Gateway install
>>>>> time so that any NEW gateway installs won't have to do anything
>>>>> special and will have more valid looking (default) DNs.
>>>>>
>>>>> Sound reasonable?
>>>>>
>>>>> -Neill.
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Alex Sim" <asim at lbl.gov>
>>>>> To: neillm at mcs.anl.gov
>>>>> Cc: go-essp-tech at ucar.edu
>>>>> Sent: Friday, August 6, 2010 11:04:56 AM GMT -06:00 US/Canada   
>>>>> Central
>>>>> Subject: Re: [Go-essp-tech] Call for CA and OpenID Trust root
>>>>> Certificates
>>>>>
>>>>> I hate to bring this up again, but the DN format has to work out
>>>>> without GlobusTest in it.
>>>>>
>>>>> -- Alex
>>>>>
>>>>>
>>>>> On 8/6/10 8:49 AM, neillm at mcs.anl.gov wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Thanks to everyone that has submitted their certificate
>>>>>> information!  At the moment, I have a list of MyProxy and OpenID
>>>>>> trusted certificates listed here:
>>>>>>
>>>>>> http://www.ci.uchicago.edu/wiki/bin/view/ESGProject/ESGFederationTrustRoots
>>>>>>
>>>>>> While this page is obviously not complete, please verify that the
>>>>>> certificates that you've sent appear in the listings.  I'd like  
>>>>>> to
>>>>>> know roughly how many more I should be expecting before moving on
>>>>>> to fill in the other details as well, so if you know you haven't
>>>>>> sent yours in yet, please let me know (off-list is fine).
>>>>>>
>>>>>> thanks,
>>>>>> -Neill.
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: neillm at mcs.anl.gov
>>>>>> To: go-essp-tech at ucar.edu
>>>>>> Sent: Tuesday, August 3, 2010 10:58:29 AM GMT -06:00 US/Canada
>>>>>> Central
>>>>>> Subject: [Go-essp-tech] Call for CA and OpenID Trust root
>>>>>> Certificates
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> As discussed on the call just now, I need all OpenID trust root
>>>>>> certificates in addition to the hostname of the machine.
>>>>>>
>>>>>> For anyone that has already submitted theirs (i.e. Luca, Phil),  
>>>>>> if
>>>>>> there are helpful commands that you can share with others, please
>>>>>> do so in follow-up to this.
>>>>>>
>>>>>> A helpful page that shows commands for working with your java  
>>>>>> key/
>>>>>> trust store is here:
>>>>>>
>>>>>> http://www.sslshopper.com/article-most-common-java-keytool-keystore-commands.html
>>>>>>
>>>>>> I also need everyone managing a MyProxy CA to send me their CA
>>>>>> certificates.  If you're running a MyProxy CA, there are 2 simple
>>>>>> ways to find out which certs are needed (please pick one, not   
>>>>>> both):
>>>>>>
>>>>>> 1) Login to the MyProxy CA host and run "ls -al ~/.globus/
>>>>>> simpleCA/" as the user that runs the CA.
>>>>>>
>>>>>> In this listing, you'll see a file called
>>>>>> "globus_simple_ca_XXXXXXXX_setup-0.20.tar.gz" where XXXXXXXX is a
>>>>>> hash of the CA certificate.  Please send the files /etc/grid-
>>>>>> security/certificates/XXXXXXXX.0 and /etc/grid-security/
>>>>>> certificates/XXXXXXXX.signing_policy as well as the hostname of  
>>>>>> the
>>>>>> CA machine.
>>>>>>
>>>>>> 2) Another method of finding which cert to send is to run the   
>>>>>> "grid-
>>>>>> default-ca" program:
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>> $GLOBUS_LOCATION/bin/grid-default-ca
>>>>>>
>>>>>> The available CA configurations installed on this host are:
>>>>>>
>>>>>> Directory: /etc/grid-security/certificates
>>>>>>
>>>>>> 1) 0ba75d15 -  /O=Grid/OU=GlobusTest2/OU=simpleCA-
>>>>>> vm-125-66.ci.uchicago.edu/CN=Globus Simple CA
>>>>>> 2) 1c3f2ca8 -  /DC=org/DC=DOEGrids/OU=Certificate Authorities/
>>>>>> CN=DOEGrids CA 1
>>>>>> 3) 3de8c5e9 -  /O=Grid/OU=GlobusTest/OU=simpleCA-
>>>>>> vm-125-67.ci.uchicago.edu/CN=Globus Simple CA
>>>>>> 4) 519bfbae -  /O=Grid/OU=GlobusTest/OU=simpleCA-
>>>>>> vm-125-66.ci.uchicago.edu/CN=Globus Simple CA
>>>>>> 5) 6349a761 -  /O=DOE Science Grid/OU=Certificate Authorities/
>>>>>> CN=Certificate Manager
>>>>>> 6) 9388e5cb -  /O=Grid/OU=GlobusTest/OU=simpleCA-pcmdi3.llnl.gov/
>>>>>> CN=Globus Simple CA
>>>>>> 7) 9d8753eb -  /DC=net/DC=es/OU=Certificate Authorities/OU=DOE
>>>>>> Science Grid/CN=pki1
>>>>>> 8) d1b603c3 -  /DC=net/DC=ES/O=ESnet/OU=Certificate Authorities/
>>>>>> CN=ESnet Root CA 1
>>>>>> 9) ecdb249f -  /O=Grid/OU=GlobusTest/OU=simpleCA-
>>>>>> esgdev.ci.uchicago.edu/CN=Globus Simple CA
>>>>>>
>>>>>>
>>>>>> The default CA is: /O=Grid/OU=GlobusTest2/OU=simpleCA-
>>>>>> vm-125-66.ci.uchicago.edu/CN=Globus Simple CA
>>>>>>      Location: /etc/grid-security/certificates/0ba75d15.0
>>>>>>
>>>>>> Enter the index number of the CA to set as the default [q to  
>>>>>> quit]
>>>>>> --------------------------------------------------------------------
>>>>>>
>>>>>> To avoid changing anything, press "q" to quit.
>>>>>>
>>>>>> Near the bottom, we are told which CA is currently our default.
>>>>>> Please send the file located at the listed "Location" in addition
>>>>>> to the XXXXXXXX.signing_policy file located in the same  
>>>>>> directory.
>>>>>> Please also send the DN listed with that file and the hostname of
>>>>>> the CA machine.
>>>>>>
>>>>>> IMPORTANT: For the MyProxy CA certificates, I need both the ".0"
>>>>>> AND the ".signing_policy" files together.  Please also send the
>>>>>> machine's hostname.
>>>>>>
>>>>>> -Neill.
>>>>>> _______________________________________________
>>>>>> GO-ESSP-TECH mailing list
>>>>>> GO-ESSP-TECH at ucar.edu
>>>>>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>>>>> _______________________________________________
>>>>>> GO-ESSP-TECH mailing list
>>>>>> GO-ESSP-TECH at ucar.edu
>>>>>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> GO-ESSP-TECH mailing list
>>>>> GO-ESSP-TECH at ucar.edu
>>>>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>>>>
>>>> Rachana Ananthakrishnan
>>>> Argonne National Lab | University of Chicago
>>>>
>>>> _______________________________________________
>>>> GO-ESSP-TECH mailing list
>>>> GO-ESSP-TECH at ucar.edu
>>>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>>>
>>
>> Rachana Ananthakrishnan
>> Argonne National Lab | University of Chicago
>>
>> _______________________________________________
>> GO-ESSP-TECH mailing list
>> GO-ESSP-TECH at ucar.edu
>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
>>
>

Rachana Ananthakrishnan
Argonne National Lab | University of Chicago

More information about the GO-ESSP-TECH mailing list