IntenseWebs/freeipa
3
0
Fork 0
mirror of https://salsa.debian.org/freeipa-team/freeipa.git synced 2024-12-25 08:21:05 -06:00
Code Issues Packages Projects Releases Wiki Activity
ff10f3fa18
freeipa/install
History
Fraser Tweedale 769180c2c6 Do not renew externally-signed CA as self-signed 
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>
2020-01-29 21:47:14 +11:00
..
certmonger Do not renew externally-signed CA as self-signed 2020-01-29 21:47:14 +11:00
custodia Replace PYTHONSHEBANG with valid shebang 2019-06-24 09:35:57 +02:00
html Fix javascript 'errors' found by jslint 2018-09-27 16:33:25 +02:00
migration Use new LDAPClient constructors 2019-02-05 08:39:13 -05:00
oddjob trust-fetch-domains: make sure we use right KDC when --server is specified 2019-06-28 13:30:59 +02:00
restart_scripts Don't create log files from help scripts 2019-09-24 15:23:30 +02:00
share Add Authentication Indicator Kerberos ticket policy options 2019-11-21 11:13:12 -05:00
tools Add delete option to ipa-cacert-manage to remove CA certificates 2020-01-28 13:05:31 -05:00
ui WebUI: Fix notification area layout 2019-11-21 16:44:11 +01:00
updates trust upgrade: ensure that host is member of adtrust agents 2019-12-04 09:06:56 +01:00
wsgi Add absolute_import future imports 2018-04-20 09:43:37 +02:00
Makefile.am Move Custodia secrets handler to scripts 2019-04-26 12:09:22 +02:00
README.schema Add some basic rules for adding new schema 2010-08-27 13:40:37 -04:00

README.schema 

Ground rules on adding new schema

Brand new schema, particularly when written specifically for IPA, should be
added in share/*.ldif. Any new files need to be explicitly loaded in
ipaserver/install/dsinstance.py. These simply get copied directly into
the new instance schema directory.

Existing schema (e.g. in an LDAP draft) may either be added as a separate
ldif in share or as an update in the updates directory. The advantage of
adding the schema as an update is if 389-ds ever adds the schema then the
installation won't fail due to existing schema failing to load during
bootstrap.

If the new schema requires a new container then this should be added
to install/bootstrap-template.ldif.