Page 2 of 2 FirstFirst 12
Results 21 to 29 of 29
  1.    #21  
    Quote Originally Posted by greenoyster View Post
    Have you tried manually adding the certificate using the Certificate Manager?
    No. I bypassed the 'drag and drop into dowloads with the usb cable plugged in..." and just dumped the files onto my phone using WQI (since i haven't installed optware SSH/SFTP yet)

    anyway, i just noticed something:

    in /etc/ssl/openssl.cnf there is a config line that states where to look for the cacert.pem file. right above that line is one defining "$dir".
    Silly me. I thought the line read /etc/ssl when, in fact, it points to /var/ssl. When I uploaded my cacerts.pem file (from which they compile weekly from, I sent it to /etc/ssl/certs instead of /var/ssl/certs.

    It should be noted that I also edited:
    certificate = $dir/cacert.pem #The CA certificate
    to read:
    certificate = $dir/certs/cacert.pem #The Ca certificate

    just so I could keep all my cert files contained in one folder i.e <root>/var/ssl/certs/

    I guess another test of cert tweaking is in order but I won't be going to campus until monday evening.

    I'd rather just recompile libcurl with the (curl_VERIFYPEER, False) switch which would put an end to hunting for/installing ssl certs. SSL would not be affected (the encryption part of it) therefor data is reasonably secure (barring the MitM attacks mentioned in previous posts). However, responsibility for connecting to SAFE/REAL networks (as opposed to spoofed ones) would be up to me.

    Personally, I'll take the danger with increased power ;-)

    Another potential for cert tweaking involves pulling any certs out of the <root>/var/ssl/crt/ (cirtificate revocation list) folder (they are usually stored there as .gz archives), and placing them into the <root>/var/ssl/certs/ folder. You would have to encounter the error first in order to generate a failed cert.

    Essentially, this would take a FAILED cert and place it in the AUTHORIZED folder. Any subsequent connections would find the previous cert now authorized and poof! it should work.


    One of these days I'm just gonna have to go chill at campus so I can test all this crap out in an isolated event.
    Last edited by jnever1; 12/06/2009 at 08:40 PM.
  2. #22  
    This is just chinese to me. LOL!
  3.    #23  
    For any who are following my uphill battle:

    Adding certs to Cert Manager failed VERIFY_PEER check.
    Adding cacerts.pem to certs failed to resolve VERIFY_PEER, Failed (error 2051).

    Extracting the failed cert from /var/ssl/crl/crl-bundle.crl had no effect on solving issue, most likely due to formatting issues.

    Last certificate cexperiment possible:
    I'm going to try appending (concatenate) the failed cert to cacerts.pem. Specifically, I'm going to reformat the header and trailer lines to reflect a *normal* cert entry in the cacerts.pem file.

    I'm also going to reformat the crl-bundle.crl file to reflect this formatting and then rename the file to a .pem for installation through cert manager.

    I doubt either one will work (I'll find out tomorrow night - necx class) but I would regret leaving this loose end untied.
  4.    #24  
    It all comes down to libcurl and how it's internally processing VERIFY_PEER operations.

    I took my laptop to school and took IE8 to the log-in page after re-direct (all under https/SSL). I formally/permanently imported the SSL certificate from school into IE8 cache. From within IE8 I exported the certificate to <pick-a-name>.crt to my desktop (Tools-->Internet Options-->Content (TAB)-->Certificates (BUTTON)-->Other People (TAB)-->Export BUTTON).

    I then moved the .crt file onto my pre via USB.
    Using the webOS Certificate Manager, I installed/Trusted this certificate.

    School re-direct STILL fails.

    Looking, briefly, into the details of the certificate, it appears that Palm has configured libcurl to be entirely too strict.

    I have the 1.3.1 - SDK. I'll see about getting a complier on the emulator and try to compile a more relaxed libcurl.

    this is not likely to happen tonight as I have to teach myself libcurl's dependencies and learn its scripting conventions... all this from a casual linux user... right.
  5. Dorowan's Avatar
    11 Posts
    Global Posts
    12 Global Posts
    I had the Error 2051 when I wanted to access my home server via https. The server certificate is signed by my own CA. This CA is self signed. The CA is imported in the pre's certificate manager. I can access my mail server with the pre which also uses a certificate signed by my own CA.

    Yesterday I set back my pre with the webOS doctor. I tried to access my home server over https again without having my own CA in the certificate store. The pre's browser asked me wether I trust the certificate and I chosed to always trust it. So without having my own CA in the certificate store and accepting the webserver certificate directly I can access my home server via https.

    I do not know if it will break again if I import my own CA. I am going to try this with the emulator.
  6.    #26  
    I've done everything I can possibly think of with certs. The bottom line for me is that the Welcome to ipsCA Worldwide certificate that my school uses is just *** backwards. I've even noticed basic text errors in some of the descriptors. That said, it's clear that the 1.3.1 itteration of curl/libcurl is just too damn hard on it. Once I figure out how to get a compiler onto the emulator (and eventually, onto my pre) and a terminal, I'll recompile libcurl with cert verification off and be done with all this bs.

    (If anyone can help with the installation of a c compiler, the 'make' command, and, more specifically, terminal access, within the emulator I'd appreciate it.) --> Accomplished
    Last edited by jnever1; 12/11/2009 at 02:57 PM.
  7. #27  
    Hi there,

    I had the same 2035 error during a redirection to a cisco-server.
    Interestingly the following lets me sign in and make the wifi works fine:
    Delete the certificate according according to the server in the certificate manager.
    Open the browser, type in any URL. You'll be redirected to the cisco-login-page.
    You'll be asked to accept the certificate again. Klick "Just for this session". That it.
    I hope that will work with your device as well.

    Btw. I'm using WebOS 1.3.1
  8.    #28  
    I posted this info previously but it seems like the 2035 error people could benefit:
    A problem occurred somewhere in the SSL/TLS handshake. You really want the error buffer and read the message there as it pinpoints the problem slightly more. Could be certificates (file formats, paths, permissions), passwords, and others.
    In other words, the 2035 error is a communication glitch (and is most common with cisco according to Palm). "Refreshing" your cert as dirschl describes might work, and in his case did. As the cURL error text states, however, investigating the error buffer sounds like a more solid direction for troubleshooting as it can be triggered as a result of several malfunctions, some not certificate related.

    Error 2051 has to do with certificate integrity and is thrown when a cert fails verification. More recent verification methods require a larger set of data points to remain 100% consistent across the certificate chain to root (root certificate authority like VeriSign, not root like 'rooting' your pre).
    The remote server's SSL certificate or SSH md5 fingerprint was deemed not OK.
    This method is programmatic, meaning that a programmer can hard code in how much verification he/she wants. If a cert doesn't pass any part of the verification test, that cert is deemed "not OK". Palm's level (I looked at the source code) is like taking a magnifying glass to 10 copies of the same page in several volumes of the same book. On the digital level, 100% duplicity should be simple, however humans fill in the certificate blanks... and we all know about human error.

    My only issue with Palm's treatment to SSL with 1.3.1 on the pre (i haven't been at school to test 1.3.5 ssl) is that they failed to implement a 'procede insecure'.

    That said, my school's cert was charity work (the cert authority they use offers free certs to .EDU institutions) and suffers an insignificant typographical error... well, 1.2.1 insignificant.

    Palm's was a dirty fix to a very distant vulnerability. My goal is to remove SSL verification in its entirety from my pre browser. Connecting to a vulnerable network should be a personal choice IMO.

    If I were a professional hacker/programmer, I would insert appropriate code at an intercept to the error toss that would frontend a button to the error dialog providing the backend option to bypass STOP code and procede (assumedly) insecurely. (Note that in doing so, ssl encryption is unaffected. Only the certificated proof of server identity would be assumed valid) Since I'm not, I'm doing my best to compile cURL with the full verification bypass option enabled with all the necessary dependencies, test/prove it in the emulator, then install it on my pre.

    This hasn't been easy. Documentation from cURL is loose. OpenSSL is a huge project in and of itself. Adding kerberos, compiling, installing, testing, debugging... the mountain looms ominously.
    Last edited by jnever1; 01/01/2010 at 11:01 AM.
  9.    #29  
    The point is 1.3.5 moot. Either my school had their certificate revamped to meet the same security standards that webOS is using (with respect to ssl vulnerability) or Palm found the glitch and threw in the appropriate code to allow/temp-allow/deny certificate trust.

    Either way (or both), wifi ssl-network access is back in effect.

    Not that I need it now that a new semester has started. I don't have any 2 hour gaps between classes to fill with shoutcast radio and homework anymore. >x)
Page 2 of 2 FirstFirst 12

Tags for this Thread

Posting Permissions