The default ID generators used by PKI might change in the
future, so to preserve the current behavior the installation
code has been updated to explicitly use the legacy ID
generators by default.
Signed-off-by: Endi S. Dewata <edewata@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@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>
__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>
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>
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>
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 <flo@redhat.com>
Since commit 1906afbeb3c8b7140601be7f9bee2f7fef5b0a5e, in order to fix
rhbz#1780082, pki defines AJP connectors using localhost4 and localhost6:
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" address="localhost4" name="Connector1" secret="..."/>
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" address="localhost6" name="Connector2" secret="..."/>
When /etc/hosts only defines the following:
127.0.0.1 localhost
::1 localhost
the connector initialization may fail with
java.net.BindException: Address already in use
The installer can add the following definitions to pkispawn cfg file:
pki_ajp_host_ipv4=127.0.0.1
pki_ajp_host_ipv6=::1
in order to force the value to an IP address instead of localhost4/6.
Fixes: https://pagure.io/freeipa/issue/8851
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
In order to call import_included_profiles the dogtag RA plugin
needs to have been loaded. Modify the requirements to also allow
the installer context along with the ra_plugin value.
This lets us add missing profiles during a replica installation.
This is needed for ACME when installing a new replica in a
cluster of older servers that don't have support for ACME.
https://pagure.io/freeipa/issue/8738
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
If the CA fails to deploy then the CRL directory will not exist
but will report an error that it has failed to be removed.
There is no need to try to navigate a directory if it doesn't exist.
Related: https://pagure.io/freeipa/issue/8565
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
This option was inconsistent between invocations and there is
no need to stop certmonger after stopping tracking. It was also
apparently causing dbus timeout errors, probably due to the amount
of work that certmonger does at startup.
https://pagure.io/freeipa/issue/8506https://pagure.io/freeipa/issue/8533
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
From the upgrade log it was not possible to see the current
state of ACME which makes troubleshooting difficult.
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Related: https://pagure.io/freeipa/issue/8712
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Put the ACME config files under normal IPA versioning so we
can more seamlessly do updates to them.
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
https://pagure.io/freeipa/issue/8712
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
This is an informational message and clutters the installation
screen with no end-user benefit. Logging it as debug is
sufficient to know what is going on.
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
This reverts commit 81c97bb992.
This is to make IPA installable again with older versions of dogtag
so it will install on CentOS 8 Stream.
ACME will not be deployed but on upgrade, if pki 10.10.x is available
then it will be.
https://pagure.io/freeipa/issue/8634
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Python code does detection of the system encoding based on the locale
settings. On RHEL 8.4 development images we somehow get LANG=en_US which
defaults to iso8859-1 _inside_ the systemd-started service, even though
the whole environment defaults to LANG=en_US.UTF-8.
When instrumented with ExecStartPre=/usr/bin/locale, the following
output can be seen:
locale[45481]: LANG=en_US
locale[45481]: LC_CTYPE="en_US"
locale[45481]: LC_NUMERIC="en_US"
locale[45481]: LC_TIME="en_US"
locale[45481]: LC_COLLATE="en_US"
locale[45481]: LC_MONETARY="en_US"
locale[45481]: LC_MESSAGES="en_US"
locale[45481]: LC_PAPER="en_US"
locale[45481]: LC_NAME="en_US"
locale[45481]: LC_ADDRESS="en_US"
locale[45481]: LC_TELEPHONE="en_US"
locale[45481]: LC_MEASUREMENT="en_US"
locale[45481]: LC_IDENTIFICATION="en_US"
locale[45481]: LC_ALL=
ipactl[45483]: Unexpected error
ipactl[45483]: SystemEncodingError: System encoding must be UTF-8, 'iso8859-1' is not supported. Set LC_ALL="C.UTF-8", or LC_ALL="" and LC_CTYPE="C.UTF-8".
systemd[1]: ipa.service: Main process exited, code=exited, status=1/FAILURE
Set the environment to explicit LC_ALL=C.UTF-8 to please the Python
code. FreeIPA server side only cares about actual encoding, not the
language itself. We already use LC_ALL=C.UTF-8 in httpd service snippet.
Fixes: https://pagure.io/freeipa/issue/8617
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
On upgrading a server without ACME to one with ACME
the RA Agent DN needs to be added as a member of the
ACME Enterprise Users group. This was previously
done as part of the creation of that entry.
So on upgrade the RA Agent wouldn't be a member so
ipa-acme-manage didn't have access to operate against
the CA REST API.
In order to add the RA Agent to this group during installation
the ACME provisioning has to come after that step so it is
moved from the middle of an installation to the end and
the group addition moved into the setup_acme() method.
https://pagure.io/freeipa/issue/8603
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Mohammad Rizwan Yusuf <myusuf@redhat.com>
This method was added temporarily while the required packages
were still under development and not available in stable
repositories.
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Mohammad Rizwan Yusuf <myusuf@redhat.com>
ACME requires an ipa-ca SAN to have a fixed URL to connect to.
If the Apache certificate is replaced by a 3rd party cert then
it must provide this SAN otherwise it will break ACME.
https://pagure.io/freeipa/issue/8498
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
New validation efforts in 389-ds-base require that the backend entry for
a database be created before the mapping tree entry. This enforces that
the mapping tree entry (the suffix) actually belongs to an existing backend.
For IPA we simply need to reverse the order of the backend vs mapping tree
creation in cainstance.py -> __create_ds_db()
Fixes: https://pagure.io/freeipa/issue/8558
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The initial ACME support required that each server individually
enable/disable the service. PKI 10.10.0 stores this state in LDAP
so global enable/disable is available and the IPA code relies on
this.
Parse the VERSION file shipped with PKI to determine the version.
https://pagure.io/freeipa/issue/8524
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
cainstance and krainstance now reuse the main LDAP connection
api.Backend.ldap2 in all helper functions. Some functions used to create
and tear down their own LDAP connection. This was a remnant of the old
CA LDAP instance in FreeIPA 3.x.
Related: https://pagure.io/freeipa/issue/8521
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The ra_certprofile API is slow. It takes ~200ms to migrate and enable a
profile even when the profile already available. The migration step
slows down the installer and upgrader by about 12 to 15 seconds.
Skip all profiles that have been imported by Dogtag already.
Related: https://pagure.io/freeipa/issue/8522
Related: https://pagure.io/freeipa/issue/8521
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Move several steps to an earlier phase of CA spawn. RA and ACME agent
ACLs are now configured while the server is down. This avoids yet
another restart and saves between 11 and 50 seconds per installation.
Related: https://pagure.io/freeipa/issue/8521
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The step set_audit_renewal modifies Dogtag's caSignedLogCert.cfg to bump
renewal to 2 years. The problem was fixed in Dogtag upstream in 2012 before
Dogtag 10.0 came out, see
f5b8ea5b08
The update step would also no longer work. Profiles have been migrated
to LDAP several FreeIPA releases ago. pkispawn populates LDAP with all
of Dogtag's default profiles. FreeIPA does not overwrite any existing
profiles.
Related: https://pagure.io/freeipa/issue/8521
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
New classes for user and group names provide a convenient way to access
the uid and primary gid of a user / gid of a group. The classes also
provide chown() and chgrp() methods to simplify common operations.
The wrappers are subclasses of builtin str type and behave like ordinary
strings with additional features. The pwd and grp structs are retrieved
once and then cached.
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
- drop unused dm_password and ldapi arguments
- remove online feature that was never implemented
- allow passing of api object that is used to populate substitution
dictionary
- simplify substitution dictionary updates
- remove unused instances vars
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The new _ldap_update() helper methods makes it easier to apply LDAP
update files from a service instance.
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
After upgrading a deployment from CA-less to CA-ful it is necessary
to install the RA Agent credential on non-CA servers. To facilitate
this, extract this behaviour from CAInstance so that it is callable
from other code.
Several other methods became @staticmethod as a result of this
change. This makes those methods callable without an instance of
CAInstance and also documents that those methods do not use 'self'.
Part of: https://pagure.io/freeipa/issue/7188
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Enhance cainstance.update_ipa_conf() to allow specifying the
ca_host. This will be used to update replica configurations when a
CA-less deployment gets promoted to CA-ful.
Part of: https://pagure.io/freeipa/issue/7188
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
For each CA server, a Dogtag user account is created for the ACME
service to use to authenticate to the CA subsystem. This commit
cleans up the Dogtag account upon server uninstallation.
The user deletion behaviour is extracted to a common method used for
both ACME RA account deletion (on uninstall) and removal of the
temporary admin account (during replica install).
Part of: https://pagure.io/freeipa/issue/4751
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
When deploying ACME set up configsources.conf to retrieve engine
configuration from engine.conf. In the initial configuration, the
ACME service is disabled (i.e. it will refuse to service requests).
A subsequent commit will add command(s) for flipping the ACME
service on or off (on a per-server basis). Later we will move to
LDAP configuration so that management of the ACME service is
deployment-wide.
The default configuration also disables issuance of wildcard
certificates.
Part of: https://pagure.io/freeipa/issue/4751
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Add a default certificate profile to be used with the ACME service.
The profile requires the (Dogtag) user interacting with the CA to be
a member of the (Dogtag) "ACME Agents" group. For each CA server we
create a dedicated ACME agent account, make it a member of this
group, and configure the ACME issuer component to use that account.
Part of: https://pagure.io/freeipa/issue/4751
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Add an ACL to allow ACME agents to revoke certificates. Although
the operation "execute" sounds quite scary (as though it would have
a wide scope), in fact it only allows revocation (and unrevocation).
See CertResource.java and base/ca/shared/conf/acl.properties in the
Dogtag source.
Part of: https://pagure.io/freeipa/issue/4751
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The ACME certificate profile will require the (Dogtag) user
interacting with the CA to be a member of the (Dogtag) "ACME Agents"
group. Therefore for each CA server, as part of the ACME setup
routine create a dedicated ACME agent account and make it a member
of this group.
Part of: https://pagure.io/freeipa/issue/4751
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
When configuring the CA, create, configure and deploy the PKI ACME
service instance. This includes creation (if necessary) of the LDAP
container object heirarchy in which ACME-related objects will be
stored.
Dogtag ACME RA account management will be added in a subsequent
commit, removing the use of the 'uid=admin' account (which as of
this commit just has a bogus password).
Part of: https://pagure.io/freeipa/issue/4751
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
PKIConnection now defaults to specifying verify=True. We've introduced
a new parameter, cert_paths, to specify additional paths (directories or
files) to load as certificates. Specify the IPA CA certificate file so
we can guarantee connections succeed and validate the peer's certificate.
Point to IPA CA certificate during pkispawn
Bump pki_version to 10.9.0-0.4 (aka -b2)
Fixes: https://pagure.io/freeipa/issue/8379
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1849155
Related: https://github.com/dogtagpki/pki/pull/443
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1426572
Signed-off-by: Alexander Scheel <ascheel@redhat.com>
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
A failed ipa-ca-install left my installation in an inconsistent
state. Then, 'ipa-server-install --uninstall' also failed when
is_crlgen_enabled() tried to read ipa-pki-proxy.conf, which was
missing.
Update is_crlgen_enabled() to handle missing ipa-pki-proxy.conf, by
raising InconsistentCRLGenConfigException instead of RuntimeError.
As a result, missing ipa-pki-proxy.conf is handled gracefully
because the calling code already catches
InconsistentCRLGenConfigException.
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
During upgrade, if discrepancies are detected in Certmonger tracking
request configuration we remove and re-create tracking requests.
The default behaviour of the CAInstance and KRAInstance
stop_tracking_certificates() method is to stop certmonger after the
requests have been removed. This behaviour results in an
unnecessary restart of certmonger and has also been observed to
cause problems. For example, subsequent certmonger operations have
to start the certmonger process and can fail because certmonger is
not yet properly initialised (manifesting as D-Bus errors).
Suppress the unnecessary restart(s) of certmonger during tracking
request update.
Related: https://pagure.io/freeipa/issue/8186
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
AJP implementation in Tomcat is vulnerable to CVE-2020-1938 if used
without shared secret. Set up a shared secret between localhost
connector and Apache mod_proxy_ajp pass-through.
For existing secured AJP pass-through make sure the option used for
configuration on the tomcat side is up to date. Tomcat 9.0.31.0
deprecated 'requiredSecret' option name in favor of 'secret'. Details
can be found at https://tomcat.apache.org/migration-9.html#Upgrading_9.0.x
Fixes: https://pagure.io/freeipa/issue/8221
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Commit 49cf5ec64b fixed a bug that
prevented migration from externally-signed to self-signed IPA CA.
But it introduced a subtle new issue: certmonger-initiated renewal
renews an externally-signed IPA CA as a self-signed CA.
To resolve this issue, introduce the `--force-self-signed' flag for
the dogtag-ipa-ca-renew-agent script. Add another certmonger CA
definition that calls this script with the `--force-self-signed'
flag. Update dogtag-ipa-ca-renew-agent to only issue a self-signed
CA certificate if the existing certificate is self-signed or if
`--force-self-signed' was given. Update `ipa-cacert-manage renew'
to supply `--force-self-signed' when appropriate.
As a result of these changes, certmonger-initiated renewal of an
externally-signed IPA CA certificate will not issue a self-signed
certificate.
Fixes: https://pagure.io/freeipa/issue/8176
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Dogtag had only one switch, ca.publish.enable, for both CRLs and certs.
Since cert publishing is not used in IPA it should be disabled to
avoid false positives in the logs.
https://pagure.io/freeipa/issue/7522
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The variable is intended to control the timeout for replication
events. If someone had significantly reduced it via configuration
then it could have caused certmogner requests to fail due to timeouts.
Add replication_wait_timeout, certmonger_wait_timeout and
http_timeout to the default.conf man page.
Related: https://pagure.io/freeipa/issue/7971
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The HSM state is stored in fstore, so that CA and KRA installer use the
correct token names for internal certificates. The default token is
"internal", meaning the keys are stored in a NSSDB as usual.
Related: https://pagure.io/freeipa/issue/5608
Co-authored-by: Magnus K Karlsson <magnus-ka.karlsson@polisen.se>
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
The CA_BACKUP_KEYS_P12 file is not enabled when pki_backup_keys is
set to False. It's the case when FreeIPA is configured with HSM support.
Related: https://pagure.io/freeipa/issue/7677
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Replace renewal CA and profile name literals with corresponding
symbols from ipalib.constants.
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Profile-based renewal means we should always explicitly specify the
profile in tracking requests that use the dogtag-ipa-ca-renew-agent
renewal helper. This includes the IPA RA agent certificate. Update
CAInstance.configure_agent_renewal() to add the profile to the
tracking request. This also covers the upgrade scenario (because
the same method gets invoked).
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The Dogtag "Server-Cert cert-pki-ca" certificate is treated
specially, with its own track_servercert() method and other special
casing. But there is no real need for this - the only (potential)
difference is the token name. Account for the token name difference
with a lookup method and treat all Dogtag system certs equally
w.r.t. tracking request creation and removal.
Part of: https://pagure.io/freeipa/issue/7991
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
