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:
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
There is also no hard dependency on the (unreleased) Dogtag 10.3.0b1
- it just puts the necessary principals/keys/configuration in place.
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.
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
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 =
and userdn =
The CN must contain the hostname, and we must also disambiguate on
key type. The current scheme is:
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
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
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
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.
Updated patches attached, include bringing back 0052-2 for the ACI
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code