[Pkg-freeipa-devel] Bug#970880: Bug#970880: Bug#970880: Bug#970880: Bug#970880: Bug#970880: freeipa-server: FreeIPA server installation fails with Certificate issuance failed (CA_REJECTED)

[Timo Aaltonen]

On 12.10.2021 20.48, Spencer Olson wrote:
> On Tue, Oct 12, 2021 at 9:53 AM Spencer Olson <olsonse at umich.edu> wrote:
>>
>> On Sun, Oct 10, 2021 at 12:58 PM Timo Aaltonen <tjaalton at debian.org> wrote:
>>>
>>>>
>>>>
>>>> Maybe the CI will finish before I can get back to my testing.
>>>
>>> And it did, this error is fixed now :)
>>>
>>> But it fails later on, so there's some work still to catch up with the
>>> current distro, but at least this particular annoyance is resolved, so
>>> many thanks for figuring it out! I was sure the reason was something
>>> silly and related to the SSL stack (or maybe ciphers) but was blind to
>>> see it.
>>
>> I borrowed the .deb packages from the build artifacts and tested more.
>> You probably already have this fixed but,
>>    * /var/lib/gssproxy directory has to be created so that gssproxy can
>> be started.

gssproxy 0.8.2-2 or newer has it.

>> I manually created the path and ran the script again.  It passes the
>> gssproxy error that the CI got stuck on, but it failed at creating the
>> client with this error:
>>
>> DEBUG The ipa-client-install command failed, exception: KerberosError:
>> No valid Negotiate header in server response
>> 2021-10-11T09:32:49Z ERROR No valid Negotiate header in server response
>>
>> I've found a few posts online with errors similar to this in 2019 (one
>> "solution" supposedly posted on RedHat's site that I don't have access
>> to).  But, I haven't figured this one out yet.  Perhaps you already
>> know how to fix this one.
> 
> So, I am now wondering if the latest issue I am seeing (where iti
> complains about the Negotiate problem) might be due to the bind9
> configuration/installation not being quite correct.
> 
> I have two VMs, one for CentOS Stream.
> For the CentOS stream VM:
>   - just uses a DHCP address because I was lazy in the setup and didn't
> take the time to change this
>   - ipa-server-install finished successfully
>   - there is a named-pkcs11 program installed and corresponding
> processing running
>   - the named-pkcs11 program is certainly linked to a few libraries
> that the normal named program is not linked to
>   - the nameserver resolves things as expected:  the host of the server
> ("sid" in my test case) and certainly also ipa-ca.domain resolve just
> fine
>   - bind9-dyndb-ldap *is* installed
>   - doing "fuser /usr/lib64/bind/ldap.so" does show the process ID of
> named-pkcs11
> 
> For the Debian sid install:
>   - Uses netplan to specify a static IP.  This is the same VM i've been
> using for all my tests, though I have been using and unwinding
> snapshots a lot from test to test.
>   - ipa-server-install fails at the point that the ipa-client-install runs
>   - named-pkcs11 does *not* exist as an installed program
>   - `named` process is running and does respond to queries, but it does
> not resolve anything useful
>   - browsing through the LDAP entries for DNS, I can see entries for
> the ipa server, but named does not resolve these
>   - bind9-dyndb-ldap *is* installed.
>   - doing "fuser /usr/lib64/bind/ldap.so" does show the process ID of
> named-pkcs11
> 
> So, clearly, there is a difference between the install on CentOS and
> Debian Sid with the latest updates.  I might add that my working old
> ubuntu machine does indeed have the named-pkcs11 process.  I am
> wondering if this is a problem that was never resolved since the
> updates to the new bind9 that plagued getting freeipa to work for
> debian originally.  Perhaps this was never fully finished because we
> never had freeipa to actually test the changes in the bind9 package.

Well, at this point my focus is on getting a working baseline on Debian sid.

named-pkcs11 isn't used anymore with the current versions.


-- 
t