On Thu, Jul 07, 2016 at 04:10:51PM +0200, Sebastian Hetze wrote:
> On 07/07/2016 03:16 PM, Rob Crittenden wrote:
> > Sebastian Hetze wrote:
> >> Hi *
> >> attached you find a patch that adds new options --subject_cn and
> >> --subject_mail to ipa-server-install that make the CA cert subject CN
> >> customizable.
> >> This patch has been tested by a customer in a PoC.
> >> However, i assume additional testing in different environments is
> >> required.
> >> It would be greatly appreciated if this patch would find its way into
> >> the product very soon.
> > I don't see the advantage of passing around the subject_rdn along with
> > the base. Why not pre-combine them into a DN?
> Think of the subject_rdn as given name for the CA cert and the
> subject_base as family name for all subsequent service certs that IPA
> automatically generates and signs. While the given names for the
> generated service certs may stay hard coded, only the given name for the
> CA cert needs to be customizable as requested in the RFE.
> Look into the source and you will see that subject_base is used all over
> the place and subject_rdn (as replacement for the hard coded
> "CN=Certificate Authority") only related to the CA cert. They need to be
> kept separate.
In your patch, subject_rdn is used in few places where it is passed
around. I agree with Rob; in the handful of places where the full
DN is formed (currently by prepending "CN=Certificate Authority"),
we should pass in the full DN.
> > Similarly, I think I'd drop storing the subject base and RDN and just
> > store just the DN. I don't think there would be any backwards compat
> > issues as this would only apply to new installs.
> > I think this would explode the number of options as users request
> > additional attributes for the subject (OU, C, etc). Might be better to
> > make the user pass in a full DN if they want to manage the CA subject.
> > I don't know if any validation would be required for dogtag (e.g. is
> > there a minimum set of components needed?)
> CN is mandatory and only emailAddress is a commonly used option for the
> "given name" subject_rdn. OU, C and alike belong to the subject_base.
Let us not add new arguments. We should enhance --subject instead.
- ``--subject`` gives subject base. If not given, defaults to
- "CN=Certificate Authority" prepended to subject base to form
full subject DN.
- Dogtag requires that the CA Subject DN starts with CN.
My proposal for augmented behaviour:
- If ``--subject`` not given, existing behaviour retained.
- If ``--subject`` supplied:
1. Extract O, OU, C, L, ST and DC components from argument
(order preserved) to form the subject base. If argument
contains none of these attributes, subject base is defaulted
to "O=$REALM" (per current behaviour) and appended to the CA
2. If argument contains CN but it is not the "most specific"
RDN, move it to the front (to satisfy requirement of Dogtag
3. If argument does not contain CN, prepend "CN=Certificate
Authortiy" per existing behaviour.
4. Apart from (1), (2) and (3), CA Subject DN stays otherwise
unchanged, therefore Email Address (E) is supported.
Sebastian, would this scheme meet your customer's requirements?
I also note, in your patch, that you define method
DsInstance.find_subject_rdn() but it is not used. What is the
purpose of this method?
Thank you for providing this patch and pushing forward on this RFE.
If you are happy with my above proposal I'm happy to take ownership
and get this over this line.
> > rob
> Beste Grüße / Best regards
> Sebastian Hetze
> Senior Solution Architect
> Red Hat GmbH. Niederlassung Berlin
> Am Treptower Park 75 12435 Berlin
> Tel: +49 30 678 1798-241 . Mobil: +49 173 8914205
> Fax: +49 30 678 1798-111 . E-Mail: s...@redhat.com
> Manage your subscription for the Freeipa-devel mailing list:
> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code