[Freeipa-users] Unable to get new certificates after upgrade

[Alexander Bokovoy]

On Sat, 27 Feb 2016, Alessandro De Maria wrote:
>Hello list,
>
>I was running freeipa 4.1 on Centos 7.1.
>I wanted to upgrade to freeipa 4.2.x to make use of user certificates.
>
>Upgrade (through yum upgrade) went ok and I am now on version:
>Name        : ipa-server
>Version     : 4.2.0
>Release     : 15.el7_2.6
>
>
>However I am unable to generate new certificates (this functionality was
>working perfectly before)
>
>When I use ipa-getcert request I get the following message (ipa-getcert
>list)
>
>*Failed request, will retry: 4001 (RPC failed at server. caIPAserviceCert:
>Certificate Profile not found*
>I read this blog:
>https://blog-ftweedal.rhcloud.com/2015/08/user-certificates-and-custom-profiles-with-freeipa-4-2/
>
>I tried the following:
>$ ipa certprofile-show caIPAserviceCert
>ipa: ERROR: caIPAserviceCert: Certificate Profile not found
>
>
>So i tried to download *caIPAserviceCert* from this url and importing it:
>
>$ wget
>https://raw.githubusercontent.com/encukou/freeipa/master/install/share/profiles/caIPAserviceCert.cfg
>
>$ ipa certprofile-import caIPAserviceCert --file caIPAserviceCert.cfg
>--desc "Default certificates" --store TRUE
>ipa: ERROR: Non-2xx response from CA REST API: 400 Bad Request. Profile
>already exists
>
>So I imported it with another profile name (caIPAserviceCert_new) and that
>worked (I can see it from the web interface, but I cannot see caIPAserviceCert
>there)
>
>I tried to use:
>ipa-getcert request -T caIPAserviceCert_new  ... ... ...
>
>and that still gives the the infamous message above:
>*Failed request, will retry: 4001 (RPC failed at server. caIPAserviceCert:
>Certificate Profile not found*
>
>Could someone help me out please? I noticed that 4.2.3 is out with
>important bug fixes, is there a repository out there with Centos rmps?
I have no comments to your problem but wanted to comment on this
specific thing:

When certain software is packaged as part of Red Hat Enterprise Linux,
there are rules its maintainers have to follow. One of these rules is to
be more strict with rebases and package versions. 

When a rebase to newer version is not granted, any bugfixes/updates will
be managed as patches to the base version. This means that if you see
ipa-server-4.2.0-<something>.el7_2 in RHEL 7.2, this does not mean that
a particular package has only FreeIPA 4.2.0 version. It includes a
number of patches on top of it which make it equal to a certain 4.2.x
version at the time of a release of that package. These patches will
have to be carried as separate files until next package rebase.

For example ipa-4.2.0-15.el7.centos.3.src.rpm has 170 patches on top of
4.2.0 tarball. Some of these are downstream-specific like branding
changes but the rest are patches on top of 4.2.0 upstream version that
bring the package close to 4.2.3.

This allows to be more explicit in what is added on top of a base
version and some Red Hat customers actually depend on such information
in their own software management processes. For maintainers this, of
course, creates a bit of overhead but it is better to be more explicit
here. The only inconvenience is that we have to explain the process
sometimes to people like you who think 4.2.0-<something>.el7_2 is older
than 4.2.3 upstream release.

In fact, out of those 170 patches, there are patches which went into
upstream 4.3.0 release and weren't yet released in 4.2.x branch because
there wasn't any 4.2.x release after 4.2.3 yet. So in the case of
4.2.0-<something>.el7_2 you are actually getting more than FreeIPA
4.2.3.

I hope this makes your hunt for '4.2.3' CentOS release less urgent.


-- 
/ Alexander Bokovoy