Hi Rob,
thanks for trying this out. This is absolute possible… We just used this certificate to get it done as quickly as possible. So is there any possibility with Corona to accept this certificate or to trust this site anyway?
Thanks!
Hi Rob
Thanks for following this up. I need to read through it all properly. Just to add to the pot that the SSL on our server is definitely configured properly.
Cheers
D
Laryllan,
Just to let you know, I was able to reproduce your issue on my Android device. In fact, I’ve noticed the following error message in the Android log just before the network Lua listener gets called…
>> I/System.out(19926): ERROR: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
This means that Android does not like/trust the certificate. In fact, my Safari web browser throws a fit about the certificate as well.
But that said, I can look into changing our Android network API to trust all certificates. I imagine if you’re making a request to an untrusted URL from within your own code, then of course you trust it… and iOS, Mac, and Windows appears to ignore certificates anyways.
Doug, what URL are you trying to access?
Everyone,
We’ve just tested doing a newtork.request() with an HTTPS URL having an untrusted certificate on Mac, Windows, iOS, and Android. All platforms return “event.isError” true when the certificate is considered untrusted by the operating system. After discussing it with the rest of the team here, we believe that this is the correct behavior.
So, I would suggest that you connect via HTTP during testing until you are ready to purchase a valid certificate and ready to deploy. That would be my best suggestion.
Just to throw my two cents in Joshua, I’ve got an SSL host I’m using https with, and I am sending gets, posts and everything else back and forth through network request and it’s working great - iOS and Android…
Had trouble with cookie persistence on android, but once my app stored PHP_SESSID on the client, and sent it back in the headers, my servers were happy with everything… Messages, pngs (throw in base64 encoding for that…), it’s all good in https as far as I’m concerned… just various server side (and platform side) hoops to identify - and then jump through…
Hi Joshua,
when I read your first answer I have been really happy. As you wrote:
imagine if you’re making a request to an untrusted URL from within your own code, then of course you trust it…
That’s exactly the point! Although I can understand your point of your second answer (that there should be an error on all devices), it would be great if there would be the possibilty to ignore these errors because I certainly do trust this url.
My problem is a little bit more complicated. The app is thought for our customers as an addition to another one of our products they have bought already. In the app the customers can enter the URL of their own server and the app will communicate with THAT server. So everyone of our customers would have to buy their own valid certificate or to use a non-secure connection via http.
Maybe you and your team can think about it again… It would be really, really helpful if there is the possibility to accept these certificates anyway!
Thanks,
Laryllan
Laryllan,
The reason we decided it was not a good idea was for security reasons. What I didn’t think of at the time was what it the HTTPS URL was expected to point to a trusted website, but a proxy server or host file caused it to be redirected to an untrusted site to steal information. For example, a popular app that wants to verify in-app purchases, but its network requests get redirected to an untrusted site that always responds that everything is verified.
In this case, we think it would actually be better for the developer to opt-in to trusting an invalid certificate (say for testing purposes) instead of making that the default. So, making it a network.request() option would be better. I’m also thinking that providing more error information via the network event such as “connectionError”, “responseTimeout”, or “certificateError” would be useful as well, because right now you cannot identify exactly why the request failed.
I’m sorry about backpedaling on this. I didn’t think it through at the time.
Hi Joshua,
making it a network.request() option would be better
more error information via the network event such as “connectionError”, “responseTimeout”, or “certificateError”
These are great news! Both of these suggestions would help very much! It would be great to get them soon.
Thanks,
Laryllan
Just curious if this issue is addressed. I’m facing the same error with untrusted certificates and would prefer to have it “ignored” rather than facing the requirement to purchase a certificate (which is a technology that’s only about money and not about security, but that’s not the discussion here :-)).
Looking forward to it!
Just curious if this issue is addressed. I’m facing the same error with untrusted certificates and would prefer to have it “ignored” rather than facing the requirement to purchase a certificate (which is a technology that’s only about money and not about security, but that’s not the discussion here :-)).
Looking forward to it!
*bump*
I don’t believe this has been addressed yet.
Rob
Thanks for replying, Rob.
Any idea if its going to be addressed soon?
Best regards,
~Rob
I’ll ask again, but with the current priorities, I’m not sure this will be addressed in the short term. I’ve gone back through the thread and I don’t see a bug report number. Can I get you to file one, so we can keep this on the radar.
Rob
Hey Rob,
I am now also finding myself in need of ignoring a privately signed cert.
*bump*
I don’t believe this has been addressed yet.
Rob
Thanks for replying, Rob.
Any idea if its going to be addressed soon?
Best regards,
~Rob
I’ll ask again, but with the current priorities, I’m not sure this will be addressed in the short term. I’ve gone back through the thread and I don’t see a bug report number. Can I get you to file one, so we can keep this on the radar.
Rob