bitfireAT/cert4android

If CN is invalid with given domain or IP no connection is established (and also no prompt to continue explicitly)

Closed this issue · 1 comments

People report that they are now unable to connect DAVx5 to their server in certain certificate use cases. It seems that our handling is correct, and in the past this was wrong. But maybe we can give them an option to accept the certificate anyway?

curl https://mail.elestra.si:2080/
curl: (60) SSL: no alternative certificate subject name matches target host name '[mail.elestra.si](http://mail.elestra.si/)'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above

Ticket references:

https://bitfire-at.zammad.com/#ticket/zoom/2632
https://bitfire-at.zammad.com/#ticket/zoom/2620

Yes, this happens when a certificate is valid, but for another hostname than specified ("bad hostname" scenario). This can be reproduced in the cert4android sample app (bad hostname button).

It seems that in previous cert4android versions, we allowed to manually accept such certificates, too:

inner class CustomHostnameVerifier(
private val defaultVerifier: HostnameVerifier?
): HostnameVerifier {
override fun verify(host: String, sslSession: SSLSession): Boolean {
Cert4Android.log.fine("Verifying certificate for $host")
if (defaultVerifier?.verify(host, sslSession) == true)
return true
// default hostname verifier couldn't verify the hostname →
// accept the hostname as verified only if the certificate has been accepted be the user
try {
val cert = sslSession.peerCertificates
if (cert.isNotEmpty() && cert[0] is X509Certificate) {
checkCustomTrusted(cert[0] as X509Certificate)
Cert4Android.log.fine("Certificate is in custom trust store, accepting")
return true

(checkCustomTrusted started the UI)