Re: [Freeipa-devel] [PATCH] 0053..0054 Configure lightweight CA key replication
On Thu, May 05, 2016 at 07:48:05AM +0200, Jan Cholasta wrote: > On 4.5.2016 06:04, Fraser Tweedale wrote: > >On Tue, May 03, 2016 at 05:05:58PM +1000, Fraser Tweedale wrote: > >>On Tue, Apr 26, 2016 at 10:02:45AM +0200, Jan Cholasta wrote: > >>>On 21.4.2016 05:30, Fraser Tweedale wrote: > On Thu, Apr 14, 2016 at 04:39:37PM +1000, Fraser Tweedale wrote: > >Hi all, > > > >The attached patches configure lightweight CA key replication on IPA > >CAs, on upgrade and installation. > > > >Patches 0051..0052 from my other mail are also needed for the system > >to work, but this patchset does not depend on them and can be > >reviewed independently. > > > >There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1 > >- it just puts the necessary principals/keys/configuration in place. > > > >Cheers, > >Fraser > > > New patches attached; 0054-2 changes the service name from > 'dogtag-ipa-custodia' to just 'dogtag', and adds an ACI to allow the > principal to search server Custodia keys. > >>> > >>Honza, thanks for review. Comments inline. > >> > >>>Patch 53: > >>> > >>>I'm not sure about this approach - the cn of custodia keys in LDAP is a > >>>free-form string, I would not tie it to service names, but rather try to > >>>keep it short. > >>> > >>>In the key replication section of the design page, you mention "ca/$NAME", > >>>I > >>>think this is a good template for the cn and that we should stick to it. > >>> > >>This scheme (or something like it, *without* '/' as the separator) > >>is needed to satisfy the ACI that allows host principals to manage > >>Custodia keys: > >> > >>add:aci: (target = > >> "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") > >>(version 3.0; acl "IPA server hosts can create own Custodia secrets"; > >> allow(add) groupdn = > >> "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX; > >> and userdn = > >> "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) > >> > >>The CN must contain the hostname, and we must also disambiguate on > >>key type. The current scheme is: > >> > >>{sig,enc}~dogtag/ > >>e.g. > >>enc~dogtag/f23-2.ipa.local > >> > >>The first separator cannot be '/' because the '*' wildcard in the > >>ACI is not greedy - the captured text would include the servicename > >>and fail to match any userdn. > >> > >>If you do not like '~' feel free to suggest a different symbol :) > >>The alternative is to add more ACIs. > > I would rather add a new ACI than have one super-ACI for everything. That > way you don't have to invent any complicated naming schemes *and* it will be > more apparent what the ACI does. > OK, I'll simplify the scheme and create corresponding ACIs. > BTW I'm a little bit confused as to what Dogtag keys will actually be stored > in Custodia. My naive understanding is that it would be the CA signing key > of each CA, but seeing how there's a host name and key usage in the name, > I'm not so sure. Could you clarify this, or point me to a design where it is > explained? > Dogtag lightweight CA signing keys are stored in Dogtag's NSSDB (/etc/pki/pki-tomcat/alias), alongside the "main" CA signing key, subsystem keys, etc. Custodia provides access to those keys, but those are not the keys that this patchset creates. The keys being dealt with in this patchset are keys for the Custodia client - running as pkiuser - to authenticate to a Custodia client, and for encrypting the response. They serve no other purpose. It is explained at [1] (note: the design page still refers to the old principal name 'dogtag-ipa-custodia'). [1] http://www.freeipa.org/page/V4/Sub-CAs#Authenticating_to_Custodia > >>> > >>>5) This also belongs to CAInstance.configure_instance(): > >>> > >>>+if setup_ca: > >>>+# CA was configured before Kerberos; > >>>+# add Custodia client princ and keys now > >>>+ca_instance.setup_lightweight_ca_key_retrieval() > >>> > >>>In order for that to work, you need to move the ca.install_step_1() after > >>>krb.create_instance(), but that should be OK, since KrbInstance does not > >>>talk to the CA. > >>> > >>`setup_lightweight_ca_key_retrieval' calls `kadmin_addprinc', which > >>fails if called before `krb.create_instance' due to missing > >>krb5.conf:: > >> > >>2016-05-03T06:29:23Z DEBUG args=kadmin.local -q addprinc -randkey > >> dogtag/f23-2.ipa.local@IPA.LOCAL -x ipa-setup-override-restrictions > >>2016-05-03T06:29:23Z DEBUG Process finished, return code=1 > >>2016-05-03T06:29:23Z DEBUG stdout= > >>2016-05-03T06:29:23Z DEBUG stderr=kadmin.local: unable to get default > >> realm > >> > >>Moving `ca.install_step_1()' to after `krb.create_instance()' does > >>not help, because `CAInstance.configure_instance' is called from > >>`ca.install_step_0()'. > > Right. *slaps forehead* > > >> > >>However, calling `CAInstance.setup_lightweight_ca_key_retrieval()' > >>*directly* from
Re: [Freeipa-devel] [PATCH] 0053..0054 Configure lightweight CA key replication
On 4.5.2016 06:04, Fraser Tweedale wrote: On Tue, May 03, 2016 at 05:05:58PM +1000, Fraser Tweedale wrote: On Tue, Apr 26, 2016 at 10:02:45AM +0200, Jan Cholasta wrote: On 21.4.2016 05:30, Fraser Tweedale wrote: On Thu, Apr 14, 2016 at 04:39:37PM +1000, Fraser Tweedale wrote: Hi all, The attached patches configure lightweight CA key replication on IPA CAs, on upgrade and installation. Patches 0051..0052 from my other mail are also needed for the system to work, but this patchset does not depend on them and can be reviewed independently. There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1 - it just puts the necessary principals/keys/configuration in place. Cheers, Fraser New patches attached; 0054-2 changes the service name from 'dogtag-ipa-custodia' to just 'dogtag', and adds an ACI to allow the principal to search server Custodia keys. Honza, thanks for review. Comments inline. Patch 53: I'm not sure about this approach - the cn of custodia keys in LDAP is a free-form string, I would not tie it to service names, but rather try to keep it short. In the key replication section of the design page, you mention "ca/$NAME", I think this is a good template for the cn and that we should stick to it. This scheme (or something like it, *without* '/' as the separator) is needed to satisfy the ACI that allows host principals to manage Custodia keys: add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") (version 3.0; acl "IPA server hosts can create own Custodia secrets"; allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX; and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) The CN must contain the hostname, and we must also disambiguate on key type. The current scheme is: {sig,enc}~dogtag/ e.g. enc~dogtag/f23-2.ipa.local The first separator cannot be '/' because the '*' wildcard in the ACI is not greedy - the captured text would include the servicename and fail to match any userdn. If you do not like '~' feel free to suggest a different symbol :) The alternative is to add more ACIs. I would rather add a new ACI than have one super-ACI for everything. That way you don't have to invent any complicated naming schemes *and* it will be more apparent what the ACI does. BTW I'm a little bit confused as to what Dogtag keys will actually be stored in Custodia. My naive understanding is that it would be the CA signing key of each CA, but seeing how there's a host name and key usage in the name, I'm not so sure. Could you clarify this, or point me to a design where it is explained? 5) This also belongs to CAInstance.configure_instance(): +if setup_ca: +# CA was configured before Kerberos; +# add Custodia client princ and keys now +ca_instance.setup_lightweight_ca_key_retrieval() In order for that to work, you need to move the ca.install_step_1() after krb.create_instance(), but that should be OK, since KrbInstance does not talk to the CA. `setup_lightweight_ca_key_retrieval' calls `kadmin_addprinc', which fails if called before `krb.create_instance' due to missing krb5.conf:: 2016-05-03T06:29:23Z DEBUG args=kadmin.local -q addprinc -randkey dogtag/f23-2.ipa.local@IPA.LOCAL -x ipa-setup-override-restrictions 2016-05-03T06:29:23Z DEBUG Process finished, return code=1 2016-05-03T06:29:23Z DEBUG stdout= 2016-05-03T06:29:23Z DEBUG stderr=kadmin.local: unable to get default realm Moving `ca.install_step_1()' to after `krb.create_instance()' does not help, because `CAInstance.configure_instance' is called from `ca.install_step_0()'. Right. *slaps forehead* However, calling `CAInstance.setup_lightweight_ca_key_retrieval()' *directly* from `ca.install_step_1' would probably work. Are you happy with putting it there, instead of `configure_instance()'? Works for me. Cheers, Fraser Updated patches attached, include bringing back 0052-2 for the ACI change. Cheers, Fraser -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0053..0054 Configure lightweight CA key replication
On Tue, May 03, 2016 at 05:05:58PM +1000, Fraser Tweedale wrote: > On Tue, Apr 26, 2016 at 10:02:45AM +0200, Jan Cholasta wrote: > > On 21.4.2016 05:30, Fraser Tweedale wrote: > > >On Thu, Apr 14, 2016 at 04:39:37PM +1000, Fraser Tweedale wrote: > > >>Hi all, > > >> > > >>The attached patches configure lightweight CA key replication on IPA > > >>CAs, on upgrade and installation. > > >> > > >>Patches 0051..0052 from my other mail are also needed for the system > > >>to work, but this patchset does not depend on them and can be > > >>reviewed independently. > > >> > > >>There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1 > > >>- it just puts the necessary principals/keys/configuration in place. > > >> > > >>Cheers, > > >>Fraser > > >> > > >New patches attached; 0054-2 changes the service name from > > >'dogtag-ipa-custodia' to just 'dogtag', and adds an ACI to allow the > > >principal to search server Custodia keys. > > > Honza, thanks for review. Comments inline. > > > Patch 53: > > > > I'm not sure about this approach - the cn of custodia keys in LDAP is a > > free-form string, I would not tie it to service names, but rather try to > > keep it short. > > > > In the key replication section of the design page, you mention "ca/$NAME", I > > think this is a good template for the cn and that we should stick to it. > > > This scheme (or something like it, *without* '/' as the separator) > is needed to satisfy the ACI that allows host principals to manage > Custodia keys: > > add:aci: (target = > "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") > (version 3.0; acl "IPA server hosts can create own Custodia secrets"; > allow(add) groupdn = > "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX; > and userdn = > "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) > > The CN must contain the hostname, and we must also disambiguate on > key type. The current scheme is: > > {sig,enc}~dogtag/ > e.g. > enc~dogtag/f23-2.ipa.local > > The first separator cannot be '/' because the '*' wildcard in the > ACI is not greedy - the captured text would include the servicename > and fail to match any userdn. > > If you do not like '~' feel free to suggest a different symbol :) > The alternative is to add more ACIs. > > > > > Patch 54: > > > > 1) This belongs to CAInstance.configure_instance(): > > > > +CA = cainstance.CAInstance( > > +api.env.realm, certs.NSS_DIR, host_name=api.env.host) > > +CA.setup_lightweight_ca_key_retrieval() > > > See comments for (5). > > > > > 2) Any ACI changes should be in a separate patch. (What happened to patch > > 52?) > > > Patch 52 added an ACI that allowed any authenticated user to see the > keys. Simo wanted it limited it to the Dogtag principal so I > rescinded patch 52 and added the ACI in the same patch where the > principal was added. > > Separate patch is no problem; I will resurrect number 52. > > > > > 3) This is not a platform constant, just a constant: > > > > +PKI_GSSAPI_SERVICE_NAME = 'dogtag' > > > Thanks, will put it in `ipalib.constants'. > > > > > 4) CAInstance.setup_lightweight_ca_key_retrieval() does too much. Please > > split it into a "setup keytab" and "setup custodia" parts. > > > Will extract methods for next patchset. > > > > > 5) This also belongs to CAInstance.configure_instance(): > > > > +if setup_ca: > > +# CA was configured before Kerberos; > > +# add Custodia client princ and keys now > > +ca_instance.setup_lightweight_ca_key_retrieval() > > > > In order for that to work, you need to move the ca.install_step_1() after > > krb.create_instance(), but that should be OK, since KrbInstance does not > > talk to the CA. > > > `setup_lightweight_ca_key_retrieval' calls `kadmin_addprinc', which > fails if called before `krb.create_instance' due to missing > krb5.conf:: > > 2016-05-03T06:29:23Z DEBUG args=kadmin.local -q addprinc -randkey > dogtag/f23-2.ipa.local@IPA.LOCAL -x ipa-setup-override-restrictions > 2016-05-03T06:29:23Z DEBUG Process finished, return code=1 > 2016-05-03T06:29:23Z DEBUG stdout= > 2016-05-03T06:29:23Z DEBUG stderr=kadmin.local: unable to get default > realm > > Moving `ca.install_step_1()' to after `krb.create_instance()' does > not help, because `CAInstance.configure_instance' is called from > `ca.install_step_0()'. > > However, calling `CAInstance.setup_lightweight_ca_key_retrieval()' > *directly* from `ca.install_step_1' would probably work. Are you > happy with putting it there, instead of `configure_instance()'? > > Cheers, > Fraser > Updated patches attached, include bringing back 0052-2 for the ACI change. Cheers, Fraser From 3d047e3dc1e7f700751c0f52f26326764b70d94d Mon Sep 17 00:00:00 2001 From: Fraser TweedaleDate: Tue, 3 May 2016 13:22:39 +1000 Subject: [PATCH] Allow Dogtag service principals to read Custodia keys The
Re: [Freeipa-devel] [PATCH] 0053..0054 Configure lightweight CA key replication
On Tue, Apr 26, 2016 at 10:02:45AM +0200, Jan Cholasta wrote: > On 21.4.2016 05:30, Fraser Tweedale wrote: > >On Thu, Apr 14, 2016 at 04:39:37PM +1000, Fraser Tweedale wrote: > >>Hi all, > >> > >>The attached patches configure lightweight CA key replication on IPA > >>CAs, on upgrade and installation. > >> > >>Patches 0051..0052 from my other mail are also needed for the system > >>to work, but this patchset does not depend on them and can be > >>reviewed independently. > >> > >>There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1 > >>- it just puts the necessary principals/keys/configuration in place. > >> > >>Cheers, > >>Fraser > >> > >New patches attached; 0054-2 changes the service name from > >'dogtag-ipa-custodia' to just 'dogtag', and adds an ACI to allow the > >principal to search server Custodia keys. > Honza, thanks for review. Comments inline. > Patch 53: > > I'm not sure about this approach - the cn of custodia keys in LDAP is a > free-form string, I would not tie it to service names, but rather try to > keep it short. > > In the key replication section of the design page, you mention "ca/$NAME", I > think this is a good template for the cn and that we should stick to it. > This scheme (or something like it, *without* '/' as the separator) is needed to satisfy the ACI that allows host principals to manage Custodia keys: add:aci: (target = "ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX") (version 3.0; acl "IPA server hosts can create own Custodia secrets"; allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX; and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";) The CN must contain the hostname, and we must also disambiguate on key type. The current scheme is: {sig,enc}~dogtag/ e.g. enc~dogtag/f23-2.ipa.local The first separator cannot be '/' because the '*' wildcard in the ACI is not greedy - the captured text would include the servicename and fail to match any userdn. If you do not like '~' feel free to suggest a different symbol :) The alternative is to add more ACIs. > > Patch 54: > > 1) This belongs to CAInstance.configure_instance(): > > +CA = cainstance.CAInstance( > +api.env.realm, certs.NSS_DIR, host_name=api.env.host) > +CA.setup_lightweight_ca_key_retrieval() > See comments for (5). > > 2) Any ACI changes should be in a separate patch. (What happened to patch > 52?) > Patch 52 added an ACI that allowed any authenticated user to see the keys. Simo wanted it limited it to the Dogtag principal so I rescinded patch 52 and added the ACI in the same patch where the principal was added. Separate patch is no problem; I will resurrect number 52. > > 3) This is not a platform constant, just a constant: > > +PKI_GSSAPI_SERVICE_NAME = 'dogtag' > Thanks, will put it in `ipalib.constants'. > > 4) CAInstance.setup_lightweight_ca_key_retrieval() does too much. Please > split it into a "setup keytab" and "setup custodia" parts. > Will extract methods for next patchset. > > 5) This also belongs to CAInstance.configure_instance(): > > +if setup_ca: > +# CA was configured before Kerberos; > +# add Custodia client princ and keys now > +ca_instance.setup_lightweight_ca_key_retrieval() > > In order for that to work, you need to move the ca.install_step_1() after > krb.create_instance(), but that should be OK, since KrbInstance does not > talk to the CA. > `setup_lightweight_ca_key_retrieval' calls `kadmin_addprinc', which fails if called before `krb.create_instance' due to missing krb5.conf:: 2016-05-03T06:29:23Z DEBUG args=kadmin.local -q addprinc -randkey dogtag/f23-2.ipa.local@IPA.LOCAL -x ipa-setup-override-restrictions 2016-05-03T06:29:23Z DEBUG Process finished, return code=1 2016-05-03T06:29:23Z DEBUG stdout= 2016-05-03T06:29:23Z DEBUG stderr=kadmin.local: unable to get default realm Moving `ca.install_step_1()' to after `krb.create_instance()' does not help, because `CAInstance.configure_instance' is called from `ca.install_step_0()'. However, calling `CAInstance.setup_lightweight_ca_key_retrieval()' *directly* from `ca.install_step_1' would probably work. Are you happy with putting it there, instead of `configure_instance()'? Cheers, Fraser -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0053..0054 Configure lightweight CA key replication
On 21.4.2016 05:30, Fraser Tweedale wrote: On Thu, Apr 14, 2016 at 04:39:37PM +1000, Fraser Tweedale wrote: Hi all, The attached patches configure lightweight CA key replication on IPA CAs, on upgrade and installation. Patches 0051..0052 from my other mail are also needed for the system to work, but this patchset does not depend on them and can be reviewed independently. There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1 - it just puts the necessary principals/keys/configuration in place. Cheers, Fraser New patches attached; 0054-2 changes the service name from 'dogtag-ipa-custodia' to just 'dogtag', and adds an ACI to allow the principal to search server Custodia keys. Patch 53: I'm not sure about this approach - the cn of custodia keys in LDAP is a free-form string, I would not tie it to service names, but rather try to keep it short. In the key replication section of the design page, you mention "ca/$NAME", I think this is a good template for the cn and that we should stick to it. Patch 54: 1) This belongs to CAInstance.configure_instance(): +CA = cainstance.CAInstance( +api.env.realm, certs.NSS_DIR, host_name=api.env.host) +CA.setup_lightweight_ca_key_retrieval() 2) Any ACI changes should be in a separate patch. (What happened to patch 52?) 3) This is not a platform constant, just a constant: +PKI_GSSAPI_SERVICE_NAME = 'dogtag' 4) CAInstance.setup_lightweight_ca_key_retrieval() does too much. Please split it into a "setup keytab" and "setup custodia" parts. 5) This also belongs to CAInstance.configure_instance(): +if setup_ca: +# CA was configured before Kerberos; +# add Custodia client princ and keys now +ca_instance.setup_lightweight_ca_key_retrieval() In order for that to work, you need to move the ca.install_step_1() after krb.create_instance(), but that should be OK, since KrbInstance does not talk to the CA. Honza -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0053..0054 Configure lightweight CA key replication
On Thu, Apr 14, 2016 at 04:39:37PM +1000, Fraser Tweedale wrote: > Hi all, > > The attached patches configure lightweight CA key replication on IPA > CAs, on upgrade and installation. > > Patches 0051..0052 from my other mail are also needed for the system > to work, but this patchset does not depend on them and can be > reviewed independently. > > There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1 > - it just puts the necessary principals/keys/configuration in place. > > Cheers, > Fraser > New patches attached; 0054-2 changes the service name from 'dogtag-ipa-custodia' to just 'dogtag', and adds an ACI to allow the principal to search server Custodia keys. Cheers, Fraser From b30e8d640a03ec81d5a1f962a81076993d9cea69 Mon Sep 17 00:00:00 2001 From: Fraser TweedaleDate: Mon, 11 Apr 2016 12:42:35 +1000 Subject: [PATCH 53/54] Optionally add service name to Custodia key DNs Lightweight CAs support introduces new service principals for Dogtag, with Custodia keys. The current Custodia key creation uses a DN that contains only they key type and the hostname, so keys for multiple services on the same host cannot be created. Add the 'generate_keys' method to generate keys for a host or an arbitrary service. When a service name is given, include the service name in the DN. This change does not affect searching because all searching is done using the ipaKeyUsage and memberPrincipal attributes. Part of: https://fedorahosted.org/freeipa/ticket/4559 --- ipapython/secrets/kem.py | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/ipapython/secrets/kem.py b/ipapython/secrets/kem.py index 1025ed7980f055c82c602634e8845fa490cf0514..533121779241d30e19fef4c050bb69c55d29ec22 100644 --- a/ipapython/secrets/kem.py +++ b/ipapython/secrets/kem.py @@ -105,10 +105,11 @@ class KEMLdap(iSecLdap): encoding=serialization.Encoding.DER, format=serialization.PublicFormat.SubjectPublicKeyInfo) -def set_key(self, usage, host, principal, key): +def set_key(self, usage, servicename, host, principal, key): public_key = self._format_public_key(key) conn = self.connect() -name = '%s/%s' % (KEY_USAGE_MAP[usage], host) +service_segment = '~' + servicename if servicename else '' +name = '%s%s/%s' % (KEY_USAGE_MAP[usage], service_segment, host) dn = 'cn=%s,%s' % (name, self.keysbase) try: mods = [('objectClass', ['nsContainer', @@ -170,15 +171,18 @@ class IPAKEMKeys(KEMKeysStore): return conn.get_key(usage, kid) def generate_server_keys(self): -principal = 'host/%s@%s' % (self.host, self.realm) +self.generate_keys() + +def generate_keys(self, servicename=None): +principal = '%s/%s@%s' % (servicename or 'host', self.host, self.realm) # Neutralize the key with read if any self._server_keys = None # Generate private key and store it pubkeys = newServerKeys(self.config['server_keys'], principal) # Store public key in LDAP ldapconn = KEMLdap(self.ldap_uri) -ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0]) -ldapconn.set_key(KEY_USAGE_ENC, self.host, principal, pubkeys[1]) +ldapconn.set_key(KEY_USAGE_SIG, servicename, self.host, principal, pubkeys[0]) +ldapconn.set_key(KEY_USAGE_ENC, servicename, self.host, principal, pubkeys[1]) @property def server_keys(self): -- 2.5.5 From 8fa16b34e9c866d2f2470d70cb4b265e28013a16 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale Date: Mon, 11 Apr 2016 16:47:33 +1000 Subject: [PATCH 54/54] Setup lightweight CA key retrieval on install/upgrade To configure Dogtag lightweight CA key replication on installation and upgrade: - add the 'dogtag/$HOSTNAME' service principal - create the pricipal's Custodia keys - add ACI to allow the principal to read server Custodia keys - retrieve keytab - configure the IPACustodiaKeyRetriever in CS.cfg Part of: https://fedorahosted.org/freeipa/ticket/4559 --- install/tools/ipa-ca-install| 4 install/updates/20-aci.update | 3 +++ ipaplatform/base/constants.py | 1 + ipaserver/install/cainstance.py | 43 + ipaserver/install/server/install.py | 8 ++- ipaserver/install/server/upgrade.py | 6 +- 6 files changed, 63 insertions(+), 2 deletions(-) diff --git a/install/tools/ipa-ca-install b/install/tools/ipa-ca-install index 1bc5def03bf687a1e4f9fb38a54363b5429c8fc4..0af5b39116b4649423ed2a51579e2adc767d802b 100755 --- a/install/tools/ipa-ca-install +++ b/install/tools/ipa-ca-install @@ -226,6 +226,10 @@ def install_master(safe_options, options): ca.install_check(True, None, options) ca.install(True, None, options) +CA = cainstance.CAInstance( +api.env.realm, certs.NSS_DIR, host_name=api.env.host) +