I used DAVx5 on my Motorola Moto G3 to sync with my calender at web.de without any issues over the last month. Today I wasn’t able to sync and DAVx5 came up with the information, that it found an unknown X509 certificate. Following this message there are several details listed (CN=hsp.gmx.net, O=1&1 Mail & Media GmbH…) and I have to check “I checked the full checksum manually” (translated from German) to accept the certificate.
I unsuccessfully tried finding information about the correct checksum at web.de website. Is there another way to check a certificate for authenticity?
Did you enable “Distrust system certificates” in DAVx⁵ settings? Can you please provide the debug info?
Can you provide the base URL you have used? Normally, trust for public providers should be established by the PKI. It’s also possible that there was a temporary problem or something like a MITM WiFi.
I experience the same issue. I guess, the issue is the base URL https://kalender-bs-ddos.gmx.net/ of my calendar, which is not part of the certificate delivered. Only https://kalender.gmx.net/ and some other sub domains of gmx.net are part of this certificate.
I added my calendar providing email address. I will try to figure out, if I can re-add the calendar providing URL and email address.
I could reproduce the problem (add a GMX account).
The reason is: DAVx⁵ looks up the SRV records of GMX which are:
$ host -t SRV _caldavs._tcp.gmx.net _caldavs._tcp.gmx.net has SRV record 0 1 443 kalender-bs-ddos.gmx.net.
So, GMX servers says the CalDAV service is at https://kalender-bs-ddos.gmx.net:443. When you access this URL, the certificate is invalid. You can easily check this by opening the URL in a browser.
Could you contact GMX that their SRV records are wrong, providing this thread as reference?
Same for web.de:
$ host -t SRV _caldavs._tcp.web.de _caldavs._tcp.web.de has SRV record 1 1 443 kalender-bs.web.de. $curl https://kalender-bs.web.de curl: (51) SSL: no alternative certificate subject name matches target host name 'kalender-bs.web.de'
Für die genannten Domains wurden gestern wieder funktionierende Zertifikate hinterlegt. Bitte verifizieren, ob das Problem damit gelöst ist.
Eventuell kann es vorkommen, dass ältere Android Versionen (<4.3) trotzdem nicht damit zurecht kommen, da die ausstellende CA nicht im Zertifikatsstore des Betriebssystems enthalten ist/sein könnte.
@rfc2822 Sorry, I didn’t thought about answering in English. At least good, that it works again.
Works for me.
@papierkorb Thanks for fixing this so quickly!
@xperia-xz1 Sorry for the inconvenience. This shouldn’t have happened in the first place.
Sorry for the delay: Works for me!
Thanks a lot for helping!