21

I'm trying to make Cross-Domain webservice calls from an HTTP page to an HTTPS service.

I have set up the proper CORS headers on the server (it works with HTTP-HTTP and HTTPS-HTTPS).

It does work if I change the requests to JSONp.

What I'm seeing in Chrome and Firefox is the HTTPS request is never sent, it's immediately aborted, and the server never sees the request.

It is worth noting that the preflight OPTIONS request is aborted (and it doesn't reach the server).

I can't find any source that explains that this is indeed not possible (HTTP to HTTPS) and better yet: explains why. I can understand HTTPS to HTTP is unsafe, but the othe way around should be fine right? It seems silly to me because JSONp works (but it's messy).

notes

I also have withCredentials set to true and I'm sending some custom headers and a custom Content-Type: application/json

I'm using the regular XMLHTTPRequest with fallbacks to JSONp for IE<=9

Halcyon
  • 57,230
  • 10
  • 89
  • 128

2 Answers2

12

Ok, I figured it out. The certificate I'm using for the HTTPS domain is self-signed and unverified. Adding it to the list of trusted third-party authorities fixed it for me.

You can install the certificate in Windows 7 through IE. This worked for me: http://productforums.google.com/forum/#!topic/chrome/bds-Ao9LigA%5B1-25%5D post by zacharysyoung 2/11/09 Make sure you run IE(9) as administrator or the install will fail even-though it says it installed it correctly.

  1. Open Internet Explorer (IE) and navigate to the site hosting the self-signed certificate.
  2. IE should display a page warning that, 'There is a problem with this web site's security certificate.'
  3. Click the, 'Continue to this website (not recommended)' link.
  4. Once the page has loaded, look to the right of the address bar. A red/pink button, labeled 'Certificate Error,' should be visible. Click that button.
  5. A pop-up, titled 'Untrusted Certificate,' will appear. Click the 'View certificates' link at the bottom of the pop-up.
  6. Another pop-up, titled 'Certificate,' will appear. Click the 'Install Certificate...' button.
  7. The 'Certificate Import Wizard' will be started. Click the 'Next' button.
  8. ** For XP: a. Leave 'Automatically select the certificate...' option selected, and click the 'Next' button. ** For Vista: a. Choose 'Place all certificates in the following store' option, and click the 'Browse' button. b. Click the 'Show physica stores' checkbox. c. Expand the 'Third-Party Root Certification Authorities' folder, and choose 'Local Computer'. Click the 'OK' button. d. Click the 'Next' button.
  9. This should display the 'Completing the Certificate Import Wizard' dialog. Click the 'Finish' button.
  10. A 'Security Warning' pop-up will appear. The warning is informing you that the certificate's origin cannot actually be validated. You should know where the certificate is coming from. If you do, click the 'Yes' button to install the certificate.
  11. A final pop-up informing you that, 'The import was successful,' will be displayed. Click the 'OK' button.
  12. Restart/Open Chrome and navigate to the site in question. You should not be greeted by the security warning page.

Aside from that, I think I may have discovered a bug in Chrome. See: https://code.google.com/p/chromium/issues/detail?id=141839

Halcyon
  • 57,230
  • 10
  • 89
  • 128
  • Super helpful. For others looking, Firefox will silently abort the OPTIONS request if the ssl cert has problems. I just fixed it by going directly to the domain and adding an exception for my local self-signed. After that the OPTIONS requests worked just fine – mrgreenfur Apr 23 '16 at 20:30
1

It might be easier to setup something like easyXDM. It is rather quick to get going and will do all the backwards compatibility for you (all the way to IE6). It might not be the home-grown solution you are looking for but if you want cross-domain (where you have access to both sides) in a hurry it fits the bill.

You could always write your own iframe (postMessage) interface but why re-invent the wheel (and don't forget to set your document.domain if you are using different sub-domains).

SciSpear
  • 2,008
  • 18
  • 18
  • I have an implementation that works (JSONp). But I want to know _why_ Chrome and Firefox and blocking HTTP to HTTPS requests. easyXDM looks unmaintained, untidy, completely feature bloated and it requires .. Flash? An iframe fallback might be interesting if I want to do uploads or really large requests, but for now, I have no such requirements. I am also not 'in a hurry'. – Halcyon Jul 27 '12 at 15:27
  • For individual browsers the protocols have very large implications around privacy and security. New browsers do have "Content-Security-Policy" but not sure if it is cross protocol. I Might have jumped the gun in offering a solution but the [community for easyXDM](https://groups.google.com/forum/?fromgroups#!forum/easyxdm) is still out there. I believe the last change was less then a month ago (it is just pretty stable and does not need any new features). As for as flash, it is used as a fallback when postMessage is not an option but it does have a large (overkill) feature-set. – SciSpear Jul 27 '12 at 16:29
  • I am not sure what your market really is but you might also be able to try [CORS](https://developer.mozilla.org/en/http_access_control) and/or "Access-Control-Allow-Origin". Again those are really directed toward cross-domain and not cross-protocol (but might be able to sneak by with one). – SciSpear Jul 27 '12 at 16:35
  • I am using CORS .. I thought I mentioned that? What is cross-protocol? – Halcyon Jul 28 '12 at 10:14
  • Looks like I am oblivious to the world around me sometime (working too many hours I guess). HTTP & HTTPS are different protocols is what I meant by cross-protocol. Anyway [W3C CORS](http://www.w3.org/TR/cors/#resource-security) mentions the user-agent can be considered independent of the page policy; and in turn will probably prevent https to http calls. – SciSpear Aug 03 '12 at 15:46
  • 1
    HTTPS to HTTP sure, I can understand that, but HTTP to HTTPS? – Halcyon Aug 03 '12 at 16:18
  • I understand what you are saying (and I do have a few choice words for the w3c group in general), but http->https breaks the fundamental decision that [different protocol === different site/domains](https://developer.mozilla.org/en-US/docs/Same_origin_policy_for_JavaScript). It is not going change, but you could write your own postMessage stuff like I suggested in the response (and I came across a [postMessage](http://postmessage.freebaseapps.com/) wrapper lib that will make it easier). – SciSpear Aug 04 '12 at 00:38