On 5/3/24 10:14 AM, Antoine Gatineau via FreeIPA-users wrote:


On 5/2/24 14:35, Alexander Bokovoy via FreeIPA-users wrote:
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/#cryptography.hazmat.primitives.asymmetric.ec.EllipticCurvePublicNumbers>,
  which had been deprecated for several years. |public_bytes()|
  <https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ec/#cryptography.hazmat.primitives.asymmetric.ec.EllipticCurvePublicKey.public_bytes>
  and |from_encoded_point()|
  <https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ec/#cryptography.hazmat.primitives.asymmetric.ec.EllipticCurvePublicKey.from_encoded_point>
  should be used instead.

*

  *BACKWARDS INCOMPATIBLE:* Support for using MD5 or SHA1 in
  |CertificateBuilder|
  <https://cryptography.io/en/latest/x509/reference/#cryptography.x509.CertificateBuilder>,
  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.




I confirm that by applying manually the change https://pagure.io/freeipa/c/a45a7a20d96af51d463a285cb9318582720be708?branch=master I am now able to enroll tumbleweed client.


--
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue