1. uber_geek's Avatar
    Does anyone have either of these working on the DTEK50? I have both working for my Z10 to Baikal on a private server but can't get either to connect from a DTEK50.

    Posted via the CrackBerry App for Android
    09-13-16 09:35 PM
  2. gebco's Avatar
    I have it working on my Priv. How did you try setting it up?

    Posted via the CrackBerry App for Android
    09-15-16 10:13 PM
  3. c_bryant34's Avatar
    Do they have a different user name and email address?
    09-16-16 01:20 PM
  4. dualpassport's Avatar
    Does anyone have either of these working on the DTEK50? I have both working for my Z10 to Baikal on a private server but can't get either to connect from a DTEK50.

    Posted via the CrackBerry App for Android
    Uber Geek

    I was interested that you can use Baikal with a BB10 device as I was unable to get my Passport linking to my Synology NAS.
    Would you be able to proide details of the settigs you used?


    Posted via CB10
    09-16-16 02:18 PM
  5. uber_geek's Avatar
    Yes, the user name for the caldav and carddav accounts are different than the email address

    Posted via the CrackBerry App for Android
    09-16-16 11:40 PM
  6. uber_geek's Avatar
    Uber Geek

    I was interested that you can use Baikal with a BB10 device as I was unable to get my Passport linking to my Synology NAS.
    Would you be able to proide details of the settigs you used?


    Posted via CB10
    Sure. I entered a description, the user ID I created on the Baikal server, the email address (which was different from the Baikal user), the password needed for the server, and the server address. For the calendar it was 'https://<server name>/baikal/html/cal.php/principals/<user ID>'. For the contacts it was '<server name>/baikal/html/card.php'. The server running Baikal is only accessible via https.

    Posted via the CrackBerry App for Android
    09-17-16 12:04 AM
  7. c_bryant34's Avatar
    Yes, the user name for the caldav and carddav accounts are different than the email address

    Posted via the CrackBerry App for Android
    There's a known issue that were looking at. Seems like it's always just using the email address and not the user name specified.
    09-17-16 10:31 PM
  8. polytan02's Avatar
    Caldav and carddav don't work properly on priv and dtek as such.
    I had to use 3rd party software, which is ****.

    Hopefully this bug will be solved soon.

    It works perfectly well on any bb10 phone.

    Posted via CB10
    09-17-16 11:39 PM
  9. c_bryant34's Avatar
    What errors specifically are you guys seeing when attempting to connect with a CalDAV or CardDAV server?
    09-21-16 12:28 PM
  10. uber_geek's Avatar
    Mine says it can't connect to the server.

    Posted via the CrackBerry App for Android
    Attached Thumbnails CalDAV and CardDAV working?-screenshot_20160921-233614.jpg  
    09-21-16 11:38 PM
  11. waitfor1t's Avatar
    CalDAV and CardDAV are definitely NOT working for me on my Dtek60, but works fine on my passport and z10.
    Every configuration I try sends a malformed request to my server - I get a 400 error on the server like this:

    192.168.10.84 - - [12/Nov/2016:15:37:10 -0800] "-" 400 0 "-" "-"

    I'm using SSL with a self-signed certificate. I have tried using the server name, or just an IP address. I have tried logins using an email address and logins that have the account name different from the email address.

    My backend is baikal. The URL is typically https://server/cal.php/calendars/username/default where "server" is the server name and "username" is the account name.

    Definitely looks like a serious bug.
    11-12-16 05:40 PM
  12. uber_geek's Avatar
    I did a packet capture a few days ago on my server and discovered that I'm not even getting to try the password. The DTEK50 is rejecting my self-signed certificate even though I had it set to accept all. At that point I looked into 3rd party software and found a carddav and a caldav connector that work.
    11-13-16 06:47 AM
  13. waitfor1t's Avatar
    All the caldav connectors I tried didn't work, but cardDav Sync does seem to work for contacts. The caldav connectors that were able to successfully issue a PROPFIND to my server (200 response) couldn't integrate with the Blackberry calendar app.
    11-13-16 08:37 AM
  14. waitfor1t's Avatar
    So I tried importing my self-signed certificate for the web server into the DTEK-60's certificate store, and for some reason it isn't accepted. HOWEVER: I am able to accept another self-signed certificate for VPN use. It could be related to how the certificate is created. I'm going to try a few variations (key size, etc.). Of note: ATT does not seem to allow any key larger than 1024 ... this, AFTER I filed an FCC complaint because they were outright blocking my IPSEC traffic. buttholes.
    11-13-16 08:55 AM
  15. waitfor1t's Avatar
    SOLVED:
    This appears to be an android issue related to key requirements. Android requires the CA flag to be TRUE in the certificate. For openSSL, you need to change 'basicConstraints=CA:TRUE' in '/etc/ssl/openssl.cnf'. My configuration had 'basicConstraints=CA:FALSE'

    once you do this, you can make the key using the following OpenSSL syntax:
    openssl req -new -x509 -sha256 -days 365 -nodes -out server.crt -keyout server.key
    The source of the above is here:
    https://wiki.debian.org/Self-Signed_Certificate

    NEXT: you need to import the certificate into the trust store. There's an app called CAdroid that makes this MUCH easier. If you want to do it manually, you can use any desktop browser to get the certificate, export it, copy to the phone, then install from SDCard. Voila! Working Carddav and Caldav.
    Last edited by waitfor1t; 11-13-16 at 04:12 PM. Reason: adding more detail
    11-13-16 04:06 PM
  16. waitfor1t's Avatar
    I spoke too soon... It looks like the certificates interfere with the mail certs. Apparently the mail certs have different requirements, because I was getting mail before and now I have to re-authenticate over and over. Something is definitely wrong.
    EDIT: The problem seems to be when the email address specified in the caldav and carddav accounts are the same as the email used in the mail account. This messes with authentication in a way I can't figure out. Clearly two different teams developing different parts making wrong assumptions about each other's certificate needs. I've spent too much time on it. Looks to be just broken.
    Last edited by waitfor1t; 11-13-16 at 09:58 PM.
    11-13-16 09:42 PM
  17. waitfor1t's Avatar
    It looks like the problem is related to how the Hub integrates accounts having the same email address. So if you have a calendar and supply the same address as your email server, it gets confused about which certificate to use. Either that, or the dav apps "borrowed" my original email cert before I changed it, and thus updating my email cert broke dav and email. I seem to have things working by wiping everything, then installing email, carddav, caldav, then using a combination of unique certificates for email vs dav, PLUS different email addresses for carddav, email, and caldav, PLUS a 3rd party tool for carddav, PLUS setting CA=TRUE for the caldav/carddav server certs. Oh - and this results in a warning that the calendar app cant send meeting invites out because it isn't associated with an email address. This smells like offshore development.

    My passport just worked.
    11-14-16 11:47 PM
  18. uber_geek's Avatar
    I've done some more investigation with my server. Following waitfor1t's direction, I recreated my self signed certificate with 'basicConstraints=CA:TRUE'. Watching the Apache logs, I see that my DTEK50 is now accepting the certificate. Now what I see is the phone talk to the server twice with the caldav user then try four times with the email address associated. So it appears that the phone is inconsistent with the user it sends to the caldav server. The attempts with the correct user succeed with a 207 but the failures all return a 401

    I added an account to the caldav server named with the email address and added the email address as a user for the Web server. Now setting up the caldav account on the phone succeeds but when I try to add an appointment to the calendar nothing show up. Looking at the Apache logs, l see a 405 returned.

    After fixing the certificate and working around the phones insistence on using the email address as the user on the caldav server, it looks like the caldav server (or the Baikal implementation) doesn't like to use an email address as the user ID.

    Hopefully in a future release of the Hub or Calendar, the phone will send the configured user ID rather than the email address. I haven't worked thru all of the same tests with carddav, but I assume the same error exists there.
    11-15-16 10:39 PM
  19. waitfor1t's Avatar
    I was able to verify that Baikal can use an email address as a dav login using Thunderbird (with lightening and cardbook plugins). So that's not the issue. I do notice, however, that if I specify "server/cal.php/calendars/user/default" as the server, the first request that goes out from blackberry is this:
    PROPFIND /.well-known/caldav HTTP/1.1" 302 160 "-" "BlackBerry-BBA100-1/6.0.1"
    so far so good, because my server gives it a bunch of info, but then the caldav sync adapter on the blackberry does this:
    PROPFIND / HTTP/1.1" 405 172 "-" "BlackBerry-BBA100-1/6.0.1
    so it seems to ignore the info it got, and grabs / which is no bueno.

    HOWEVER: if I specify "server/cal.php/principals/user", it gives me this:
    "PROPFIND /cal.php/principals/user/ HTTP/1.1" 207 538 "-" "BlackBerry-BBA100-1/6.0.1"
    followed by this
    "PROPFIND /card.php/addressbooks/user/default HTTP/1.1" 207 69348 "-" "BlackBerry-BBA100-1/6.0.1"
    SO far so good! I got some calendar entries. But then the bug resurfaces on a calendar refresh:
    "PROPFIND /.well-known/caldav HTTP/1.1" 302 160 "-" "BlackBerry-BBA100-1/6.0.1"
    LOL
    I dont think this is tested code, to be honest. I may be able to do some workarounds with rewrites, but then I'll likely break Thunderbird.

    Nice bug.

    EDIT: I wonder if it doesn't like the expected 302 response, which is what a server should respond when it redirects... this can be altered. That would be so funny if BB doesn't like a 302.. will try to change that next at some point.
    Last edited by waitfor1t; 11-23-16 at 07:59 AM.
    11-22-16 10:12 PM
  20. waitfor1t's Avatar
    New calendar fixes nothing. It still IGNORES the url you put in the server field and looks for ./well-known/caldav on the second try to get to the server. Once it does that, it doesn't consume the redirected page, so the caldav connector can only sync a calendar on the first try. I wish I could see the source... its such a simple fix, and I'm not a programmer.
    12-02-16 10:32 AM
  21. waitfor1t's Avatar
    Confirmed.. The calendar app wants a 301 response and breaks with 302. Omg that is junk coding. Seriously??!! Who put their kiddie as the blackberry calendar app lead??
    I changed the response to 301 and now it likes the redirect and can read entries reliably. However: it still cannot put entries without getting a 401 (unauthorized) response. Lol!!!
    12-04-16 01:27 AM
  22. Mark Shane Hayden's Avatar
    Confirmed.. The calendar app wants a 301 response and breaks with 302. Omg that is junk coding. Seriously??!! Who put their kiddie as the blackberry calendar app lead??
    I changed the response to 301 and now it likes the redirect and can read entries reliably. However: it still cannot put entries without getting a 401 (unauthorized) response. Lol!!!
    I know this thread is kind of stale, but I thought I should mention that this is not junk coding; Blackberry is properly following the IETF standard for calDAV discovery. As stated hete:

    https://tools.ietf.org/html/rfc6764

    The expected responses are 301, 303 or 307. The code 302 is not appropriate for this application because it may not preserve the method. If you want to have a temporary (uncacheable) redirect you must use 307 to ensure the method is preserved.

    So this is NOT exactly junk coding...it is merely a strict interpretation of the standard. Though it would be useful for the client to be more forgiving people who implement servers should actually follow standards
    05-24-17 10:56 AM
  23. waitfor1t's Avatar
    I know this thread is kind of stale, but I thought I should mention that this is not junk coding; Blackberry is properly following the IETF standard for calDAV discovery. As stated here:

    https://tools.ietf.org/html/rfc6764
    This is the kind of thinking that makes offshoring awful. it IS junk coding because they didn't test, and if the test reveals the strict interpretation to cause scenario failures, then screw the RFC. That said: the RFC does not exclude 302:
    (e.g., using a 301, 303, or 307 response)
    These are examples. Servers like Baikal are recommending 302 redirects - totally valid. A dev team gets paid to make things work, not to stand on principle. Workarounds are a fact of life... they're never pleasant because you risk having to undo them if the other party fixes their issue. Whatever - I got it to work, but many won't. so be it.
    Last edited by waitfor1t; 02-21-18 at 12:07 PM.
    06-14-17 07:17 PM
  24. redspawn's Avatar
    I had the same problem and honestly no other available application does have a problem with the implementation on the server than blackberry has. Offering an app which does not really work with common server implementations is not a good way. So sadly the only way using carddav and caldav on the dtek50 is using 3rd party applications. :-(
    10-25-17 12:55 AM

Similar Threads

  1. Best and worst about BB moving to android
    By Powdah in forum General BlackBerry News, Discussion & Rumors
    Replies: 27
    Last Post: 09-17-16, 09:02 AM
  2. Replies: 5
    Last Post: 09-17-16, 05:01 AM
  3. Replies: 2
    Last Post: 09-13-16, 10:07 PM
  4. My Apps and Keyboard
    By John Ransom1 in forum Ask a Question
    Replies: 8
    Last Post: 09-13-16, 01:52 PM
  5. Replies: 1
    Last Post: 09-13-16, 10:24 AM
LINK TO POST COPIED TO CLIPBOARD