On Аўт, 30 кра 2024, Antoine Gatineau via FreeIPA-users wrote:
>
> On 4/30/24 15:34, Rob Crittenden wrote:
>> Antoine Gatineau via FreeIPA-users wrote:
>>> Hello,
>>>
>>> When enrolling a opensuse tumbleweed client, ipa-client-install
>>> fails to
>>> get the cacertificate from ldap with error:
>>>
>>> 2024-04-30T11:23:16Z DEBUG Initializing principal adminprincipal using
>>> password
>>> 2024-04-30T11:23:16Z DEBUG Starting external process
>>> 2024-04-30T11:23:16Z DEBUG args=['/usr/bin/kinit',
'adminuser', '-c',
>>> '/tmp/krbcc2swf0edk/ccache']
>>> 2024-04-30T11:23:16Z DEBUG Process finished, return code=0
>>> 2024-04-30T11:23:16Z DEBUG stdout=Password for adminuser:
>>>
>>> 2024-04-30T11:23:16Z DEBUG stderr=
>>> 2024-04-30T11:23:16Z DEBUG trying to retrieve CA cert via LDAP from
>>> ipa-server-01.empire.lan
>>> 2024-04-30T11:23:16Z DEBUG retrieving schema for SchemaCache
>>> url=ldap://ipa-server-01.empire.lan:389
>>> conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f020cb3f490>
>>> 2024-04-30T11:23:17Z ERROR unable to convert the attribute
>>> 'cacertificate;binary' value
>>> b'0\x82\x04\x.........ETC........................................'
to
>>> type <class 'cryptography.x509.base.Certificate'>
>>> 2024-04-30T11:23:17Z DEBUG get_ca_certs_from_ldap() error: %i
>>> format: a
>>> real number is required, not dict
>>> 2024-04-30T11:23:17Z DEBUG %i format: a real number is required,
>>> not dict
>>> 2024-04-30T11:23:17Z ERROR Cannot obtain CA certificate
>>> 'ldap://ipa-server-01.empire.lan' doesn't have a certificate.
>>> 2024-04-30T11:23:17Z ERROR Installation failed. Rolling back changes.
>>>
>>> ipa server is 4.11.0 (centos stream 9 latest)
>>>
>>> ipa client is 4.11.1 (opensuse tumbleweed) from this source:
>>>
https://build.opensuse.org/package/show/security%3Aidm/freeipa
>>>
>>>
>>> With debian 12 and ipa-client 4.9.11 the enrollment succeeds.
>>>
>>> With centos stream 9 and ipa-client 4.11.0 the enrollment succeeds.
>>>
>>> Is there a limitation with clients newer than the server?
>> Not usually.
>>
>>> What can I check to fix this issue?
>> I'd start with comparing what version of python-cryptography is on the
>> working vs non-working systems.
>
> debian: 38.0.4-3 (python 3.11)
>
> centos stream: 36.0.1-4.el9 (python 3.9)
>
> tumbleweed: python311-cryptography 42.0.5-1.1
>
> Indeed, it is quite newer on tumbleweed.
>
>
https://cryptography.io/en/latest/changelog/
> There are some deprecations in 39.0 that might be in play but I don't
> know exactly what is used by ipa.
>
> *
>
> *BACKWARDS INCOMPATIBLE:* Removed the |encode_point| and
> |from_encoded_point| methods on |EllipticCurvePublicNumbers|
>
<
https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ec/#crypto...;,
> which had been deprecated for several years. |public_bytes()|
>
<
https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ec/#crypto...
> and |from_encoded_point()|
>
<
https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ec/#crypto...
> should be used instead.
>
> *
>
> *BACKWARDS INCOMPATIBLE:* Support for using MD5 or SHA1 in
> |CertificateBuilder|
>
<
https://cryptography.io/en/latest/x509/reference/#cryptography.x509.Certi...;,
> other X.509 builders, and PKCS7 has been removed.
We don't use any of those features at all.
Fedora 39+ is using python-cryptography 42.0.5 and it works fine with
FreeIPA with a set of fixes to
https://pagure.io/freeipa/issue/9518.
Perhaps Tumbleweed misses these patches?
After some digging, I think you are
right.
Tumbleweed has package based on commit e18ac35 dated from January 10th
while the fix you mentioned has commit a45a7a2 commited on January 24th.
Thank you a lot for the analysis and the time. I'll open a bug with
opensuse because the issue is on their side.
My concern and why I asked to provide the certificate was due to the
particular message displayed in your logs. That message comes from
PyUnicode_Format() which is internal Python function that is called by
internal Python code when a string is transformed from bytes to Python
string. Neither FreeIPA nor Cryptography code provides any string that
uses '%i' format in the certificate parsing path. This means it might be
a string from the certificate itself here. However, the certificate you
sent me does not have any problem and is loadable without issues.