sslv3 alert bad certificate

[pidario]

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.

[WhyNotHugo]

Not sure why CI is failing; longintrepr.h is part of the python package on Arch.

[pidario]

It is indeed part of python package 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]

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]

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.

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]

Thanks for the explanation. Hope you'll figure this out soon! Let me know if I can be of any help.

[WhyNotHugo]

Does #1070 fix this for you?

[pidario]

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 verify line in the configuration.
Maybe something changed from 0.19.1 and .3. I guess issue can be closed.