Self-signed certificates for Accept Hosted and the IFrameCommunicator

[bryanb]

I've got a bit of a follow-up question to this thread on "Is SSL required for localhost development and testing". 

It seems, for Accept.js, that a self-signed certificate on localhost is acceptable for development and testing.

With respect to the Accept Hosted and the IFrameCommunicator, the documentation simply indicates HTTPS is required:

Note: If you plan to use IFrame, you must send the hostedPaymentIFrameCommunicatorUrl parameter in the getHostedPaymentPageRequest method.

Note: You must use HTTPS when using IFrameCommunicator.

For the hostedPaymentIFrameCommunicatorUrl, can the HTTPS certificate be self-signed for development and testing in sandbox or must it be a valid public certificate? I haven't begun testing yet, but if you are checking the validity of the cert, not just it's presence, I'm guessing a a self-signed certificate will be insufficient?

Thx!
Bryan

[Aaron]

Hi @bryanb,

I'm not aware of any particular certificate requirement on our end.

It's important to remember that the communication will be happening within the customer's browser, so any errors resulting from using a self-signed certificate will be generated by the customer's browser.

In general, I would assume that most customers are using default browser settings, while a small group has looser security settings, and another small group has tighter security settings. Knowing this, there's a chance you'd have at least some of your customer's browsers throw an alert regarding the self-signed certificate. Of course, this isn't specific to IFrameCommunicator. To work correctly the hostedPaymentIFrameCommunicatorUrl would point to the same domain as your checkout page (or whatever called the payment form). If you were using a self-signed certificate on that server, your customers would likely have some sort of problem before even getting to the checkout form.

[kgw39]

We use self-signed certificates in test without issue.  You just have to add the exception for your test website.

As far as entering the data in the form and the iFrameComunicator not redirecting to the page, we just ran in to the issue with a blocked frame error in Chrome.  Google has just fixed a bug in version 60, Firefox is working on theirs and IE, well….

https://www.chromestatus.com/feature/4678102647046144

We were incorrectly setting the X-Frame-Options to SAMEORIGIN and their were javascript errors on the page from Chrome 60 on.  Chrome < 60 worked fine.  Look for javascript errors on the page in Chrome Tools or whatever you are using.

You’ll have to remove the X-Frame-Origin (bad!) or set the X-Frame-Origin header to your domain.

[tarekhamou]

Refused to display 'https://websitename.local/en-us/checkout/IFrameCommunicator/#action=resizeWindow&width=1000&height=6...' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

This error appears in Chrome and not in FireFox.

[Aaron]

Hi @tarekhamou,

Chrome recently changed how it handles "sameorigin". See details in this thread.