Connection via https results in "Error 501: Not Implemented"



  • When I try to connect to my owncloud calendar, I get an error 501 as said above. When connecting via http everything works fine (calendars show up etc.), but the connection is unsafe.

    Information:
    Site hostet at www.one.com with SNI certificate. Browser shows no failure and when I try to access the caldav-page directly I am prompted for my login which works fine. (sabreDav 1.7.6 stable).


  • developer

    Please provide an URL, otherwise I can't know what the problem is. If you don't want to post it publicly, please send it to play@bitfire.at mentioning Issue #271.


  • developer

    This is a server problem. When sending an OPTIONS request to the server (in order to determine whether it's CalDAV-capable), it returns 501 Not Implemented:

    curl -vX OPTIONS https://yourdomain/oc6/remote.php/caldav
    * SSL connection using TLS_RSA_WITH_AES_128_CBC_SHA
    > OPTIONS /oc6/remote.php/caldav HTTP/1.1
    > User-Agent: curl/7.32.0
    > Host: yourdomain
    > Accept: */*
    > 
    * HTTP 1.0, assume close after body
    < HTTP/1.0 501 Not Implemented
    < Content-Type: text/html
    < Content-Length: 28
    < Expires: now
    < Pragma: no-cache
    < Cache-control: no-cache,no-store
    < 
    * Closing connection 0
    


  • Tried the same thing, but here I get a different output. Which seems to refer to a "self-signed certificate" in the chain, but as far as I know there is no self-signed cert. And second: Why does a http request work, but a https not?


  • developer

    Tried the same thing, but here I get a different output.

    Repeated it from elsewhere, same result:

    curl -vX OPTIONS https://www.your.host/oc6/remote.php/caldav
    * Hostname was NOT found in DNS cache
    *   Trying xx.xx.xx.xx...
    * Connected to www.your.host (xx.xx.xx.xx) port 443 (#0)
    * successfully set certificate verify locations:
    *   CAfile: none
      CApath: /etc/ssl/certs
    * SSLv3, TLS handshake, Client hello (1):
    * SSLv3, TLS handshake, Server hello (2):
    * SSLv3, TLS handshake, CERT (11):
    * SSLv3, TLS handshake, Server finished (14):
    * SSLv3, TLS handshake, Client key exchange (16):
    * SSLv3, TLS change cipher, Client hello (1):
    * SSLv3, TLS handshake, Finished (20):
    * SSLv3, TLS change cipher, Client hello (1):
    * SSLv3, TLS handshake, Finished (20):
    * SSL connection using AES256-GCM-SHA384
    * Server certificate:
    * 	 subject: OU=Domain Control Validated; OU=Hosted by One.com A/S; OU=EssentialSSL Wildcard; CN=*.your.host
    * 	 start date: 2014-05-19 00:00:00 GMT
    * 	 expire date: 2015-05-19 23:59:59 GMT
    * 	 subjectAltName: www.your.host matched
    * 	 issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=EssentialSSL CA
    * 	 SSL certificate verify ok.
    > OPTIONS /oc6/remote.php/caldav HTTP/1.1
    > User-Agent: curl/7.35.0
    > Host: www.your.host
    > Accept: */*
    > 
    * HTTP 1.0, assume close after body
    < HTTP/1.0 501 Not Implemented
    < Content-Type: text/html
    < Content-Length: 28
    < Expires: now
    < Pragma: no-cache
    < Cache-control: no-cache,no-store
    < 
    * Closing connection 0
    * SSLv3, TLS alert, Client hello (1):
    

    Which seems to refer to a "self-signed certificate" in the chain, but as far as I know there is no self-signed cert.

    Your problem is in no way related to the certificate. It's not an SSLT/TLS problem but a HTTP problem. Your server returns HTTP error 501 when queried via HTTPS.

    And second: Why does a http request work, but a https not?

    That's your real problem. Your server is misconfigured (probably because the HTTPS VHost's configuration is different from the HTTP VHost's one). You can test it with the curl command from above – as long as the OPTIONS request returns 501 for HTTPS, your server is misconfigured.



  • ...sorry for my question, I know it is "my" personal problem, but.. please
    give me a little hint: is this caused by a buggy .htacces file (or in other
    words: something a normal privileged user can influence) or is it the
    hoster who did something wrong and/or weird? Thanks in advance! Thomas

    2014-07-14 12:21 GMT+02:00 rfc2822 notifications@github.com:

    Tried the same thing, but here I get a different output.

    Repeated it from elsewhere, same result:

    curl -vX OPTIONS https://www.your.host/oc6/remote.php/caldav

    • Hostname was NOT found in DNS cache
    • Trying xx.xx.xx.xx...
    • Connected to www.your.host (xx.xx.xx.xx) port 443 (#0)
    • successfully set certificate verify locations:
    • CAfile: none
      CApath: /etc/ssl/certs
    • SSLv3, TLS handshake, Client hello (1):
    • SSLv3, TLS handshake, Server hello (2):
    • SSLv3, TLS handshake, CERT (11):
    • SSLv3, TLS handshake, Server finished (14):
    • SSLv3, TLS handshake, Client key exchange (16):
    • SSLv3, TLS change cipher, Client hello (1):
    • SSLv3, TLS handshake, Finished (20):
    • SSLv3, TLS change cipher, Client hello (1):
    • SSLv3, TLS handshake, Finished (20):
    • SSL connection using AES256-GCM-SHA384
    • Server certificate:
    • subject: OU=Domain Control Validated; OU=Hosted by One.com A/S; OU=EssentialSSL Wildcard; CN=*.your.host
    • start date: 2014-05-19 00:00:00 GMT
    • expire date: 2015-05-19 23:59:59 GMT
    • subjectAltName: www.your.host matched
    • issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=EssentialSSL CA
    • SSL certificate verify ok.

    OPTIONS /oc6/remote.php/caldav HTTP/1.1
    User-Agent: curl/7.35.0
    Host: www.your.host
    Accept: /

    • HTTP 1.0, assume close after body
      < HTTP/1.0 501 Not Implemented
      < Content-Type: text/html
      < Content-Length: 28
      < Expires: now
      < Pragma: no-cache
      < Cache-control: no-cache,no-store
      <
    • Closing connection 0
    • SSLv3, TLS alert, Client hello (1):

    Which seems to refer to a "self-signed certificate" in the chain, but as
    far as I know there is no >self-signed cert.

    Your problem is in no way related to the certificate.

    And second: Why does a http request work, but a https not?

    That's your real problem. Your server is misconfigured (probably because
    the HTTPS VHost's configuration is different from the HTTP VHost's one).
    You can test it with the curl command from above – as long as the OPTIONS
    request returns 501 for HTTPS, your server is misconfigured.


    Reply to this email directly or view it on GitHub
    https://github.com/rfc2822/davdroid/issues/271#issuecomment-48884624.


  • developer

    ...sorry for my question, I know it is "my" personal problem, but.. please give me a little hint: is this caused by a buggy .htacces file (or in other words: something a normal privileged user can influence) or is it the hoster who did something wrong and/or weird?

    I can't tell you :/ It can be anything. 501 is often caused by .htaccess misconfiguration, but there are thousands of other possible reasons. I'd first test "normal" HTTPS and DAV without HTTPS, then combine it. Don't forget to make sure the required HTTP methods for DAV (OPTIONS, PROPFIND, GET, PUT, DELETE, REPORT, [PATCH]) are allowed.



  • Thank you, that helps me a lot... too sad, that support at my hoster is
    soooo low level.

    2014-07-15 12:26 GMT+02:00 rfc2822 notifications@github.com:

    ...sorry for my question, I know it is "my" personal problem, but.. please
    give me a little hint: is this caused by a buggy .htacces file (or in other
    words: something a normal privileged user can influence) or is it the
    hoster who did something wrong and/or weird?

    I can't tell you :/ It can be anything. 501 is often caused by .htaccess
    misconfiguration, but there are thousands of other possible reasons. I'd
    first test "normal" HTTPS and DAV without HTTP, then combine it. Don't
    forget to make sure the required HTTP methods for DAV (OPTIONS, PROPFIND,
    GET, PUT, DELETE, REPORT, [PATCH]) are allowed.


    Reply to this email directly or view it on GitHub
    https://github.com/rfc2822/davdroid/issues/271#issuecomment-49014245.


Log in to reply
 

Looks like your connection to Bitfire App Forums was lost, please wait while we try to reconnect.