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.
--
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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