[Freeipa-users] Using already running dogtag-instance possible?

Fri Apr 16 22:34:00 UTC 2010

Am Freitag, 16. April 2010 15:43:52 schrieb Rob Crittenden:
> ...
> > Just to remember, I'm using the latest IPA V2 from the repository
> > http://jdennis.fedorapeople.org/ipa-devel/fedora/12/...  I found that in
> > the docs and hope its the best source. And I'm using a clean F12
> > installation with all updates.
> 
> I don't know about "best" but it is basically our daily builds. So buyer
> beware :-)

I'm aware of this.  ;-)

> ...
> Hmm, it seems like this should have been fixed in
> https://bugzilla.redhat.com/show_bug.cgi?id=442310 .
> I think the best thing to do would be to open a new bug and reference
> this old one. Bug 441974 is currently closed so is likely not on
> anyone's radar.

Okay, I reported a new one:

https://bugzilla.redhat.com/show_bug.cgi?id=583177

It's just I'm not a fan of flooding bugzilla with same reports.

> ...
> Yes, I wasn't aware of this restriction myself. I think it is definitely
> something that should be addressed. We are trying to be UTF-8 friendly
> in v2 and currently have 8 or 9 translations of the IPA management
> framework (though no German translation yet).
> 
> For a short-term fix would it be acceptable if we set LC_CTYPE to en_US
> when installing dogtag?

I agree with it as a work around. Best practice IMHO would be:

Insert a "LANG=en_US" at top in /etc/init.d/pki-cad

an run pkicreate/pkisilent/pkiremove/... as

# LANG=en_US pkicreate ... 

in ipa-server-install and friends.

> 
> > b)
> > Using „ipa-server-install --setup-dns“, the SOA Records in DNS are wrong.
> >
> > There are missing trailing dots for server-name und email, at
> > reverse-zone also in the zone-name. To look at this, just use dig and dig
> > -x on domain, changing it directly in ldap corrects it..
> >
> > Should be easy to fix in ipaserver/install/bindinstance.py
> 
> Martin, can you look into this? I filed
> https://bugzilla.redhat.com/show_bug.cgi?id=583023
> ...
> > c)
> > manpage ipa-server-install(1): there is no short-option -U for
> > --uninstall, it's bogus with --unattended
> 
> Gah, good catch. I pushed this as a one-liner fix.

Great, thanks. Btw, is it better to report such things in bugzilla, here on 
the list, or both? As I said, I'm not a fan of flooding bugzilla.

> 
> > Thoughts and wishes which could be realized with no big effort:
> >
> > d)
> > Email for zone-manager in bind-setup should be asked/customizeable
> > (root at domain.name is IMHO not a good choice). Maybe this option/answer
> > should also be used as „o=IPA,e=manager at domain.name“ in base-subject for
> > certificates, when –subject is not set by user.
> 
> We do something similar when installing dogtag. We set -admin_email to
> root at localhost.
> 
> I filed https://bugzilla.redhat.com/show_bug.cgi?id=583027

Thanks!

> 
> > e)
> > To me, ipa is more an organisational unit, not the organisation of an
> > individual soho ipa installation. IMHO a better choice for the default
> > subject (if not given by option) used by certificates would be „o=Local
> > Security Domain,ou=IPA,e=manager at domain.name". This could be academic 
> > ;-)  , but it's easier to find the certs in an certificate manager
> > (firefox for example), and it is clearer that there is no official/global
> > IPA CA or trust center with the name IPA.
> 
> Yeah, my picking o=IPA was truly arbitrary. I'm open to further
> suggestions. By "Local Security Domain" do you mean substitute the
> domain name for this or literally use that string?

Well, I looked around a little bit, there seams no reserved or common 
dn/subject-name or something like this for local/private installs of a ca. I 
only found a rfc about reserved domain names for local installs:

http://tools.ietf.org/html/rfc2606

So my best guesses, if we don't want to ask the user for the organization name 
(but asking would be great):

literally use "o=Local Security Domain,ou=FreeIPA,e=..." or
literally use "o=Localhost Security Domain,ou=FreeIPA,e=..." or

"o=<domain> Security Domain,ou=FreeIPA,e=..."

where in the last example <domain> should be replaced with the FQDN (without 
server) or the uppercase kerberos realm.

Best regards,
Oli

> 
> > f)
> > The default valid-range in dogtag for ca-signing cert is 2 years, others
> > are a half year. This is a little bit short. Signing certs for a ca are
> > normaly good for 10 years, and if I think about the release-schedule und
> > updates of fedora, the cert for clients/servers should be valid for at
> > least 1 ½ year in this context.
> 
> I'll let the dogtag guys comment on this. I agree that 2 years for a CA
> sounds a bit short.
> 
> > Thoughts and wishes for the future:
> >
> > g)
> > Currently only SHA1withRSA is used/supported by the pkisilent
> > installation, but it is a little bit outdated. Despite this, the
> > dogtag-system supports the successors like SHA256, etc. out of the box.
> > There was a discussion about it here:
> >
> > https://www.redhat.com/archives/pki-users/2010-April/msg00007.html
> >
> > Currently you have to renewal your initial certs with dogtag by hand, to
> > get this modern hash-alg. It would be nice, if  ipa-server-install would
> > give an option to choose the hash-alg as soon, as pkisilent does.
> 
> Yes, I think that if they add this capability we would want to take
> advantage of it.
> 
> > Okay, hope it was not to much for one posting,
> > best regards,
> > Oli
> 
> This is great feedback, thanks!
> 
> rob
> 
> > Am Dienstag, 13. April 2010 19:58:23 schrieb Rob Crittenden:
> >> Oliver Burtchen wrote:
> >>> Hi Rob,
> >>>
> >>> thanks for the answer. I know about the externel CA-Cert possibility of
> >>> ipa- server- install. But it does not what I want.
> >>>
> >>> I did setup a dogtag ca and a fedora-ds (389). It would be nice, if
> >>> freeipa could just use them. I find it a little bit inconsitent that
> >>> dogtag tries to be a central service, and freeipa claims to be the
> >>> same, setting up a new one.
> >>
> >> Well, it gets tricky because we need an RA certificate in IPA and there
> >> is no automated way to get this with an existing dogtag installation.
> >> This is why making IPA a subordinate CA is suggested, so you can
> >> continue with your existing central authority.
> >>
> >> I'm sure it's possible to wedge in an existing dogtag instance, it would
> >> just take a bit of work and lots of code reading. Among the things you'd
> >> have to do are:
> >>
> >> - change the dogtag ports in IPA
> >> - have your CA issue an RA certificate and trust that user in the
> >> existing CA
> >> - load that RA cert and private key into /etc/httpd/alias using the
> >> right nickname
> >> - set the right CA type in /etc/ipa/default.conf on the IPA server
> >>
> >> Perhaps some other things I'm missing. I'm not sure how cloning will
> >> work in this case.
> >>
> >>> BTW.: Freeipa setup tells me, that it should be the only 389-instance,
> >>> and exist gracefully. Well, my dogtag and bind setup with 389-backend
> >>> works quiet well, i just want freeipa to use them.
> >>
> >> IPA is really geared for configuration on a fresh install. We have to
> >> touch so many things the installation is difficult as it is. Having to
> >> integrate with a lot of existing services makes this doubly more
> >> difficult. You can always disable the check (only via code now, no
> >> arguments for this).
> >>
> >>> Is there a possibility to setup freeipa this way? Thanks for the all in
> >>> one setup, but it means I cannot run an other ldap (389)
> >>> server(-instance) on a machine where freeipa is running. Is this right?
> >>
> >> You can't if it is already installed, at least not without a small code
> >> change.
> >>
> >> We have to use the 80/20 rule here and try to have some control over the
> >>   initial environment before trying the installation. It is probably
> >> possible to do what you want given time and patience but we are unlikely
> >> to do this in the near future.
> >>
> >> rob
> >>
> >>> Best regards,
> >>> Oli
> >>>
> >>> Am Freitag, 9. April 2010 23:42:54 schrieb Rob Crittenden:
> >>>> Oliver Burtchen wrote:
> >>>>> Hi @all,
> >>>>>
> >>>>> is it possible to use an already configured und running
> >>>>> dogtag-instance for freeipa V2 in the installation process? I would
> >>>>> like to give ipa-server- install just the params for the
> >>>>> dogtag-instance/server to use, and skip its own creation-process
> >>>>> (pkisilence ...).
> >>>>>
> >>>>> Or are there arguments for an extra CA used by freeipa?
> >>>>>
> >>>>> Background: I customized dogtag for my needs (using SHA256, default
> >>>>> to 10 year validity of ca-SigningCert, organization and location
> >>>>> defaults, etc. ).
> >>>>>
> >>>>> Best regards,
> >>>>> Oli
> >>>>
> >>>> Probably the best way to do it would be to use the external CA install
> >>>> option (--external-ca). This is a two-step installation process. The
> >>>> first step generates a CSR for the IPA CA. You take this CSR to your
> >>>> existing CA and issue a subordinate CA certificate that will be used
> >>>> by IPA. Then you continue the IPA Installation and it sets up a
> >>>> separate dogtag instance with this subordinate CA.
> >>>>
> >>>> It might be possible to wedge in an existing dogtag install into IPA
> >>>> in another way but I haven't yet tried it.
> >>>>
> >>>> rob
> 

-- 
Oliver Burtchen, Berlin