When using the dogtag CA we can control what the subject of an issued
certificate is regardless of what is in the CSR, we just use the CN value.
The selfsign CA does not have this capability. The subject format must
match the configured format or certificate requests are rejected.
The default format is CN=%s,O=IPA. certmonger by default issues requests
with just CN so all requests would fail if using the selfsign CA.
This subject base is stored in cn=ipaconfig so we can just fetch that
value in the enrollment process and pass it to certmonger to request
the right thing.
Note that this also fixes ipa-join to work with the new argument passing
mechanism.
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.
A number of doc strings were not localized, wrap them in _().
Some messages were not localized, wrap them in _()
Fix a couple of failing tests:
The method name in RPC should not be unicode.
The doc attribute must use the .msg attribute for comparison.
Also clean up imports of _() The import should come from
ipalib or ipalib.text, not ugettext from request.
This moves code that does HTTP and HTTPS requests into a common library
that can be used by both the installer and the dogtag plugin.
These functions are not generic HTTP/S clients, they are designed
specifically to talk to dogtag, so use accordingly.
This error message was producing a warning from xgettext
because there were multiple substations in the string.
In some languages it may be necessary to reorder the
substitutions for a proper translation, this is only
possible if the substitutions use named values.
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.
Need to add a few more places where the DN will not be automatically
normalized. The krb5 server expects a very specific format and normalizing
causes it to not work.
ldap2._generate_modlist now uses more sophisticated means to decide
when to use MOD_ADD+MOD_DELETE instead of MOD_REPLACE.
MOD_REPLACE is always used for single value attributes and never
for multi value.
This profile enables subject validation and ensures that the subject
that the CA issues is uniform. The client can only request a specific
CN, the rest of the subject is fixed.
This is the first step of allowing the subject to be set at
installation time.
Also fix 2 more issues related to the return results migration.
The pyOpenSSL PKCS#10 parser doesn't support attributes so we can't identify
requests with subject alt names.
Subject alt names are only allowed if:
- the host for the alt name exists in IPA
- if binding as host principal, the host is in the services managedBy attr
I saw this with a host where I joined a host, obtained a host
principal, kinited to that principal, then deleted the host from the
IPA server. The ticket was still valid so Apache let it through but
it failed to bind to LDAP.
Using the client IP address was a rather poor mechanism for controlling
who could request certificates for whom. Instead the client machine will
bind using the host service principal and request the certificate.
In order to do this:
* the service will need to exist
* the machine needs to be in the certadmin rolegroup
* the host needs to be in the managedBy attribute of the service
It might look something like:
admin
ipa host-add client.example.com --password=secret123
ipa service-add HTTP/client.example.com
ipa service-add-host --hosts=client.example.com HTTP/client.example.com
ipa rolegroup-add-member --hosts=client.example.com certadmin
client
ipa-client-install
ipa-join -w secret123
kinit -kt /etc/krb5.keytab host/client.example.com
ipa -d cert-request file://web.csr --principal=HTTP/client.example.com
- The aci plugin didn't quite work with the new ldap2 backend.
- We already walk through the target part of the ACI syntax so skip that
in the regex altogether. This now lets us handle all current ACIs in IPA
(some used to be ignored/skipped)
- Add support for user groups so one can do v1-style delegation (group A
can write attributes x,y,z in group B). It is actually quite a lot more
flexible than that but you get the idea)
- Improve error messages in the aci library
- Add a bit of documentation to the aci plugin
This will create a host service principal and may create a host entry (for
admins). A keytab will be generated, by default in /etc/krb5.keytab
If no kerberos credentails are available then enrollment over LDAPS is used
if a password is provided.
This change requires that openldap be used as our C LDAP client. It is much
easier to do SSL using openldap than mozldap (no certdb required). Otherwise
we'd have to write a slew of extra code to create a temporary cert database,
import the CA cert, ...
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())
If you don't want to use ldapi then you can remove the ldap_uri setting
in /etc/ipa/default.conf. The default for the framework is to use
ldap://localhost:389/
ldap2.find_entries now returns a tuple containing 2 values. First,
a list of entries (dn, entry_attrs), Second, the truncated flag. If
the truncated flag is True, search results hit a server limitation
and are incomplete.
This patch also removes decoding of non-string scalar python types into
unicode (they are left unchanged).
