When authentication indicators were introduced in 2016, ipa-pwd-extop
plugin gained ability to reject LDAP BIND when an LDAP client insists
the authentication must use an OTP token. This is used by ipa-otpd to
ensure Kerberos authentication using OTP method is done with at least
two factors (the token and the password).
This enfrocement is only possible when an LDAP client sends the LDAP
control. There are cases when LDAP clients cannot be configured to send
a custom LDAP control during BIND operation. For these clients an LDAP
BIND against an account that only has password and no valid token would
succeed even if admins intend it to fail.
Ability to do LDAP BIND without a token was added to allow users to add
their own OTP tokens securely. If administrators require full
enforcement over LDAP BIND, it is cannot be achieved with LDAP without
sending the LDAP control to do so.
Add IPA configuration string, EnforceLDAPOTP, to allow administrators to
prevent LDAP BIND with a password only if user is required to have OTP
tokens. With this configuration enabled, it will be not possible for
users to add OTP token if one is missing, thus ensuring no user can
authenticate without OTP and admins will have to add initial OTP tokens
to users explicitly.
Fixes: https://pagure.io/freeipa/issue/5169
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
ipa-restore is relying on the presence of specific directories,
e.g. /var/lib/dirsrv/slapd-/db/ipaca, to detect
which backends are in use (userRoot or ipaca).
With the switch to LMDB, these directories do not exist and the
restore fails finding the ipaca backend.
Use lib389.cli_ctl.dblib.run_dbscan utility instead to
check which backends are present.
This method was been introduced in 389ds 2.1.0 and works with
Berkeley DB and LMDB.
Add a --data option to the ipa-backup and ipa-restore tasks to do
only an LDIF backup and restore. Also add the ability to restore by
backend.
Add new tests to do a data-only backup and restore.
Fixes: https://pagure.io/freeipa/issue/9526
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Do minimal validation of the Kerberos principal name when passing it to
kinit command line tool. Also pass it as the final argument to prevent
option injection.
Accepted Kerberos principals are:
- user names, using the following regexp
(username with optional @realm, no spaces or slashes in the name):
"(?!^[0-9]+$)^[a-zA-Z0-9_.][a-zA-Z0-9_.-]*[a-zA-Z0-9_.$-]?@?[a-zA-Z0-9.-]*$"
- service names (with slash in the name but no spaces). Validation of
the hostname is done. There is no validation of the service name.
The regular expression above also covers cases where a principal name
starts with '-'. This prevents option injection as well.
This fixes CVE-2024-1481
Fixes: https://pagure.io/freeipa/issue/9541
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
ipa-backup is relying on the presence of the directory
/var/lib/dirsrv/slapd-<INSTANCE>/db/ipaca/
to detect if the CA is installed on the server and backup
the ipaca backend.
With the switch to LMDB, this directory does not exist and the
backup is missing ipaca information.
Use lib389.cli_ctl.dblib.run_dbscan utility instead to
check if ipaca backend is present (this method has been
introduced in 389ds 2.1.0 and works with Berkeley DB and LMDB).
Fixes: https://pagure.io/freeipa/issue/9516
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thierry Bordaz <tbordaz@redhat.com>
Vault uses PKCS1v15 as default padding wrapping algo, which is not an approved
FIPS algorithm. This commit ensures that KRA is installed with RSA-OAEP if FIPS
is enabled. It also handles upgrade path.
Fixes: https://pagure.io/freeipa/issue/9191
Signed-off-by: Francisco Trivino <ftrivino@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
If a vault operation fails, the error message just says "InternalError". This commit
improves error handling of key archival and retrieval calls by catching the PKIException
error and raising it as an IPA error.
Related: https://pagure.io/freeipa/issue/9191
Signed-off-by: Francisco Trivino <ftrivino@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Cryptography 42.0.0 introduced two new abstract properties
`not_valid_before_utc` and `not_valid_after_utc`, which are non-naive UTC
variants of the `not_valid_before` and `not_valid_after` properties.
The old properties are deprecated. The changeset also modifies code and
tests to use the new `_utc` variants.
Fixes: https://pagure.io/freeipa/issue/9518
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
This should not have been gated on options.setup_ca because we need
the RA agent on all servers if there is a CA in the topology otherwise
the non-CA servers won't be able to communicate with the CA.
Fixes: https://pagure.io/freeipa/issue/9510
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
ca_enable and kra_enabled are intended to be used to identify that
a CA or KRA is available in the topology. It was also being used
to determine whether a CA or KRA service is desired on a replica
install, rather than options.setup_[ca|kra]
Fixes: https://pagure.io/freeipa/issue/9510
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Some tools may pass None as NetBIOS name if not put explicitly by a
user. This meant to use default NetBIOS name generator based on the
domain (realm) name. However, this wasn't done properly, so None is
passed later to python-ldap and it rejects such LDAP entry.
Fixes: https://pagure.io/freeipa/issue/9514
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Since commit 5c0e7a5fb4, a new extended
operation to get a keytab is supposed to be used. This keytab
setting/retrieval extended operation checks access rights of the bound
DN to write to a virtual attribute 'ipaProtectedOperation;write_keys'.
If the write isn't allowed, the operation is rejected and ipa-getkeytab
tool falls back to an older code that generates the keytab on the client
and forcibly sets to the LDAP entry. For the latter, a check is done to
make sure the bound DN is allowed to write to 'krbPrincipalKey' attribute.
This fallback should never happen for newer deployments. When enrollemnt
operation is delegated to non-administrative user with the help of 'Host
Enrollment' role, a host can be pre-created or created at enrollment
time, if this non-administrative user has 'Host Administrators' role. In
the latter case a system permission 'System: Manage Host Keytab' grants
write access to 'krbPrincipalKey' attribute but lacks any access to the
virtual attributes expected by the new extended operation.
There is a second virtual attribute, 'ipaProtectedOperation;read_keys',
that allows to retrieve existing keys for a host. However, during
initial enrollment we do not allow to retrieve and reuse existing
Kerberos key: while 'ipa-getkeytab -r' would give ability to retrieve
the existing key, 'ipa-join' has no way to trigger that operation.
Hence, permission 'System: Manage Host Keytab' will not grant the right
to read the Kerberos key via extended operation used by 'ipa-getkeytab
-r'. Such operation can be done later by utilizing 'ipa
service/host-allow-retrieve-keytab' commands.
Fix 'System: Manage Host Keytab' permission and extend a permission test
to see that we do not fallback to the old extended operation.
Fixes: https://pagure.io/freeipa/issue/9496
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
We want to avoid splitting a replica server installation between
two hosts where possible so if a CA or KRA is requested then
we only try to install against a remote server that also provides
those capabilities. This avoids race conditions.
If a CA or KRA is not requested and the user has provided a
server to install against then use that instead of overriding it.
Extend the logic of picking the remote Custodia mode
(KRA, CA, *MASTER*) to include considering whether the
CA and KRA services are requested. If the service(s) are
not requested the the associated hostname may not be
reliable.
Fixes: https://pagure.io/freeipa/issue/9491
Related: https://pagure.io/freeipa/issue/9289
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Up to PKI 11.5.0 even when a pki-server call failed it had a
return value of 0. This was fixed in 11.5.0 which breaks
ipa-acme-manage pruning. If a configuration value is not set
then the call fails and the tool gives up with an error like:
ERROR: No such parameter: jobsScheduler.job.pruning.certRetentionUnit
In previous versions this resulted in an empty string so the tool
displayed the default value.
So now upon failure look in the stderr output for "No such parameter"
and return an empty string so the behavior is consistent between
both old and new PKI server versions.
Fixes: https://pagure.io/freeipa/issue/9503
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
The referer was only checked in WSGIExecutioner classes:
- jsonserver
- KerberosWSGIExecutioner
- xmlserver
- jsonserver_kerb
This left /i18n_messages, /session/login_kerberos,
/session/login_x509, /session/login_password,
/session/change_password and /session/sync_token unprotected
against CSRF attacks.
CVE-2023-5455
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Fix the following errors:
I0021(useless-suppression)
R1710(inconsistent-return-statements)
E1101(no-member)
Ignore the following errors:
E0601(used-before-assignment)
The variable is imported when the code is run in_server.
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
hbactest does a number of internal searches, one of which
can exceed the configured sizelimit: hbacrule-find
Collect any messages returned from thsi call and display them
to the user on the cli.
Fixes: https://pagure.io/freeipa/issue/9486
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The command ipa group-add-member --external aduser@addomain.test
fails with an internal error when used with samba 4.19.
The command internally calls samba.security.dom_sid(sid) which
used to raise a TypeError but now raises a ValueError
(commit 9abdd67 on https://github.com/samba-team/samba).
IPA source code needs to handle properly both exception types.
Fixes: https://pagure.io/freeipa/issue/9466
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The subsystem.select is not a reliable indicator to determine
whether the CA is a renewal master since there is no process in
PKI to update the param when the role of the instance changes
(from master to clone and vice versa) so the param has been
removed in PKI 11.5.
Instead, it's better to use CAInstance.is_crlgen_enabled() since
CRL generation is only enabled in a renewal master.
Signed-off-by: Endi Sukma Dewata <edewata@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Currently LWCA is only supported in IPA since the key
replication depends on Custodia, so LWCA is not actually
supported in regular PKI installation. However, currently
the AuthorityMonitor is enabled by default and it executes
a persistent search to monitor LWCA replication so it is
wasting resources in non-IPA environment.
To reduce unnecessary resource consumption the LWCA monitor
will be disabled by default in PKI, so IPA will need to
enable it explicitly for new and existing installations.
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
This is a side-effect of adding the libpwquality options. It
imposes its own hardcoded minimum password length so some care
was needed to ensure that it isn't set too low.
So if there are no libpwquality options used then it's fine to
have no minlength in the policy.
Fixes: https://pagure.io/freeipa/issue/9297
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
The replica install was unilaterally removing KRB5CCNAME from
os.environ in some cases. Instead check first to see if it is
present and only remove in that case.
Fixes: https://pagure.io/freeipa/issue/9446
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
389DS supports BDB and LMDB backends. FreeIPA installation fails with
LMDB backend since it tries to apply tuning for BDB backend.
Instead, tuning for BDB should be applied only when 389DS uses BDB
backend.
Fixes: https://pagure.io/freeipa/issue/9435
Signed-off-by: Viktor Ashirov <vashirov@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Write a new krb5.conf in case any values changed finding the
right server to configure against (e.g. for CA, KRA) and
ensure the API connection is to the remote server that
will be installed against.
When finding a CA or KRA during initial replica installation
set the remote master as well. The order is:
- existing server value in /etc/ipa/default.conf
- the chosen CA host if the server doesn't provide one
- the chosen KRA host if the server doesn't provide one
This is more or less heirarchical. If a server is provided
then that is considered first. If it provides all the
optional services needed (CA and/or KRA) then it will
be used. Otherwise it will fall back to a server that provides
all the required services.
In short, providing --server either at client install or
with ipa-replica-install is no guarantee that it will
define all topology. This may be unexpected behavior.
For the case of adding a CA or KRA things are effectively
unchanged. This type of install does not appear to be
impacted by affinity issues.
Fixes: https://pagure.io/freeipa/issue/9289
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Clean up and remove obsolete code from ipa-replica-install. For several
versions replica installer first ensures that a host is an IPA client,
then promotes the client to a replica. The client installer code sets up
CA stores like IPA_CA_CRT already.
Related: https://pagure.io/freeipa/issue/9272
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
The ipaidpuser objectclass is required for the attribute ipaidpsub.
When a user is created or modified with --idp-user-id, the operation
must ensure that the objectclass is added if missing.
Add a test for user creation and user modification with --idp-user-id.
Fixes: https://pagure.io/freeipa/issue/9433
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The XML API is already deprecated and will be removed in some
future release.
All but the updateCRL API has an equivalent in REST. The upstream
dogtag project documents most of the API at
https://github.com/dogtagpki/pki/wiki/REST-API . I say most
because not every API includes sample input/output. The
pki ca-cert command is a good substitute for seeing how the API
is used by their own tooling.
This changes no pre-existing conventions. All serial numbers are
converted to decimal prior to transmission and are treated as
strings to avoid previous limitations with sizing (which would
have been exacerbated by random serial numbers).
Fixes: https://pagure.io/freeipa/issue/9345
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
An attempt to do this was already coded but the wrong
argument was used. It was passing in the location name and
not the map name so the map wouldn't be completely removed.
Include a test to verify that the map is gone after removing
it by calling automountlocation-tofiles which will fail if the
map wasn't properly removed.
Fixes: https://pagure.io/freeipa/issue/9397
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
ipa-server-guard reads a lock file in order to
check if the lock is still taken by comparing
the stored value, for instance:
expire = 20230810155452589311
with the current datetime.
The expire value needs to be timezone-aware in
order to be compared with "now" which is also tz aware.
Related: https://pagure.io/freeipa/issue/9425
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
ipa-cert-fix compares the current datetime with the
value obtained from a cert.not_valid_after.
With the fix for #9425, not_valid_after is timezone
aware and cannot be compared to a naive datetime.
Make the datetime "now" timezone aware.
Related: https://pagure.io/freeipa/issue/9425
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The following warning is displayed on a system running with Python 3.12:
-------------------
/usr/lib/python3.12/site-packages/ipalib/rpc.py:925: DeprecationWarning:
datetime.utcnow() is deprecated and scheduled for removal in a future
version. Use timezone-aware objects to represent datetimes in UTC:
datetime.now(datetime.UTC).
timestamp=datetime.datetime.utcnow())
-------------------
Fixes: https://pagure.io/freeipa/issue/9425
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
admin is required for trust operations
Note that testing for removing the last member is now
irrelevant because admin must always exist so the test
for it was removed, but the code check remains. It is done
after the protected member check.
Fixes: https://pagure.io/freeipa/issue/8878
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Use of 'ipa idp-add --provider' was supposed to allow override scope and
other IdP options. The defaults are provided by the IdP template and
were actually not overridden. Fix this.
Fixes: https://pagure.io/freeipa/issue/9421
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The user and stageuser commands return the following error
when the user is created/updated with a non existing idp:
$ ipa user-add testuser --first test --last user --idp dummy
ipa: ERROR: no such entry
The error is not descriptive enough and has been modified to
display instead:
$ ipa user-add testuser --first test --last user --idp dummy
ipa: ERROR: External IdP configuration dummy not found
Fixes: https://pagure.io/freeipa/issue/9416
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
A host uses Location (nshostlocation) as an optional hint where
a host may phsyically be located (e.g. Lab 2). This will result in
an attribute in the host entry like:
nshostlocation: Lab 2
A server uses location (ipalocation) to identify which DNS location
the server is part of (e.g. prague). This will result in an attribute
in the server entry like:
ipalocation: idnsname=prague,cn=locations,cn=etc,dc=example,dc=test
They are completely different animals.
https://pagure.io/freeipa/issue/9317
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
In order to know if ca/kra is installed locally, the code
is calling pki-server subsystem-show _subsystem_
and ensures that "Enabled: True" is in the output.
If a subsystem fails to start, the command returns
"Enabled: False" but it doesn't mean that the subsystem
is not installed, it just means that it is not active
right now.
Same output if the subsystem has been disabled with
pki-server subsystem-disable _subsystem_.
The correct way to check if a subsystem is installed is to
ensure that subsystem-show does not exit on error and
contains "Enabled: ", whatever the value.
Related: https://pagure.io/freeipa/issue/9330
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The uninstaller is stopping all the services before
calling pkidestroy to uninstall the CA.
With PKI 11.4+ this sequence fails as pkidestroy tries
to connect to PKI server in order to unregister from the
security domain. The error interrupts the full completion
of pkidestroy, is logged but doesn't make ipa uninstallation
fail.
The issue is that trying to re-install later on would fail because
pkidestroy did not completely uninstall the CA.
To avoid this, call pkidestroy before shutting down the services.
Also add an uninstall_check method that restarts IPA if it is
not running, and use pkidestroy --force to make sure that PKI
is uninstalled even if restart failed.
Fixes: https://pagure.io/freeipa/issue/9330
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The upgrade checks the replication agreements to ensure that
some attributes are excluded from replication. The agreements
are stored in entries like
cn=serverToreplica,cn=replica,cn=_suffix_,cn=mapping tree,cn=config
but those entries are managed by the replication topology plugin
and should not be updated directly. The consequence is that the update
of the attributes fails and ipa-server-update prints an error message:
Error caught updating nsDS5ReplicatedAttributeList: Server is unwilling
to perform: Entry and attributes are managed by topology plugin.No direct
modifications allowed.
Error caught updating nsDS5ReplicatedAttributeListTotal: Server is
unwilling to perform: Entry and attributes are managed by topology
plugin.No direct modifications allowed.
The upgrade continues but the replication is not excluding
passwordgraceusertime.
Instead of editing the agreements, perform the modifications on
the topology segments.
Fixes: https://pagure.io/freeipa/issue/9385
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
During the installation of IPA server, the installer adds a drop-in
file in /etc/systemd/system/pki-tomcatd@pki-tomcat.service.d/ipa.conf
that ensures the CA is reachable before the start command returns.
If the file is missing (for instance because the server was installed
with an old version before this drop-in was created), the upgrade
should add the file.
Fixes: https://pagure.io/freeipa/issue/9381
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
There are 2 possible methods to rename users and groups:
- either use ipa user|group-mod oldname --rename newname
- or use settattr:
ipa user-mod oldname --setattr uid=newname
ipa group-mod oldname --setattr cn=newname
The first method validates the new name but the second method
doesn't. Add a validation to make both methods consistent
Fixes: https://pagure.io/freeipa/issue/9396
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
cert-find is a rather complex beast because it not only
looks for certificates in the optional CA but within the
IPA LDAP database as well. It has a process to deduplicate
the certificates since any PKI issued certificates will
also be associated with an IPA record.
In order to obtain the data to deduplicate the certificates
the cert from LDAP must be parser for issuer and serial number.
ipaldap has automation to determine the datatype of an
attribute and will use the ipalib.x509 IPACertificate class to
decode a certificate automatically if you access
entry['usercertificate'].
The downside is that this is comparatively slow. Here is the
parse time in microseconds:
cryptography 0.0081
OpenSSL.crypto 0.2271
ipalib.x509 2.6814
Since only issuer and subject are required there is no need to
make the expensive IPACertificate call.
The IPACertificate parsing time is fine if you're parsing one
certificate but if the LDAP search returns a lot of certificates,
say in the thousands, then those microseconds add up quickly.
In testing it took ~17 seconds to parse 5k certificates (excluding
transmission overhead, etc).
cert-find when there are a lot of certificates has been
historically slow. It isn't related to the CA which returns
large sets (well, 5k anyway) in a second or two. It was the
LDAP comparision adding tens of seconds to the runtime.
When searching with the default sizelimit of 100 the time is
~10s without this patch. With it the time is 1.5s.
CLI times from before and after searching for all certs:
original:
-------------------------------
Number of entries returned 5038
-------------------------------
real 0m15.507s
user 0m0.828s
sys 0m0.241s
using cryptography:
real 0m4.037s
user 0m0.816s
sys 0m0.193s
Fixes: https://pagure.io/freeipa/issue/9331
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
This reverts commit 1f30cc6527.
The problem isn't with python-cryptography, it is with the
IPACertificate class which does way more work on a certificate
than is necessary in cert-find.
Related: https://pagure.io/freeipa/issue/9331
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
This reverts commit 191880bc9f.
The problem isn't with python-cryptography, it is with the
IPACertificate class which does way more work on a certificate
than is necessary in cert-find.
Related: https://pagure.io/freeipa/issue/9331
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Alexander Bokovoy
Rob Crittenden
Florence Blanc-Renaud
Francisco Trivino
Christian Heimes
Rafael Guterres Jeffman
Endi S. Dewata
Viktor Ashirov
Miro Hrončok