mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2025-02-25 18:55:28 -06:00
Dogtag has implemented a new random serial number scheme they are calling RSNv3. https://github.com/dogtagpki/pki/wiki/Random-Certificate-Serial-Numbers-v3 Given the known issues reported this will be supported in IPA for new installations only. There is no mixing of random servers and non-random servers allowed. Instructions for installing a CA: https://github.com/dogtagpki/pki/blob/master/docs/installation/ca/Installing-CA-with-Random-Serial-Numbers-v3.adoc Instructions for installing a KRA: https://github.com/dogtagpki/pki/blob/master/docs/installation/kra/Installig-KRA-with-Random-Serial-Numbers-v3.adoc The version of random serial numbers is stored within the CA entry of the server. It is stored as a version to allow for future upgrades. If a CA has RSN enabled then any KRA installed will also have it enabled for its identifiers. A new attribute, ipaCaRandomSerialNumberVersion, is added to the IPA CA entry to track the version number in case PKI has future major revisions. This can also be used to determine if RSN is enabled or not. Fixes: https://pagure.io/freeipa/issue/2016 Signed-off-by: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Florence Blanc-Renaud <flo@redhat.com> Reviewed-By: Francisco Trivino <ftrivino@redhat.com> Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com> |
||
---|---|---|
.. | ||
certmonger | ||
custodia | ||
html | ||
migration | ||
oddjob | ||
restart_scripts | ||
share | ||
tools | ||
ui | ||
updates | ||
wsgi | ||
Makefile.am | ||
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.