#4002 IPA should own its certificate profile
Closed: Fixed None Opened 10 years ago by mkosek.

Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 916289

Description of problem:

For some reason when we initially added support for pki-core we adding the
certificate profile to the pki-ca package.

This has been problematic for both sides, forcing a new release of pki-core
whenever IPA needs an update.

We should coordinate moving ownership of this from the pki-core package to the
ipa package.

Moving unfinished November tickets to January.

This might be a good target for Fraser to look on when dealing with certificate profiles & IPA.

There are two profiles that seem to be IPA-related:

IPA-RA Agent-Authenticated Server Certificate Enrollment

  • This certificate profile is for enrolling server certificates with IPA-RA agent authentication.
  • caIPAserviceCert.cfg

Manual Jar Signing Certificate Enrollment

  • This is an IPA profile for enrolling Jar Signing certificates.
  • caJarSigningCert.cfg

Are both of these in scope to be moved to IPA or just the former?

I am not sure that either is related...

The second profile is related (grep for IPA_SERVICE_PROFILE) and should be owned by FreeIPA as it is really just IPA specific and does not have value for pki-core.

As for the first one, I personally do not think it should be owned by FreeIPA, we just use it to generate one cert. It is true we update it though:

    def __setup_sign_profile(self):
        # Tell the profile to automatically issue certs for RAs
        installutils.set_directive(self.dogtag_constants.SIGN_PROFILE,
                'auth.instance_id', 'raCertAuth', quotes=False, separator='=')

but I do not see that as a reason for FreeIPA to own it.

IMO it makes a lot of sense to carry out this change out after or alongside https://fedorahosted.org/pki/ticket/778.

In moving to a system directory for profiles, non-pki packages could install additional profiles into
the system directory, or rather, in a subdirectory thereof, because using subdirectories will simplify the coordination of this change and make it easy to distinguish profiles from pki itself versus profiles from FreeIPA (or other software). Consider the following sequence:

  1. Dogtag system profile directory implemented. Looks for certificates in /usr/share/pki/profiles/, then subdirectories /usr/share/pki/profiles/*. caIPAserviceCert.profile lives in /usr/share/pki/profiles/

  2. FreeIPA updated to install caIPAserviceCert.profile in /usr/share/pki/profiles/freeipa/. Dogtag continues seeing the version from the parent directory, for the time being. Future IPA-specific profiles also get installed to the subdirectory.

  3. Remove /usr/share/pki/profiles/caIPAserviceCert.profile from pki packages. Dogtag now sees the version installed by freeipa, and freeipa can update its profile(s) without touching pki packages.

What do people think?

I do not see these changes as strictly depending on each other. We can make CA profile owned by FreeIPA immediately and place it into standard Dogtag profile directory. When 778 is implemented, we would just move it, no big effort.

My point is that I would not wait with FreeIPA change for too long, if 778 would not be done any time soon. But if 778 is happening soon then sure, good idea.

May be I am missing something but shouldn't the profiles be replicated and thus stored in LDAP?

Should they? This is news to me. If this is the case and moving to LDAP defined profiles happens soon, then it would make sense to connect both efforts.

I am really surprised that they do not. I am under the impression that dogtag implemented API to add and remove profiles, right? So it should be replicated somehow. I assume LDAP since it is the Dogtag back end. If it is not replicated then what is the point of API. If it is replicated in some other way I would be interested to know how. May be they use some other method that passes profiles around but that would look fragile. Clarity on the subject would be appreciated.

New profiles are written to the filesystem alongside the standard profiles.

I am not aware of any mechanism to replicate the profiles but will confirm. Moving profiles into LDAP might then be a necessary first step to support FreeIPA custom profiles.

I've started the discussion on pki-devel list: https://www.redhat.com/archives/pki-devel/2014-June/msg00038.html

Yes, Fraser is right - since the old FreeIPA versions, profile was kept, managed and updated on the file system. Moving it to LDAP would be a logical step, if PKI has API to manage them. Fraser, please continue investigating that option.

Moving to further release. Given to the discussion above, this should be part of bigger development effort (like moving profiles to LDAP).

master:

  • b24fe0e Import included profiles during install or upgrade

master:

  • ce33f82 Fix certificate subject base
  • 8b3bc99 Import profiles earlier during install
  • 355b6d4 ipa-pki-proxy: allow certificate and password authentication

Metadata Update from @mkosek:
- Issue assigned to ftweedal
- Issue set to the milestone: FreeIPA 4.2

7 years ago

Login to comment on this ticket.

Metadata