Description
Context:
OS: Arch
vdirsyncer v0.19.x
python v3.11.3
This applies to vdirsyncer (v0.19.0 and v0.19.1) installed from either pipx, pip or community arch repository.
I use xandikos server behind a reverse proxy. I use mutual TLS authentication, the configuration is the following:
[general]
status_path = "/path/to/vdirsyncer/status/"
[pair contacts]
a = "contacts_local"
b = "contacts_remote"
collections = ["from a", "from b"]
[storage contacts_local]
type = "filesystem"
path = "/path/to/contacts/"
fileext = ".vcf"
[storage contacts_remote]
type = "carddav"
url = "https://mydavserver"
auth_cert = ["/path/to/cert.pem", "/path/to/key.pem"]
verify = "/etc/ssl/cert.pem"
This started to happen after python 3.11 update:
whenever I try to launch vdirsyncer discover I get the following error:
error: Unknown error occurred: [Errno 1] [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate (_ssl.c:2576)
It looks like vdirsyncer is not using the client certificate and key because if I manually add in this if block this line of code:
ssl.load_cert_chain(*self._settings["cert"])the error is gone.
On a side note, I also had to add the line verify = "/etc/ssl/cert.pem" to my configuration, which I didn't have before. If I omit it, I get that same error from before. Maybe there was a change in the python module ecosystem that stopped the modules from using OS certificates bundle?
Downgrading to v0.18.0 fixes both issues.
Any idea what might have gone wrong with the upgrade to 0.19?
Thanks in advance.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Participants
Activity
Fix client certificate support
WhyNotHugo commentedon May 18, 2023
Not sure why CI is failing;
longintrepr.his part of thepythonpackage on Arch.pidario commentedon May 18, 2023
It is indeed part of
pythonpackage on Arch. I don't know how to help you here.Anyway, mine is a dirty trick that I found out by playing around with
aiohttp, I'm not sure that would be good for the whole project. The failing CI is a clear indicator that I'm right. If I knew that was the optimal fix I would have opened a PR myself.The only sure thing I can say is that by introducing
aiohttp(if I'm not mistaken in v0.18.0 it wasn't there) broke something but I'm sure there is a better approach to fix this issue.WhyNotHugo commentedon May 18, 2023
Your approach doesn't seem to break anything (at least not on some limited testing that I did locally). I wanted to get CI to run to make sure it doesn't break a any other test scenarios, but the CI failure is entirely unrelated.
WhyNotHugo commentedon May 18, 2023
Yeah, some of the TLS bits had to be re-written and I think some less common features were left out (like client certs).
pidario commentedon May 18, 2023
Thanks for the explanation. Hope you'll figure this out soon! Let me know if I can be of any help.
Fix client certificate support
Fix client certificate support
WhyNotHugo commentedon Dec 9, 2024
Does #1070 fix this for you?
pidario commentedon Dec 9, 2024
I still don't understand what happened, probably I messed up my setup when I switched from pipx to uv... I thought I was still running 0.18 since it worked flawlessly but I'm actually using 0.19.3 and it works. I don't even need the
verifyline in the configuration.Maybe something changed from 0.19.1 and .3. I guess issue can be closed.