LiveCode Forums.

I'm posting preliminary findings, as it may be a big deal to others as well.

I installed latest Mac security update, 10.8.5, onto 3 machines today.
My software communications to internet now fail 100% of the time.

Testing in the IDE, I can restore functionality on a test machine running 10.8.5 by converting calls to use http: instead of https:

Will file as bug once I learn more, but I'm not in a position to know if Apple or Rev is source of the problem, though it was Apples's recent change that revealed the issue.

Cheers
Bruce

What's the error message you get when the failure occurs?

I just get silence, I believe--but I need to go back and make the I checked the result

All I have had time to do is change all POST calls to http instead of https. This completely fixes. I have not tried libURL

I did learn that it is broken on all recent Mac OSX updates:
10.8.5
10.7.5
10.6.8

I hope to characterize further and file bug report this weekend

I have been having a lot of problems with POST code that worked in spring but fails now, returning nothing in it, nothing in the result

We have made changes in security, so I cannot ascribe to livecode vs. server changes here...

rbrucep wrote:We have made changes in security, so I cannot ascribe to livecode vs. server changes here...

I wonder if it's a certificate that's valid but not signed for its domain.

What happens if you add this before your HTTPS calls?:

libUrlSetSSLVerification false

My client started receiving occasional SSL certificate errors after he did the OS X security update, when my app issued an https POST command. That may be related to what you're seeing, but he doesn't get it every time and I assumed it was a normal error due to an expired certificate somewhere down the line. But check the result in your script and see if you're getting the same thing.

If it is the same error, I'd like to know. For now I've turned off authentication (libURLSetVerification false) but I'd rather not have to do that.

D'OH

I'm somehow continually surprised by the need for 'the return'; I foolishly assume that info would be in 'it'

Here is what shows up in 'the return' for failed POST to https:


error -Error with certificate at depth: 1 issuer = /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root subject = /C=US/O=Internet2/OU=InCommon/CN=InCommon Server CA err 20:unable to get local issuer certificate

I'm assuming this is an issue that must be solved on the LC end, but I am not a smart man.

Thanks for the libURL tip; will try that when I next get an opportunity

What happens if you add this before your HTTPS calls?:

libUrlSetSSLVerification false

Yup, same error my client is getting, and it did just start after the security update. The only difference is that his is at level 2. Try what Richard suggested, it's what I did.

I'm wondering if this is something that RR needs to fix though. It's hard to tell.

Filed as bug
11211
Will update when I receive feedback

Turning off SSL verification was not something my IT guy was thrilled about; I work around by using http instead, which is probably a step down from there.

FYI, I was pointed at an older post with this line of code

--set the sslCertificates to "/usr/share/curl/curl-ca-bundle.crt"

It fails with different error; I'm wondering if it's a symptom of the same disease--LC is looking in the wrong place or wrong way for things that have changed since latest security update

rbrucep wrote:Filed as bug
11211
Will update when I receive feedback

Thanks for filing the report. I've added myself as CC there, and look forward to seeing its progress.

Turning off SSL verification was not something my IT guy was thrilled about; I work around by using http instead, which is probably a step down from there.

Most definitely. Of course we'd like to maintain the verification if possible, but until that's resolved using HTTP is indeed far less secure, since even an unverified cert will still encrypt all traffic, while HTTP will make all traffic fully exposed as plain text.

Has there been any progress on this issue. I see the bug #11211 was confirmed. Does it still exist in OS X 10.9?

I am seeing this when using the updater from the GLX framework to connect to an https site to check for updates to the application.

Martin Koob

I have just tested getting a URL from a site with https using LC 6.5.1 on Mac OS X 8.5 and it returns the error

error -Error with certificate at depth: 2 issuer = /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA subject = /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA err 10:certificate has expired

I tested again with LC 6.7.0 DP-2 and no error was returned. Has this been fixed? Can someone else confirm this?

Thanks.

Martin

Do you know if the certificate has really expired? If so, then the bug is in 6.7 and it should not have accepted the certificate as valid.

The bug report in the QCC is about LiveCode being unable to find any certificates in OS X. That was fixed recently. But the error you're getting concerns the validity of a certificate that was found, which could actually be true.

Hi Jacque

The certificate is on my server that is the backend for my app. I checked with the hosting company who also provides the certificate and it is good till the end of this year.
Safari also shows the certificate as valid when I connect to my site. So from that I gather that it is not a problem with an expired certificate, do you think I am on solid ground on this?
If that is the case that the fix in LC 6.7.0 is what has resolved the issue.

Martin

Yes, the fix may have resolved it if the certificate in question is the one that is client-side and not server-side. So you're probably okay.