This issue has been fixed with the latest update of aCalendar+.
HostnameVerifier doesn't verify correct hostname
-
Hello,
since last update (v0.6.10.1), I cannot synchronize anymore.
With version v0.6.10, everything is fine so I believe this is a regression due to #410.My certificate contains “example.com” as CN. The only stuff special about my setup it that I run the calendar server on another port (63000).
Android 4.2.2
Phone: Wiko rainbow
Server: Radicale 0.7-1.1 (Debian)
DAVDroid 0.6.10.1Logs (anonymized):
V/davdroid.URIUtils( 8354): Normalized URL https://example.com:63000/user/standard.ics/ -> https://example.com:63000/user/standard.ics/ D/davdroid.WebDavResource( 8354): Using preemptive authentication (not compatible with Digest auth) I/davdroid.SyncManager( 8354): Remotely removing 0 deleted resource(s) (if not changed) I/davdroid.SyncManager( 8354): Uploading 0 new resource(s) (if not existing) I/davdroid.SyncManager( 8354): Uploading 0 modified resource(s) (if not changed) D/davdroid.TlsSniSocketFactory( 8354): Establishing direct TLS connection to https://example.com:63000 V/davdroid.TlsSniSocketFactory( 8354): Setting allowed TLS protocols: TLSv1, TLSv1.1, TLSv1.2 V/davdroid.TlsSniSocketFactory( 8354): Setting allowed TLS ciphers: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA D/davdroid.TlsSniSocketFactory( 8354): No documented SNI support on Android <4.2, trying reflection method with host name example.com E/NativeCrypto( 8354): ssl=0x5e2a42a8 cert_verify_callback x509_store_ctx=0x5e6a3a88 arg=0x0 E/NativeCrypto( 8354): ssl=0x5e2a42a8 cert_verify_callback calling verifyCertificateChain authMethod=RSA E/davdroid.DavSyncAdapter( 8354): I/O error (Android will try again later) E/davdroid.DavSyncAdapter( 8354): javax.net.ssl.SSLPeerUnverifiedException: example.com E/davdroid.DavSyncAdapter( 8354): at at.bitfire.davdroid.webdav.TlsSniSocketFactory.establishAndVerify(TlsSniSocketFactory.java:121) E/davdroid.DavSyncAdapter( 8354): at at.bitfire.davdroid.webdav.TlsSniSocketFactory.connectSocket(TlsSniSocketFactory.java:83) E/davdroid.DavSyncAdapter( 8354): at at.bitfire.davdroid.webdav.TlsSniSocketFactory.connectSocket(TlsSniSocketFactory.java:37) E/davdroid.DavSyncAdapter( 8354): at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:124) E/davdroid.DavSyncAdapter( 8354): at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318) E/davdroid.DavSyncAdapter( 8354): at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:373) E/davdroid.DavSyncAdapter( 8354): at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:225) E/davdroid.DavSyncAdapter( 8354): at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195) E/davdroid.DavSyncAdapter( 8354): at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86) E/davdroid.DavSyncAdapter( 8354): at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) E/davdroid.DavSyncAdapter( 8354): at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) E/davdroid.DavSyncAdapter( 8354): at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) E/davdroid.DavSyncAdapter( 8354): at at.bitfire.davdroid.webdav.WebDavResource.propfind(WebDavResource.java:272) E/davdroid.DavSyncAdapter( 8354): at at.bitfire.davdroid.resource.RemoteCollection.getCTag(RemoteCollection.java:64) E/davdroid.DavSyncAdapter( 8354): at at.bitfire.davdroid.syncadapter.SyncManager.synchronize(SyncManager.java:61) E/davdroid.DavSyncAdapter( 8354): at at.bitfire.davdroid.syncadapter.DavSyncAdapter.onPerformSync(DavSyncAdapter.java:142) E/davdroid.DavSyncAdapter( 8354): at android.content.AbstractThreadedSyncAdapter$SyncThread.run(AbstractThreadedSyncAdapter.java:254) I/davdroid.DavSyncAdapter( 8354): Sync complete for com.android.calendar
Thanks !
W. -
Are you sure that your certificate is correct? Can you post the FQDN or send it to play@bitfire.at?
-
Yes I think my certificate is correct, because if I downgrade DAVDroid to v0.6.10, the synchronisation is successful.
Please check your mails for the FQDN. -
I don’t have an idea why BrowserCompatHostNameVerifier doesn’t work.
-
javax.net.ssl.SSLException: Certificate for <xxxxxxxxx.eu> doesn't contain CN or DNS subjectAlt at org.apache.http.conn.ssl.AbstractVerifierHC4.verify(AbstractVerifierHC4.java:180) at org.apache.http.conn.ssl.BrowserCompatHostnameVerifierHC4.verify(BrowserCompatHostnameVerifierHC4.java:54) at org.apache.http.conn.ssl.AbstractVerifierHC4.verify(AbstractVerifierHC4.java:154) at at.bitfire.davdroid.webdav.TlsSniSocketFactory.establishAndVerify(TlsSniSocketFactory.java:125) at at.bitfire.davdroid.webdav.TlsSniSocketFactory.connectSocket(TlsSniSocketFactory.java:86)
For some reason, BrowserCompatHostnameVerifierHC4 doesn’t see the CN of this special certificate.
-
BrowserCompatHostnameVerifierHC4.getCNs(certificate)
isn’t able to extract the CN.Can I use the certificate content to report the bug to Apache HttpClient?
-
Le 09/01/2015 22:33, rfc2822 a écrit :
|BrowserCompatHostnameVerifierHC4.getCNs(certificate)| isn’t able to
extract the CN.Can I use the certificate content to report the bug to Apache HttpClient?
—
Reply to this email directly or view it on GitHub
https://github.com/bitfireAT/davdroid/issues/424#issuecomment-69402642.Yes you can. Thanks for your efforts !
-
I guess it’s because of the " " components. As a workaround, I suggest to create a certificate without " ".
-
Reported to upstream: https://issues.apache.org/jira/browse/HTTPCLIENT-1597
Please follow up there. -
Thanks for you efforts.
What did you mean with " " component ? Which part of the certificate is empty ?
As a workaround, because I guess I will never get a lib http update, would it be possible to first use the BrowserCompatHostnameVerifierHC4 and if it fails, fallback to the DefaultHostnameVerifier ?
-
What did you mean with " " component ? Which part of the certificate is empty ?
subject=/C=EU/ST= /O= /CN=nobelxx.xx
The ST and O parts.
As a workaround, because I guess I will never get a lib http update,
Why shouldn’t you? The Apache HttpClient library is shipped with DAVdroid.
-
Yes sorry I thought apache http came with the O.S.
Ok, I will try with a ST and a O when I find time. Maybe in between the guys from apache http find something.
-
They found the bug in apache http.
When you ship the new apache, I will give a try and post my results.
-
Yes it has been fixed in upstream, but I didn’t manage to integrate the new library version yet.
-
The issue has been fixed in upstream, it works now. Will be available in the next DAVdroid release.