client certificates and okhttp failures: okhttp3.internal.http2.StreamResetException: stream was reset: HTTP_1_1_REQUIRED



  • Hi everyone,

    I’m trying to get davx5 work with SSL client certificates but I’m running into problems so far.
    If I access the server using username + password (doing Basic authentication), everything works as expected. As soon as I enable Client Certificates support, setting up a new account in DAVx5 fails with

    2019-05-22 20:21:33 428 [HttpClient] Using provider certificate michael@test.example.com for authentication (chain length: 2)
    2019-05-22 20:21:33 428 [ui.setup.DavResourceFinder] Finding initial carddav service configuration
    2019-05-22 20:21:33 428 [ui.setup.DavResourceFinder] Checking user-given URL: https://dav.test.example.com:8843/
    2019-05-22 20:21:33 428 [HttpClient] --> PROPFIND https://dav.test.example.com:8843/
    2019-05-22 20:21:33 428 [HttpClient] Content-Type: application/xml; charset=utf-8
    2019-05-22 20:21:33 428 [HttpClient] Content-Length: 290
    2019-05-22 20:21:33 428 [HttpClient] Depth: 0
    2019-05-22 20:21:33 428 [HttpClient] 
    2019-05-22 20:21:33 428 [HttpClient] <?xml version='1.0' encoding='UTF-8' ?><propfind xmlns="DAV:" xmlns:CAL="urn:ietf:params:xml:ns:caldav" xmlns:CARD="urn:ietf:params:xml:ns:carddav"><prop><resourcetype /><displayname /><CARD:addressbook-description /><CARD:addressbook-home-set /><current-user-principal /></prop></propfind>
    2019-05-22 20:21:33 428 [HttpClient] --> END PROPFIND (290-byte body)
    2019-05-22 20:21:33 428 [HttpClient] <-- HTTP FAILED: okhttp3.internal.http2.StreamResetException: stream was reset: HTTP_1_1_REQUIRED
    2019-05-22 20:21:33 428 [ui.setup.DavResourceFinder] PROPFIND/OPTIONS on user-given URL failed
    EXCEPTION okhttp3.internal.http2.StreamResetException: stream was reset: HTTP_1_1_REQUIRED
    	at okhttp3.internal.http2.Http2Stream.takeHeaders(Http2Stream.java:158)
    	at okhttp3.internal.http2.Http2Codec.readResponseHeaders(Http2Codec.java:131)
    	at okhttp3.internal.http.CallServerInterceptor.intercept(CallServerInterceptor.java:88)
    	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
    	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
    	at at.bitfire.davdroid.HttpClient$UserAgentInterceptor.intercept(HttpClient.kt:246)
    	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
    	at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:45)
    	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
    	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
    	at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93)
    	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
    	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
    	at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
    	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
    	at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:126)
    	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
    	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
    	at okhttp3.logging.HttpLoggingInterceptor.intercept(HttpLoggingInterceptor.java:225)
    	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
    	at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
    	at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:250)
    	at okhttp3.RealCall.execute(RealCall.java:93)
    	at at.bitfire.dav4jvm.DavResource$propfind$1.invoke(DavResource.kt:323)
    	at at.bitfire.dav4jvm.DavResource$propfind$1.invoke(DavResource.kt:34)
    	at at.bitfire.dav4jvm.DavResource.followRedirects(DavResource.kt:378)
    	at at.bitfire.dav4jvm.DavResource.propfind(DavResource.kt:318)
    	at at.bitfire.davdroid.ui.setup.DavResourceFinder.checkUserGivenURL(DavResourceFinder.kt:180)
    	at at.bitfire.davdroid.ui.setup.DavResourceFinder.findInitialConfiguration(DavResourceFinder.kt:115)
    	at at.bitfire.davdroid.ui.setup.DavResourceFinder.findInitialConfiguration(DavResourceFinder.kt:73)
    	at at.bitfire.davdroid.ui.setup.DetectConfigurationFragment$DetectConfigurationModel$detectConfiguration$2.invoke(DetectConfigurationFragment.kt:83)
    	at at.bitfire.davdroid.ui.setup.DetectConfigurationFragment$DetectConfigurationModel$detectConfiguration$2.invoke(DetectConfigurationFragment.kt:62)
    	at kotlin.concurrent.ThreadsKt$thread$thread$1.run(Thread.kt:30)
    
    
    

    A full log is attached davx5-info.txt

    Is anyone successfully using authentication via client certificates and has an idea what is going wrong here?



  • https://stackoverflow.com/a/40093039

    Reading this it looks like it might be a client problem.


  • developer

    Does it work when you disable HTTP/2 in the Web server? Can you provide a test account / certificate so that I can have a look?



  • Hi @rfc2822 ,

    thanks for your swift reply!

    Turning off HTTP2 support (in my case, IIS 10), does indeed work around the problem.
    Unfortunately, this is a global switch for IIS, i.e. I can’t just turn it off for the CardDAV server (at least I haven’t found a way to do that) and I’d prefer not having to turn off HTTP/2 globally.

    Concerning the test account: The test system is running on a server without a public facing IP address, so this won’t be that easy.
    But if this is what it takes to get this issue resolved, I’ll see what I can do.


  • developer

    Seems like HTTP/2 does not support client certificates yet, so I guess it should be disabled both on server and client until this combination works fine. Will have to investigate further.



  • https://www.apachelounge.com/viewtopic.php?p=33810

    This is from 2016, dunno what the current state of affairs is.


  • developer



  • Looking good so far. First tests indicate that everything is now working as expected. Thanks!
    Should I run into problems, I’ll report back


  • developer

    @mbiebl Ok. Thanks for the hint. Seems like there’s still plenty of work with HTTP/2…


  • developer



  • @rfc2822 thanks again


Log in to reply
 

Similar topics

  • 1
  • 7
  • 3