Ok - I double checked and debugged that on my own :):
The problem is, that okhttp changed its verification behavior with cd84d79c3574de81f23802f832f2ead6ad38a735:
The use of Common Name was deprecated in RFC 2818 (May 2000), section 3.1:
Although the use of the Common Name is existing practice, it is
deprecated and Certification Authorities are encouraged to use the
In 2017, Chrome 58, Firefox 48, and Opera 45 web browsers removed this
fallback, with Chrome leaving it configurable for enterprise deployments
Android is removing it in http://r.android.com/581382 .
The okhttp version was updated within dav4android with 1169e15017a900d7fb3f29e42ea18d45e3c5d33a.
I generated my server-side certificate without any X509 extensions and just gave the common name (CN, -> the domain name) in the certificate, something like:
openssl req -new -key key-for-webserver.pem -out www_sign-request.csr -sha512 # and than entering all the stuff interactively…
So I need to generate a new certificate with a subject alternative name (e.g. like described here - for people with the same problem as me). I’ll do that and hope that it is than working again.
Nevertheless I wonder why e.g. Firefox does not have a problem with this certificate, as the above commit note says the “fallback”- verification by the CN is removed with version 48 of FF…