Commit Graph

11 Commits

Author SHA1 Message Date
Rob Crittenden
49b36583a5 Add external CA signing and abstract out the RA backend
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())
2009-09-15 10:01:08 -04:00
Rob Crittenden
e31d5fb1cf Implement support for non-LDAP-based actions that use the LDAP ACI subsystem.
There are some operations, like those for the certificate system, that
don't need to write to the directory server. So instead we have an entry
that we test against to determine whether the operation is allowed or not.

This is done by attempting a write on the entry. If it would succeed then
permission is granted. If not then denied. The write we attempt is actually
invalid so the write itself will fail but the attempt will fail first if
access is not permitted, so we can distinguish between the two without
polluting the entry.
2009-07-10 16:41:05 -04:00
Rob Crittenden
fe012f4ff2 Fix a few issues introduced by the new Param.use_in_context() patch 2009-05-21 14:33:23 -04:00
Rob Crittenden
014f3ff1c6 Improve revocation_reason argument 2009-05-13 14:17:03 -04:00
Rob Crittenden
8f1df0fe8a Store the new certificate in a service record. Clean up some argument names to match the current standard. 2009-05-07 10:54:14 -04:00
Jason Gerard DeRose
7e23ee7cc6 Removed 'Assert False' that was mistakingly left in cert.py; small cleanup in cert.py and ra.py imports 2009-02-17 16:03:10 -05:00
Jason Gerard DeRose
4ab133c3cb Implemented more elegant way for entire plugin module to be conditionally skipped; updated cert.py and ra.py modules to use this 2009-02-17 16:03:10 -05:00
Jason Gerard DeRose
e0fe732318 Added env.enable_ra variable and change cert.py and ra.py plugin modules to register plugins conditionally 2009-02-17 16:03:09 -05:00
Jason Gerard DeRose
97c04c491b Continued cleanup cert/ra plugins 2009-02-17 16:03:09 -05:00
Jason Gerard DeRose
d9d5e8b2d5 Some cleanup in cert plugins module, changed to shorter command names all starting with cert_* 2009-02-17 16:03:08 -05:00
Jason Gerard DeRose
eb73a4fef5 Renamed f_ra.py plugin to cert.py 2009-02-17 16:03:07 -05:00