The IPA location system relies on DNS record priorities in order to give
higher precedence to servers from the same location. For Kerberos, this
is done by redirecting generic SRV records (e.g.
_kerberos._udp.[domain].) to location-aware records (e.g.
_kerberos._udp.[location]._locations.[domain].) using CNAMEs.
This commit applies the same logic for URI records. URI location-aware
record were created, but there were no redirection from generic URI
records. It was causing them to be ignored in practice.
Kerberos URI and TXT records have the same name: "_kerberos". However,
CNAME records cannot coexist with any other record type. To avoid this
conflict, the generic TXT realm record was replaced by location-aware
records, even if the content of these records is the same for all
locations.
Fixes: https://pagure.io/freeipa/issue/9257
Signed-off-by: Julien Rische <jrische@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
There are currently three sets of CA schema changes applied
in ipa-server-upgrade:
* addition of ACME schema
* addition of certificate profile schema
* addition of lightweight CA schema
None of these require a restart of the CA to be supported.
There is an issue in schema parsing such that it doesn't handle
X-ORIGIN properly. A difference is detected and a change applied
but no change is recorded in LDAP so every time upgrade is
run it thinks a CA restart is needed. The CA is not quick to
restart so avoiding one is best, particularly when the update is
run as part of an rpm transaction where a user with an itchy finger
may think things have hung and break out of it.
https://github.com/389ds/389-ds-base/issues/5366 was
filed to track this.
Related: https://pagure.io/freeipa/issue/9204
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
In the memory check failure message, add a hint to the administrator
that they can use the --skip-mem-check flag to skip the check.
Related: https://pagure.io/freeipa/issue/8404
Signed-off-by: Fraser Tweedale <frase@frase.id.au>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
PKI 10.10 unconditionally added an upgrade script for the AJP
connector which replaced the AJP secret regardless of tomcat
version. It replaced requiredSecret with secret. IPA expects
the attribute by version so this could make the secrets out of
date and/or have connectors with both secrets and different
values.
PKI commit e70373ab131aba810f318c1d917896392b49ff4b has since
been reverted but there may be servers with both secrets still.
On next IPA upgrade clean them up.
Also allow re-writing ipa-pki-proxy.conf in case the secret
changes to ensure they remain in sync.
Fixes: https://pagure.io/freeipa/issue/9176
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
nsds5replicaUpdateInProgress is defined in LDAP schema as a boolean.
Now that IPA API is able to properly map booleans to the python
bool type, this attribute is not a string any more and
comparisons can be done directly based on its real type.
The code in ipa-replica-install was reading nsds5replicaUpdateInProgress
and calling value.tolower() == 'true' but should now use
value == True instead.
Related: https://pagure.io/freeipa/issue/9171
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
In IPA framework we don't properly convert to Python bool type and just
return a string (TRUE or FALSE). This can be seen with many boolean
attributes, like
Bool('idnsallowdynupdate?',
cli_name='dynamic_update',
label=_('Dynamic update'),
doc=_('Allow dynamic updates.'),
attribute=True,
default=False,
autofill=True
),
in 'ipa dnszone-show':
> > > api.Command.dnszone_show('ipa.test')['result']['idnsallowdynupdate']
['TRUE']
This is because we don't have the reverse (from LDAP to Python) mapping
for the LDAP boolean OID 1.3.6.1.4.1.1466.115.121.1.7.
When Web UI asks for the entry, it gets back JSON output that contains
this 'TRUE' value:
"idnsallowdynupdate": [
"TRUE"
],
Add proper mapping from LDAP to Python bool type. With this, a simple
'checkbox' type can be used in Web UI instead of a complex radio-box
setup.
Note that when IPA API is asked to return raw values, 'TRUE' and 'FALSE'
still returned. These are the actual LDAP boolean attribute values. Care
needs to be done in tests:
- if output is from a command with --raw option, 'TRUE' or 'FALSE'
should be expected
- if output if from a normal (non-raw) command, True or False would be
returned
Fixes: https://pagure.io/freeipa/issue/9171
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The graceperiod plugin was only being enabled on new
installations. Enable also on upgrade.
Loading a new plugin requires a restart. Do so if a
new one is configured.
Fixes: https://pagure.io/freeipa/issue/1539
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Add support for bind grace limiting per
https://datatracker.ietf.org/doc/html/draft-behera-ldap-password-policy-06
389-ds provides for alternative naming than the draft, using those
instead: passwordGraceUserTime for pwdGraceUserTime and
passwordGraceLimit for pwdGraceLoginLimit.
passwordGraceLimit is a policy variable that an administrator
sets to determine the maximum number of LDAP binds allowed when
a password is marked as expired. This is suported for both the
global and per-group password policies.
passwordGraceUserTime is a count per-user of the number of binds.
When the passwordGraceUserTime exceeds the passwordGraceLimit then
all subsequent binds will be denied and an administrator will need
to reset the user password.
If passwordGraceLimit is less than 0 then grace limiting is disabled
and unlimited binds are allowed.
Grace login limitations only apply to entries with the objectclass
posixAccount or simplesecurityobject in order to limit this to
IPA users and system accounts.
Some basic support for the LDAP ppolicy control is enabled such that
if the ppolicy control is in the bind request then the number of
remaining grace binds will be returned with the request.
The passwordGraceUserTime attribute is reset to 0 upon a password
reset.
user-status has been extended to display the number of grace binds
which is stored centrally and not per-server.
Note that passwordGraceUserTime is an operational attribute.
https://pagure.io/freeipa/issue/1539
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Add the --subid option to client, server and replica installers.
This option allows to configure authselect with the sssd
profile + with-subid feature, in order to have SSSD setup as
a datasource for subid in /etc/nsswitch.conf.
The default behavior remains unchanged: without the option,
/etc/nsswitch.conf keeps the line subid: files
Fixes: https://pagure.io/freeipa/issue/9159
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
So that it prints out a valid command:
- replace "ipa-replica-manage del" by "ipa server-del" (only domain-level1 is now supported)
- the commands needs to be run on a working server, not on the host where ipa-replica-install failed
Fixes: https://pagure.io/freeipa/issue/9162
Reviewed-By: Michal Polovka <mpolovka@redhat.com>
KDC configuration in /var/kerberos/krb5kdc/kdc.conf is generated from
the template in install/share/kdc.conf.template. Master key encryption
type specified there is used to bootstrap the master key in LDAP
database. Once it is done, actual deployment does not rely on the
master_key_type value anymore. The actual master key(s) get loaded from
LDAP database where they stored in a BER-encoded format, preserving all
parameters, including encryption type.
This means we can safely migrate to AES256-SHA2 as the default master
key encryption type for new installations. Replicas will get their
master key encryption type details from the server they were provisioned
from.
MIT Kerberos supports AES256-SHA2 since 1.15 (2015), meaning RHEL 7.4 is
the earliest supported version as it provides krb5 1.15.1. Current
supported RHEL 7 version is RHEL 7.9. Since RHEL 6 already cannot be
used as a replica to IPA 4.5+ due to a domain level 1 upgrade, this
change does not affect old releases.
Migration from the previously deployed master key encryption type is
described by MIT Kerberos upstream in
http://web.mit.edu/kerberos/krb5-latest/doc/admin/advanced/retiring-des.html#the-database-master-key
One would need to use '-x ipa-setup-override-restrictions' to allow
the `kdb5_util` utility to modify the data over IPA KDB driver.
Fixes: https://pagure.io/freeipa/issue/9119
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Francisco Trivino <ftrivino@redhat.com>
Pylint 2.11.0 extends consider-using-in check to work for
attribute access.
> To check if a variable is equal to one of many values,combine the
values into a tuple and check if the variable is contained "in" it
instead of checking for equality against each of the values.This
is faster and less verbose.
Fixes: https://pagure.io/freeipa/issue/9117
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Pylint 2.9.0 introduced new checker which was a subset of
arguments-differ:
> Used when a method parameter has a different name than in the
implemented interface or in an overridden method.
Fixes: https://pagure.io/freeipa/issue/9117
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Pylint 2.9 introduced new check:
> New checker consider-using-dict-items. Emitted when iterating over
dictionary keys and then indexing the same dictionary with the key
within loop body.
Fixes: https://pagure.io/freeipa/issue/9117
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
__remove_lightweight_ca_key_retrieval_custodia has been added in
8700101d9, but it was never used.
Caught by Pylint:
```
ipaserver/install/cainstance.py:1308: [W0238(unused-private-member),
CAInstance.__remove_lightweight_ca_key_retrieval_custodia]
Unused private member
`CAInstance.__remove_lightweight_ca_key_retrieval_custodia(self)`)
```
Fixes: https://pagure.io/freeipa/issue/9117
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
__convert_to_gssapi_replication has been added in a0bfbec19 and
then removed in ce2bb47cc without clean up.
Found by Pylint:
```
ipaserver/install/krbinstance.py:589: [W0238(unused-private-member),
KrbInstance.__convert_to_gssapi_replication] Unused private member
`KrbInstance.__convert_to_gssapi_replication(self)`)
```
Fixes: https://pagure.io/freeipa/issue/9117
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
RHEL 9 system-wide crypto policies aim at eventual removal of SHA-1 use.
Due to bootstrapping process, force explicitly supported encryption
types in kdc.conf or we may end up with AES128-SHA1 and AES256-SHA2 only
in FIPS mode at bootstrap time which then fails to initialize kadmin
principals requiring use of AES256-SHA2 and AES128-SHA2.
Camellia ciphers must be filtered out in FIPS mode, we do that already
in the kerberos.ldif.
At this point we are not changing the master key encryption type to
AES256-SHA2 because upgrading existing deployments is complicated and
at the time when a replica configuration is deployed, we don't know what
is the encryption type of the master key of the original server as well.
Fixes: https://pagure.io/freeipa/issue/9119
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Julien Rische <jrische@redhat.com>
Reviewed-By: Francisco Trivino <ftrivino@redhat.com>
The example text included a trailing dot which isn't actually
allowed in a system hostname (just DNS). Remove the suggestion
to include it and strip off any trailing dot so that the install
can proceed.
Related: https://pagure.io/freeipa/issue/9111
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The refactor change 9094dfc had a slight error where the
user-input provided value in input wasn't being validated. Only
the command-line or the current FQDN was being verified so
if the FQDN was bad any value input by the user was being skipped.
Fixes: https://pagure.io/freeipa/issue/9111
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
There is no use-case to keep a restored server in a hidden
state. It can be re-marked as hidden once the installation is
recovered from the restore. So mark all restored services as
enabled so they are visible to existing clients during the
remaining recovery.
Fixes: https://pagure.io/freeipa/issue/9095
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
The timer was only being enabled during package installation
if IPA was configured. So effectively only on upgrade.
Add as a separate installation step after the ccache directory
is configured.
Fixes: https://pagure.io/freeipa/issue/9107
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
pylint 2.9 thinks that __add_principal is a class-level method that is
unused. It is a local function inside one of class methods and is used
directly inside that method.
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
OpenLDAP 2.6+ finally deprecated -h and -p options in all its command
line tools. They are not allowed anymore and cause ldap* tools to stop
hard with 'unknown option' error.
Fix this by always using -H url option instead. Deriving default value
for -H url from the configuration file still works, it is only -h and -p
that were deprecated.
See also: https://bugs.openldap.org/show_bug.cgi?id=8618
Fixes: https://pagure.io/freeipa/issue/9106
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
I can only guess to the original purpose of this override. I
believe it was because this is called in the installer prior
to Apache being set up. The expectation was that this would
only be called locally. It predates the RestClient class.
RestClient will attempt to find an available service. In this
case, during a CA installation, the local server is not
considered available because it lacks an entry in
cn=masters. So it will never be returned as an option.
So by overriding the port to 8443 the remote connection will
likely fail because we don't require that the port be open.
So instead, instantiate a RestClient and see what happens.
There are several use-cases:
1. Installing an initial server. The RestClient connection
should fail, so we will fall back to the override port and
use the local server. If Apache happens to be running with
a globally-issued certificate then the RestClient will
succeed. In this case if the connected host and the local
hostname are the same, override in that case as well.
2. Installing as a replica. In this case the local server should
be ignored in all cases and a remote CA will be picked with
no override done.
3. Switching from CA-less to CA-ful. The web server will be
trusted but the RestClient login will fail with a 404. Fall
back to the override port in this case.
The motivation for this is trying to install an EL 8.x replica
against an EL 7.9 server. 8.5+ includes the ACME service and
a new profile is needed which doesn't exist in 7. This was
failing because the RestClient determined that the local server
wasn't running a CA so tried the remote one (7.9) on the override
port 8443. Since this port isn't open: failure.
Chances are that adding the profile is still going to fail
because again, 7.9 lacks ACME capabilities, but it will fail in
a way that allows the installation to continue.
I suspect that all of the overrides can similarly handled, or
handled directly within the RestClient class, but for the sake
of "do no harm" I'm only changing this instance for now.
https://pagure.io/freeipa/issue/9100
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
As a part of CVE-2020-25717 mitigations, Samba now assumes 'CLASSIC
PRIMARY DOMAIN CONTROLLER' server role does not support Kerberos
operations. This is the role that IPA domain controller was using for
its hybrid NT4/AD-like operation.
Instead, 'IPA PRIMARY DOMAIN CONTROLLER' server role was introduced in
Samba. Switch to this role for new installations and during the upgrade
of servers running ADTRUST role.
Fixes: https://pagure.io/freeipa/issue/9031
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Add new options to ipa config-mod, allowing to enable
SID generation on upgraded servers:
ipa config-mod --enable-sid --add-sids --netbios-name NAME
The new option uses Dbus to launch an oddjob command,
org.freeipa.server.config-enable-sid
that runs the installation steps related to SID generation.
--add-sids is optional and triggers the sid generation task that
populates SID for existing users / groups.
--netbios-name is optional and allows to specify the NetBIOS Name.
When not provided, the NetBIOS name is generated based on the leading
component of the DNS domain name.
This command can be run multiple times.
Fixes: https://pagure.io/freeipa/issue/8995
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
ADTRUSTInstance performs only sid configuration when it is
called without --setup-adtrust.
Update man pages for ipa-server-install and ipa-replica-install
with the SID-related options.
Related: https://pagure.io/freeipa/issue/8995
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Move the SID-related options into a separate InstallInterface
(--add-sids, --netbios-name, --rid-base and --secondary-rid-base),
make ADTrustInstallInterface inherit from SIDInstallInterface.
Related: https://pagure.io/freeipa/issue/8995
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
ipa-server-install uninstaller must remove samba *.tdb files
in /var/lib/samba, /var/lib/samba/private and /var/lib/samba/lock.
The current code calls rm on the relative path filename
instead of building an absolute path filename,
resulting in failure to remove the tdb files.
Related: https://pagure.io/freeipa/issue/8687
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
There are time gaps in which kinit requests may fail due to
offlined SSSD's locator and replication delays.
Since `IPA` provider or SSSD offline the locator plugin for libkrb5
(man 8 sssd_krb5_locator_plugin) can do nothing about this and kinit
fallbacks to the standard libkrb5 algorithm described in `man 5 krb5.conf`.
`krb5.conf` on IPA server doesn't include `kpasswd_server` and kinit
fallbacks to DNS way. DNS (URI or SRV) RRs don't preserve any order
and kinit may contact either master or replica kpasswd servers.
This may result in a password was changed on a replica but was not
replicated to master:
master(kinit)->master(initial)->replica(kpasswd)->master(can't
obtain initial creds with new password)
So, `kpasswd_server` serves as fallback for the offlined locator.
Note: primary_kdc(the former master_kdc) doesn't help here because
it is only used if the initial credentials obtaining fails (see
`krb5_get_init_creds_password` in libkrb5) and not a password change.
Fixes: https://pagure.io/freeipa/issue/8353
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Rather than stopping the installer entirely, catch and report
errors adding new certificate profiles, and remove the
broken profile entry from LDAP so it may be re-added later.
It was discovered that installing a newer IPA that has the
ACME profile which requires sanToCNDefault will fail when
installing a new server against a very old one that lacks
this class.
Running ipa-server-upgrade post-install will add the profile
and generate the missing ipa-ca SAN record so that ACME
can work.
https://pagure.io/freeipa/issue/8974
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
The DogtagInstance.spawn_instance() and uninstall() have
been modified to specify the paths of PKI installation
logs using --log-file option on PKI 11.0.0 or later.
This allows IPA to have a full control over the log files
instead of relying on PKI's default log files.
Fixes: https://pagure.io/freeipa/issue/8966
Signed-off-by: Endi Sukma Dewata <edewata@redhat.com>
PKI has its own internal knowledge of servers and services
in its securitydomain. This has not been cleaned up in the
past but is becoming more of an issue as PKI now relies on its
securitydomain for more things, and it has a healthcheck that
reports inconsistencies.
Removing entries is straightforward using the PKI REST API.
In order to operate on the API access is needed. There was an
unused Security Domain Administrators group that I've added to
the resourceACLS we created for managing the securitydomain.
The ipara user is added as a member of this group. The REST
API binds to the CA using the IPA RA certificate.
Related commits are b3c2197b7e
and ba4df6449a.
These resourceACLS were originally created as a backwards
compatibility mechanism for dogtag v9 and later only created when a
replica was installed purportedly to save a restart. I don't see
any reason to not have these defined. They are apparently needed due
to the PKI database upgrade issues.
In any case if the purpose was to suppress these ACLS it failed
because as soon as a replica with a CA was installed they were as
well, and we need this ACL in order to manage the securitydomain.
https://pagure.io/freeipa/issue/8930
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
KRA instance import depends on lib389 package, which is not always
installed and that results in failure. Furthermore, test_installation
utilizes krainstance import. This fix moves relevant parts from
krainstance to ipalib constants where those are subsequently imported
from.
Related: https://pagure.io/freeipa/issue/8795
Signed-off-by: Michal Polovka <mpolovka@redhat.com>
Reviewed-By: Michal Polovka <mpolovka@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Tibor Dudlak <tdudlak@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Subordinate ids are now handled by a new plugin class and stored in
separate entries in the cn=subids,cn=accounts subtree.
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
New LDAP object class "ipaUserSubordinate" with four new fields:
- ipasubuidnumber / ipasubuidcount
- ipasubgidnumber / ipasgbuidcount
New self-service permission to add subids.
New command user-auto-subid to auto-assign subid
The code hard-codes counts to 65536, sets subgid equal to subuid, and
does not allow removal of subids. There is also a hack that emulates a
DNA plugin with step interval 65536 for testing.
Work around problem with older SSSD clients that fail with unknown
idrange type "ipa-local-subid", see: https://github.com/SSSD/sssd/issues/5571
Related: https://pagure.io/freeipa/issue/8361
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
It required support in dogtag which was added in 10.5.0.
This is only easily configurable during installation because
it will set ca.signing.defaultSigningAlgorithm to the
selected algorithm in CS.cfg
The certificate profiles will generally by default set
default.params.signingAlg=- which means use the CA default.
So while an existing installation will technically allow
SHA384withRSA it will require profile changes and/or
changing the defaultSigningAlgorithm in CS.cfg and
restarting (completely untested). And that won't affect
already issued-certificates.
https://pagure.io/freeipa/issue/8906
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Julien Rische
Rob Crittenden
Florence Blanc-Renaud
Fraser Tweedale
Alexander Bokovoy
Francisco Trivino
Stanislav Levin
Endi S. Dewata
Christian HeimesandFrançois Cami
Antonio Torres
Michal Polovka