This replaces the old no logging mechanism that only handled not logging
passwords passed on the command-line. The dogtag installer was including
passwords in the output.
This also adds no password logging to the sslget invocations and removes
a couple of extraneous log commands.
ticket 156
Installing dogtag is quite slow and it isn't always clear that things
are working. This breaks out some restart calls into separate steps
to show some amount of progress. There are still some steps that take
more than a minute (pkicreate and pkisilent).
Add new argument to pkisilent, -key_algorithm
Update a bunch of minimum required versions in the spec file.
tickets 139 (time) and 144 (key_algorithm)
This causes the installation to blow up badly otherwise.
To remove an existing instance run:
# pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca
I couldn't put the dogtag rules into the spec file until we required
dogtag as a component. If it wasn't pre-loaded them the rules loading
would fail because types would be missing.
We have had a state file for quite some time that is used to return
the system to its pre-install state. We can use that to determine what
has been configured.
This patch:
- uses the state file to determine if dogtag was installed
- prevents someone from trying to re-install an installed server
- displays some output when uninstalling
- re-arranges the ipa_kpasswd installation so the state is properly saved
- removes pkiuser if it was added by the installer
- fetches and installs the CA on both masters and clients
- cache all interactive answers
- set non-interactive to True for the second run so nothing is asked
- convert boolean values that are read in
- require absolute paths for the external CA and signed cert files
- fix the invocation message for the second ipa-server-install run
We set a new port to be used with dogtag but IPA doesn't utilize it.
This also changes the way we determine which security database to use.
Rather than using whether api.env.home is set use api.env.in_tree.
Also print out a restart message after applying the custom subject.
It takes a while to restart dogtag and this lets the user know things
are moving forward.
NSS is going to disallow all SSL renegotiation by default. Because of
this we need to always use the agent port of the dogtag server which
always requires SSL client authentication. The end user port will
prompt for a certificate if required but will attempt to re-do the
handshake to make this happen which will fail with newer versions of NSS.
Let the user, upon installation, set the certificate subject base
for the dogtag CA. Certificate requests will automatically be given
this subject base, regardless of what is in the CSR.
The selfsign plugin does not currently support this dynamic name
re-assignment and will reject any incoming requests that don't
conform to the subject base.
The certificate subject base is stored in cn=ipaconfig but it does
NOT dynamically update the configuration, for dogtag at least. The
file /var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg would need to
be updated and pki-cad restarted.
Also properly use the instance name where appropriate. There were a
couple of places where the service name was used and this worked because
they were the same.
We use kadmin.local to bootstrap the creation of the kerberos principals
for the IPA server machine: host, HTTP and ldap. This works fine and has
the side-effect of protecting the services from modification by an
admin (which would likely break the server).
Unfortunately this also means that the services can't be managed by useful
utilities such as certmonger. So we have to create them as "real" services
instead.
There are times where a caller will want to determine the course of
action based on the returncode instead of relying on it != 0.
This also lets the caller get the contents of stdout and stderr.
This policy should really be provided by dogtag. We don't want
to grant read/write access to everything dogtag can handle so we
change the context to cert_t instead. But we have to let dogtag
read/write that too hence this policy.
To top it off we can't load this policy unless dogtag is also loaded
so we insert it in the IPA installer
Installing a CA that is signed by another CA is a 2-step process. The first
step is to generate a CSR for the CA and the second step is to install
the certificate issued by the external CA. To avoid asking questions
over and over (and potentially getting different answers) the answers
are cached.
External CA signing is a 2-step process. You first have to run the IPA
installer which will generate a CSR. You pass this CSR to your external
CA and get back a cert. You then pass this cert and the CA cert and
re-run the installer. The CSR is always written to /root/ipa.csr.
A run would look like:
# ipa-server-install --ca --external-ca -p password -a password -r EXAMPLE.COM -u dirsrv -n example.com --hostname=ipa.example.com -U
[ sign cert request ]
# ipa-server-install --ca --external-ca -p password -a password --external_cert_file=/tmp/rob.crt --external_ca_file=/tmp/cacert.crt -U -p password -a password -r EXAMPLE.COM -u dirsrv -n example.com --hostname=ipa.example.com
This also abstracts out the RA backend plugin so the self-signed CA we
create can be used in a running server. This means that the cert plugin
can request certs (and nothing else). This should let us do online replica
creation.
To handle the self-signed CA the simple ca_serialno file now contains
additional data so we don't have overlapping serial numbers in replicas.
This isn't used yet. Currently the cert plugin will not work on self-signed
replicas.
One very important change for self-signed CAs is that the CA is no longer
held in the DS database. It is now in the Apache database.
Lots of general fixes were also made in ipaserver.install.certs including:
- better handling when multiple CA certificates are in a single file
- A temporary directory for request certs is not always created when the
class is instantiated (you have to call setup_cert_request())
This involves creating a new CA instance on the replica and using pkisilent
to create a clone of the master CA.
Also generally fixes IPA to work with the latest dogtag SVN tip. A lot of
changes to ports and configuration have been done recently.
Use the requestId we get back from the CA when requesting the RA agent cert
and use that to issue the certificate rather than hardcoding 7.
This also adds some clean-up of file permissions and leaking fds
Notes:
- will create a CA instance (pki-ca) if it doesn't exist
- maintains support for a self-signed CA
- A signing cert is still not created so Firefox autoconfig still won't work
The CA is currently not automatically installed. You have to pass in the
--ca flag to install it.
What works:
- installation
- unistallation
- cert/ra plugins can issue and retrieve server certs
What doesn't work:
- self-signed CA is still created and issues Apache and DS certs
- dogtag and python-nss not in rpm requires
- requires that CS be in the "pre" install state from pkicreate
