[Go-essp-tech] Call for CA and OpenID Trust root Certificates
Eric Nienhouse
ejn at ucar.edu
Fri Aug 6 13:08:34 MDT 2010
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.
However in general this includes:
1) All system trust stores (Java, grid-security)
2) All system DN based white lists (which are in development)
3) All system user DNs stored at each gateway database as Luca noted.
4) Short lived user certs as Rachana noted.
5) MyProxy server configuration at each Gateway (specialized ESG plugin
scripts.)
6) Installation script which produces the current "Simple-CA" based DN.
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.
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?
(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
>
More information about the GO-ESSP-TECH
mailing list