Re: [Freeipa-devel] [PATCH] 0053..0054 Configure lightweight CA key replication

[Fraser Tweedale]

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

[Jan Cholasta]

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

[Fraser Tweedale]

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 Tweedale 
Date: 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

[Fraser Tweedale]

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

[Jan Cholasta]

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

[Fraser Tweedale]

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 Tweedale 
Date: 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)
+