certutil writes to the local directory when issuing a certificate.
Change to the security database directory when issuing the self-signed CA.
Also handle the case where a user is in a non-existent directory when doing
the install.
This is a temporary fix until we either use Params to determine
output type or treat integers differently from other binary values
internally (as unicode instead of str, for example).
The attributes displayed is now dependant upon their definition in
a Param. This enhances that, giving some level of control over how
the result is displayed to the user.
This also fixes displaying group membership, including failures of
adding/removing entries.
All tests pass now though there is still one problem. We need to
return the dn as well. Once that is fixed we just need to comment
out all the dn entries in the tests and they should once again
pass.
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.
These tests rely on the existence of a backend CA. It is easiest to
test with a self-signed CA in ~/.ipa so that is what I documented.
These tests are skipped if no CA is available.
Improved robustness a bit by putting the cleanup as a separate test.
This does a number of things under the hood:
- Use authconfig to enable sssd in nss and pam
- Configure /etc/sssd/sssd.conf to use our IPA provider
- Enable the certmonger process and request a server cert
- join the IPA domain and retrieve a principal. The clinet machine
*must* exist in IPA to be able to do a join.
- And then undo all this on uninstall
Remove a bunch of trailing spaces
Add the --ca option
Add the --no-host-dns option
Add the --subject option
Fix the one-character option for --no-ntp, should be -N not -n
Add missing line break between --no-ntp and --uninstall
Resolves#545260
This primarily affects the installer. We want to log to the install/
uninstall file in DEBUG. This was getting reset to INFO causing lots of
details to not show in the logs.
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.
Add a new get_subject() helper and return the subject when retrieving
certificates.
Add a normalizer so that everything before and after the BEGIN/END
block is removed.
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.
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.
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.
If a replica is not up for some reason (e.g. you've already deleted it)
this used to quit and not let you delete the replica, generating errors in
the DS logs. This will let you force a deletion.
When we un-enroll a client we'll do a bit of cleanup including removing
any principals for the IPA realm from /etc/krb5.keytab.
This removes principals in 2 ways:
- By principal, only entries matching the full principal are removed
- By realm. Any principal for that realm is removed
This does not change the KDC at all, just removes entries from a file
on the client machine.
This assumes that the developer has the equivalent of a selfsign CA
installed. To do this, install IPA without a CA and copy
/etc/httpd/alias/*.db to ~/.ipa/alias and
/etc/httpd/alias/pwdfile.txt to ~/.ipa/alias/.pwd
Ignore NotImplementedError when revoking a certificate as this isn't
implemented in the selfsign plugin.
Also use the new type argument in x509.load_certificate(). Certificates
are coming out of LDAP as binary instead of base64-encoding.
The new framework uses default.conf instead of ipa.conf. This is useful
also because Apache uses a configuration file named ipa.conf.
This wipes out the last vestiges of the old ipa.conf from v1.
This is needed because in the client installer we actually perform the
join before creating the configuration files that join uses. All we need
is the IPA server to join to and we have that from the CLI options so
use that.
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
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
The CA was moved from residing in the DS NSS database into the Apache
database to support a self-signed CA certificate plugin. This was not
updated in the installer boilerplate.
The DS db wasn't getting a password set on it. Go ahead and set one.
The parsing bug was looking for the string 'version' expecting to find
the ACI version. This blew up with the attribute nsosversion. Use
the string 'version 3.0' instead.
The comparison bug appeared if neither ACI had a targetattr attribute.
It was trying to create a set out of a None which is illegal. If an
ACI doesn't have any targetattrs then return () instead.
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.
Because ipa-join calls ipa-getkeytab I'd like to keep the return values in
sync. ipa-join returns the value returned by ipa-getkeytab so in order to
tell what failed the return values need to mean the same things and not
overlap.
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.
If an exception is not handled here then the context isn't destroyed
leaving at least an LDAP connection dangling. This means the next time
this thread/process tries to handle a connection it will fail because
a context already exists.
This introduces 2 new params: --setattr and --addattr
Both take a name/value pair, ala:
ipa user-mod --setattr=postalcode=20601 jsmith
--setattr replaces or sets the current attribute to the value
--addattr adds the value to an attribute (or sets a new attribute)
OptionsParser allows multiple versions of this, so you can have multiple
setattr and addattr, either for the same attribute or for different
attributes.
ipa user-mod --addattr=postalcode=20601 --addattr=postalcode=30330 jsmith
Values are silent dropped if either of these on an existing param:
ipa user-mod --setattr=givenname=Jerry jsmith
Is a no-op.
This also removes the Index option of /ipa-assets as well as the
deprecated IPADebug option.
No need to build or install ipa_webgui anymore. Leaving in the code
for reference purposes for now.
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
There was much back and forth and gnashing of teeth about what the
version should actually be in these pre-releases. We decided it isn't
2.0-ish enough so went with 1.9.0, 1.9.1, etc until we're ready to
declare 2.0.0.
We want to only allow a machine to request a certificate for itself, not for
other machines. I've added a new taksgroup which will allow this.
The requesting IP is resolved and compared to the subject of the CSR to
determine if they are the same host. The same is done with the service
principal. Subject alt names are not queried yet.
This does not yet grant machines actual permission to request certificates
yet, that is still limited to the taskgroup request_certs.
We were seeing a rare deadlock of DS when creating the memberOf task because
one thread was adding memberOf in a postop while another was trying to
create an index and this was causing a PRLock deadlock.
Rob Crittenden