Update 'ca' plugin doc to mention which permissions are required for
the various commands. Also mention that CAs must first be disabled
before they can be deleted.
Part of: https://fedorahosted.org/freeipa/ticket/5011
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Currently ca-del disables the target CA before deleting it.
Conceptually, this involves two separate permissions: modify and
delete. A user with delete permission does not necessarily have
modify permission.
As we head toward enforcing IPA permissions in Dogtag, it is
necessary to decouple disablement from deletion, otherwise the
disable operation shall fail if the user does not have modify
permission. Although it introduces an additional step for
administrators, the process is consistent, required permissions map
1:1 to the operations, and the error messages make it clear what
needs to happen (i.e. disable first).
Part of: https://fedorahosted.org/freeipa/ticket/5011
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
If lightweight CA key replication has not completed, requests for
the certificate or chain will return 404**. This can occur in
normal operation, and should be a temporary condition. Detect this
case and handle it by simply omitting the 'certificate' and/or
'certificate_out' fields in the response, and add a warning message
to the response.
Also update the client-side plugin that handles the
--certificate-out option. Because the CLI will automatically print
the warning message, if the expected field is missing from the
response, just ignore it and continue processing.
** after the Dogtag NullPointerException gets fixed!
Part of: https://pagure.io/freeipa/issue/7964
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
ldap2.can_add checks for add permission of a given entry.
It did not work properly due to a defect in 389 DS. Now that the
defect has been fixed, we also need to update can_add to work with
the mechanism 389 DS provides for checking add permission for
entries where ACIs are in effect.
Update the ldap2.can_add implementation to perform the add
permission check properly. Also update call sites accordingly.
Update the spec file to require 389-ds-base-1.3.7.9-1 which is the
first release containing the fix. This version of 389-ds-base also
resolves a couple of other issues related to replication and
connection management.
Fixes: https://pagure.io/freeipa/issue/6609
Fixes: https://pagure.io/freeipa/issue/7165
Fixes: https://pagure.io/freeipa/issue/7228
Reviewed-By: Christian Heimes <cheimes@redhat.com>
If the Subject DN is syntactically valid but contains unrecognised
name attributes, FreeIPA accepts it but Dogtag rejects it, returning
status 400 and causing the framework to raise RemoteRetrieveError.
Update the ca-add command to perform some additional validation on
the user-supplied Subject DN, making sure that we recognise all the
attributes.
Fixes: https://pagure.io/freeipa/issue/6987
Reviewed-By: Stanislav Laznicka <slaznick@redhat.com>
Reviewed-By: Felipe Volpone <felipevolpone@gmail.com>
The rename operation on *_mod commands was only allowed when
the primary key of an entry was also its RDN. With these changes,
it should be possible to rename the rest of the entries as well.
An attribute to the base LDAPObject was added to whitelist the
objects we want to allow to be renamed. It replaced an old
attribute rdn_is_primary_key which was used for the very same
purpose but the name was confusing because it was not set
correctly for certain objects.
https://pagure.io/freeipa/issue/2466https://pagure.io/freeipa/issue/6784
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Reviewed-By: Martin Basti <mbasti@redhat.com>
CAs consist of a FreeIPA and a corresponding Dogtag object. When
executing ca-del, ca-enable and ca-disable, changes are made to the
Dogtag object. In the case of ca-del, the corresponding FreeIPA
object is deleted after the Dogtag CA is deleted.
These operations were not correctly authorised; the FreeIPA
permissions are not checked before the Dogtag operations are
executed. This allows any user to delete, enable or disable a
lightweight CA (except the main IPA CA, for which there are
additional check to prevent deletion or disablement).
Add the proper authorisation checks to the ca-del, ca-enable and
ca-disable commands.
https://pagure.io/freeipa/issue/6713
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Using unicode(bytes) call causes undesired side effect that is inserting
`b` character to result. This obviously causes issues with binary base64 data
https://fedorahosted.org/freeipa/ticket/4985
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
The ca_enabled_check function is a wrapper around
api.Command.ca_is_enabled. When using remote_api (e.g. during
installer), ca_enabled_check invokes the *global* api instead of the
remote_api.
Update ca_enabled_check to explicitly receive an api object from the
caller and invoke Command.ca_is_enabled through it.
Part of: https://fedorahosted.org/freeipa/ticket/2614
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Since commit 32b1743e5f, ca-find will fail
with internal error if --pkey-only is specified, because the code to
look up the CA certificate and certificate chain assumes that the ipaCAId
attribute is always present in the result.
Fix this by not attempting to lookup the certificate / chain at all when
--pkey-only is specified.
https://fedorahosted.org/freeipa/ticket/6178
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
32b1743e5f introduced a regression in
test_serverroles.py, caused by ca_find attempting to log into the
Dogtag REST API. (ca_find is called by cert_find which is called by
server_del during cleanup).
Avoid logging into Dogtag in cert_find unless something actually
needs to be retrieved.
Fixes: https://fedorahosted.org/freeipa/ticket/6178
Reviewed-By: Martin Babinsky <mbabinsk@redhat.com>
Administrators need a way to retrieve the certificate or certificate
chain of an IPA-managed lightweight CA. Add params to the `ca'
object for carrying the CA certificate and chain (as multiple DER
values). Add the `--chain' flag for including the chain in the
result (chain is also included with `--all'). Add the
`--certificate-out' option for writing the certificate to a file (or
the chain, if `--chain' was given).
Fixes: https://fedorahosted.org/freeipa/ticket/6178
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Reviewed-By: Tomas Krizek <tkrizek@redhat.com>
Add commentary to 'ca' plugin documentation to explain what happens
when a CA gets deleted - namely, that its signing cert gets revoked
and its private key deleted.
Also break the docstring up into smaller chunks to aid translation.
Fixes: https://fedorahosted.org/freeipa/ticket/6256
Reviewed-By: Martin Basti <mbasti@redhat.com>
We soon plan to revoke certificates upon lightweight CA deletion.
This makes it important to provide a way to prevent a CA from
issuing certificates whilst not deleting and revoking it, and
continuing to allow management of issued certs.
This commit adds the ca-disable and ca-enable commands.
Fixes: https://fedorahosted.org/freeipa/ticket/6257
Reviewed-By: Martin Babinsky <mbabinsk@redhat.com>
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Lightweight CA subject name collisions are prevented by Dogtag
(response code 409 Conflict), however, we do not want to expose the
Dogtag error. Perform the check in the IPA framework as well,
raising DuplicateEntry on collision.
Fixes: https://fedorahosted.org/freeipa/ticket/5981
Reviewed-By: Milan Kubik <mkubik@redhat.com>
This commit adds the 'ca' plugin for creating and managing
lightweight CAs. The initial implementation supports a single level
of sub-CAs underneath the IPA CA.
This commit also:
- adds the container for FreeIPA CA objects
- adds schema for the FreeIPA CA objects
- updates ipa-pki-proxy.conf to allow access to the Dogtag
lightweight CAs REST API.
Part of: https://fedorahosted.org/freeipa/ticket/4559
Reviewed-By: Jan Cholasta <jcholast@redhat.com>
Reviewed-By: Martin Babinsky <mbabinsk@redhat.com>
