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

Sat Apr 17 03:43:15 UTC 2010

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:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=583177
> 
> 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.

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

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

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

Thanks again for the testing and feedback.

cheers

rob

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