Oliver Burtchen wrote:
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:


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

I completely understand. We can do this via the mailing or IRC until we nail individual problems down enough to file a bug, I'm ok with that.

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.

Well, I can easily control what IPA does. I can influence what dogtag does, I'll see what the best resolution is.

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
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.

I'm not worried about extraneous bug reports. The advantage of a bugzilla is it doesn't let me forget things to fix. If you want to be cautious you can always report problems on the list and we can address them as they come up, either with 1-liner fixes, explanations or bug filings. I'm fine with reporting problems on the list as long as real problems eventually end up as bugs.

Thoughts and wishes which could be realized with no big effort:

Email for zone-manager in bind-setup should be asked/customizeable
(r...@domain.name is IMHO not a good choice). Maybe this option/answer
should also be used as „o=IPA,e=mana...@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

I filed https://bugzilla.redhat.com/show_bug.cgi?id=583027


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=mana...@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:


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.

Ok, I'll chat with the dogtag team and see if they have any suggestions on best practices. I suspect it will end up very similar to your ideas.

I'm not too keen on asking too many more questions during the installation, the biggest problem being if a user decides against using dogtag.

If one uses dogtag we set the subject in a way that regardless of the subject in the CSR we just use the CN value. So we have ultimate control over the issued subject.

With the self-signed CA we can only reject certificates that don't match what we allow. This isn't very user friendly but is the best we can do using the current NSS command-line tools we use for issuing certs. The NSS tools provide sort of a poor-man's CA so we do the best we can, it just isn't that flexible.

Ideally we make the framework configurable enough so someone could plug in their own cA (tinyCA, OpenSSL, whatever). The backend is more flexible than the front-end (installer) at this point. The tricky part for anyone that wants to bolt on another CA is how to handle replication. But that's another story...

Best regards,

Thanks again for the testing and feedback.



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:

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:


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,
This is great feedback, thanks!


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

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.


Best regards,

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,
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.


Freeipa-users mailing list

Reply via email to