ERR_INSECURE_RESPONSE handing tips in Javascript

Question

We have a lot of ajax calls from our web application and the thing is all are https request (our IT team mandates), yes we have opened up the headers to allow cross domain. But the problem is we have our own custom certificate used internally for all of our apps so basically I get error when we call ajax:

Failed to load resource: net::ERR_INSECURE_RESPONSE

If I open the URL in browser and accept the certificates the ajax calls works fine. So my question is, is there a way to handle this via Javascript? Or would adding trusted certificate would resolve this issue? Also even after we add trusted certificate would again I face any issue in ajax?

Note: We are testing all these in chrome browser

Answer 1

Yes, adding the certificate to the user's list of trusted certificates would solve your problem. As long as your server is set up to server CORS correctly (and it seems like it is, based on your success after accepting the certificate), the certificate is your only problem.

HTTPS provides two security benefits:

1. You know that the communication channel is secure between you and whoever you're talking to (e.g., when Alice talks to Bob, she know no one else can listen in)
2. You know who you're talking to is really who they claim to be (e.g., when Alice talks to bob.com she's knows it's really the server she knows as bob.com and not an impostor)

The first benefit is automatic. It is guaranteed by the cryptographic protocol and cannot be stripped away (except by very complex attacks on security holes that are usually fixed very quickly).

The second benefit is not strictly a technical benefit: it is a matter of trust. Servers use certificates to link their public key (which grants the first security component) with their own identity. Those public-key certificates are signed by user-trusted institutions called certificate authorities (CAs).

When you try to connect to bob.com, the site gives you a public key to perform secure communication. You're skeptical and say, "Sure, this public key will allow me to talk to you securely, but how do I know you're really bob.com?" The server then gives you a CA-signed certificate that says:

We, the VeriSign certificate authority, who are widely trusted to be thorough in our investigations, hereby attest that the following public key really does truly belong to bob.com:

Public key: ZGdlZGhydGhyaHJ0eWp5cmo...

Verifiably signed,

VeriSign

There are many major certificate authorities who are widely trusted (by operating systems and browsers) to issue a signed certificate if and only if they have reliably verified that a public key really does belong to a domain name. Because your OS already trusts these signatures, we can use them without any confirmation.

When you use a self-signed certificate, no trusted CA has verified that your cert really belongs to your domain name. Anyone can produce a document that says:

Hey, man, this is 100% definitely the public key for bob.com:

Public key: WGdoZmpodHlqa2p1aXl1eWk...

Just trust us, the guys who wrote this note, okay? We're DEFINITELY sure that's the key. The guys who wrote this note are the guys who run bob.com. We promise.

Signed,

The guys who wrote this note

This doesn't have a trusted signature on it. The user must decide if they wish to accept the certificate's attestation that the public key really belongs to bob.com.

Making this decision meaningfully is a difficult process -- you need to inspect the certificate and find a preexisting trusted record of the public key somewhere (or contact a site administrator or help desk representative). In effect, you need have your trust of the certificate come from somewhere, because it isn't coming from the trusted signature of a major certificate authority.

Allowing JavaScript to automatically make this determination of trust makes no sense. The entire point is that the user must decide whether or not the certificate is trustworthy and then make the appropriate modifications to the system's certificate store.

This could hypothetically be done for Ajax requests, but it wouldn't be pretty. You'd need to show the user a browser-UI screen asking if the user wants to trust the self-signed certificate for whatever domain the script is trying to access. Aside from being very disruptive to the browsing experience, this could be dangerously confusing: if I'm on example.com, and suddenly (due to the actions of a script I didn't know about) I'm asked to trust a certificate for bob.com, I might accept it purely based on my trust of example.com.

Either add the certificate to your systems' trusted certificate list, or get it signed by a CA that is already trusted by your systems.

Answer 2

Adding the trusted certificate should be enough if all the AJAX calls are made in the same domain, if they're not of the same domain, using JSONP to get the data with AJAX you wouldn't get the error.

If you would like to know about JSONP, here is an useful link: http://www.sitepoint.com/jsonp-examples/