+1 there ought to be a way to load the page anyway. We have, like so very many other companies an internal FQDN for our domain, and an external one strictly for the purpose of email. Why the two? Because of issues that crop up in your local DNS when creating multiple subdomains if the external and internal fqdn is the same.
This is not uncommon. Most SMB's do this. Now either you create a certificate for every server you have, and expensive proposition for some, or you just create the one for the email domain and live with the little dialogs when remoting into servers and such. Not only that but a LOT of things, "copiers etc.) use self signed certs. No company is going to pay for a cert for every device and wildcard certs are pricey. There *always* needs to be a way to accept the certificate anyway. Bob S On Oct 25, 2016, at 07:21 , Ben Rubinstein <benr...@cogapp.com<mailto:benr...@cogapp.com>> wrote: If an "https" site has a misconfigured certificate, most browsers will tell you what the problem is - and generally give you an option (more or less hidden) to ignore the warning and load the resource anyway. Loading the same resource from LC using libURL, the result is "error application verification failure". Is there any way to override the normal test in LC, as one can in a browser, to request that the resource be returned anyway? (The specific issue here is that the certificate has been issued for "www.domain.com<http://www.domain.com/>", but is being used to certify "internaltempmachine.internal.domain.com<http://internaltempmachine.internal.domain.com/>", but I suppose the question is quite general.) I'd be most keen to hear if there is a solution using libURL; but if there isn't, but there is a way using tsNet, that would be good to know. TIA, Ben _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
