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

Fri Apr 16 02:01:29 UTC 2010

Hi Dmitri,
hi Rob,

first of all, thanks for your support and the detailed answers. It makes it 
clearer to me what the goal of freeipa is. I think it would fit exactly my 
needs for a new soho installation (managing round about 20 clients, some 
laptops and often changing employees), if some issues can be solved. I'll try 
to answer to you both together.

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 started to fiddle around with the installation process, because it breaks by 
bug a)  after solving it I saw bug b), and so on..  ;-)  After that, I came to 
the conclusion it would be better to setup dns and dogtag by hand. But it 
would be great just to use ipa-server-install. So here are my observations 
with hopefully helpful solution-hints, as I wrote them down for myself.

By the way, thanks for the great work to the FreeIPA-Team so far.

Bugs and solution-hints:

a)
The installation-process of pki/dogtag (pkicreate/pkisilent) throws an 
exception and breaks down documented in the logs, if the locale is different 
from „en“. This is not because of missing translations, but because of a wrong 
use of java-load-resources (filenames) in the pki-sources, so it does not find 
the english fallbacks (which are the only ones for now, what is okay). As I 
described in this bugreport 
https://bugzilla.redhat.com/show_bug.cgi?id=441974#c34  it is very obviously 
and easy to fix, but now pending for 2 years.

And the dogtag 
Known Issues: Problems and Solutions – page 

http://pki.fedoraproject.org/wiki/PKI_Known_Issues

just says: „Change LC_CTYPE to en_US before starting and everything will 
work“.

Okay, I understand. Sounds a little bit like what I heard often: Change 
OS_TYPE to MS before starting and everything will work. Just kidding.  ;-)

But it should not be difficult to change a handfull of  filenames, so this great 
peace of software would work all over the world, not just in the english 
locale. I don't want to comment this any further.  ;-)

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

c)
manpage ipa-server-install(1): there is no short-option -U for --uninstall, 
it's bogus with --unattended

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.

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.

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.

Currently pkicreate nor pkisilent offer an option to change this. My workaround 
is to alter the profile-files between the runs of pkicreate and 
pkisilent/wizard. Maybe it could be asked for the validity in ipa-server-
install. Here is my bash-cli-script for 10 years validity:

PKINAME=pki-ca; \
ORIGPWD=${PWD}; \
pkicreate -pki_instance_root=/var/lib -pki_instance_name=${PKINAME} \
  -subsystem_type=ca -agent_secure_port=9443 -ee_secure_port=9444 \
  -admin_secure_port=9445 -unsecure_port=9180 -tomcat_server_port=9701 \
  -user=pkiuser -group=pkiuser -redirect conf=/etc/${PKINAME} \
  -redirect logs=/var/log/${PKINAME} -verbose; \
 \
cd /etc/${PKINAME}; \
 \
cp caCert.profile caCert.profile.orig; \
sed 's/2.default.params.range=[0-9]*/2.default.params.range=3650/g' \
  <  caCert.profile.orig >  caCert.profile; \
rm -f caCert.profile.orig; \
 \
cd /var/lib/${PKINAME}/profiles/ca; \
 \
cp caCACert.cfg caCACert.cfg.orig; \
sed 
's/policyset.caCertSet.2.constraint.params.range=[0-9]*/policyset.caCertSet.2.constraint.params.range=3650/g' 
\
  <  caCACert.cfg.orig >  caCACert.cfg.tmp; \
sed 
's/policyset.caCertSet.2.default.params.range=[0-9]*/policyset.caCertSet.2.default.params.range=3650/g' 
\
  <  caCACert.cfg.tmp >  caCACert.cfg ; \
rm -f caCACert.cfg.tmp; \
rm -f caCACert.cfg.orig; \
 \
cd ${ORIGPWD}; \
service pki-cad restart ${PKINAME}

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. 

Okay, hope it was not to much for one posting,
best regards,
Oli

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