I have an Iframe that contains a URL that is a self signed https link. In normal case browser ask for add exception of such link but in the iframe it is not allowing to add exception. It is just prompting Error code: sec_error_ca_cert_invalid. Any idea how to prompt for add certificate exception in iframe in case of self signed url's ?

I have an Iframe that contains a URL that is a self signed https link. In normal case browser ask for add exception of such link but in the iframe it is not allowing to add exception. It is just prompting Error code: sec_error_ca_cert_invalid. Any idea how to prompt for add certificate exception in iframe in case of self signed url's ?

• java
• javascript
• html
• iframe
• ssl-certificate

• 4 This would be an incredibly hideously massively bad security hole. If you COULD mark an iframe'd page as 'ignore any ssl warnings', what would there be to stop someone from framing any site they wanted. if they can do XSS attacks on a site with a real cert, and insert a "marked safe" iframe, they could essentially impersonate the real site without any issue. What you want is impossible, and had damn well never bee possible. – Marc B Commented May 5, 2014 at 14:03
• @Marc, I could understand the risk but the URL which will be render inside the iframe is third party url that could have a signed certificate or could be a self signed cert, My requirement is not to 'ignore any ssl warning' BUT to provide the choice to accept the exception or not as same as when this URL open in a browser. – Naveen Ramawat Commented May 5, 2014 at 14:40
• that's not something you can do in html or on the server. you can NOT change client security settings via any remote route. Again, that'd open incredibly hideous security problems. – Marc B Commented May 5, 2014 at 14:42
• How the self signed https url are different when it open in iframe ? When we open in browser than it ask for exception and proceed but why it is not ask for exception in iframe ? I think both are same level of security concern ? either both should not work or should both work. It is partiality :D – Naveen Ramawat Commented May 5, 2014 at 14:49
• 1 Why do you want to do this in the first place? Clearly this is a bad idea for all the reasons already mentioned, but if you post more info about what you are trying to achieve (rather than how you are trying to do it), we may be able to suggest alternative approaches that would be more secure. – steve cook Commented May 15, 2014 at 5:34

2 Answers 2

First, the difference between prompting for an SSL exception for the root document in a window and a document displayed within an iframe is an important security concern. As you note, the user isn't aware of the URL displayed (or in this case, trying to load) in the iframe. If the browser's exception mechanism were displayed in the iframe, the user would see the browser's address bar displaying the URL of the root document -- on a pletely different domain. This could lead to user confusion and, ultimately, an incorrect and unsafe choice from a security perspective.

You should not expect to find a hack/workaround that alters this behavior in modern browsers.

That said, if an iframe will not display the prompt, the simplest workaround is to get a page from the iframe's domain to load as the window's root document and therefore trigger the prompt. Consider the following sequence:

1. User requests www.example./entry
   • Server somehow decides which "dynamic" host to (eventually) load in the iframe, let's call it www.dynamic.example
   • Server REDIRECTs the browser to a well-known URL on the dynamic host: www.dynamic.example/redirect
2. User's browser requests www.dynamic.example/redirect as a normal page load, as the root document in the browser window.
   • www.dynamic.example is using a self-signed certificate, so the browser displays whatever warning/alert/prompt it usually does for sec_error_ca_cert_invalid
   • This is pretty ugly from a user experience point of view, and if the user declines to add a local exception for the certificate, everything stops here.
   • If you're confident that users will add exceptions for the self-signed cert, then upon doing so ...
3. User's browser reloads www.dynamic.example/redirect, this time accepting the self-signed cert per the user's instructions.
   • This URL on www.dynamic.example should immediately REDIRECT back to a different, well-known location on www.example., let's say: www.example./pageWithIFrame
4. User's browser requests www.example./pageWithIFrame
   • This page loads, and contains the iframe that points to something on www.dynamic.example
   • Since the user already accepted www.dynamic.example's self-signed cert, the content in that iframe should be rendered.

This solution uses only HTTP redirects and doesn't necessitate a proxy server or dropping SSL/TLS down to plaintext HTTP. It does, however, require collaboration between your site (www.example.) and any of the other domains with a self-signed cert. It will not work if that other domain provides no way to redirect back to you (e.g. embedding content without that domain's knowledge).

The same redirect chain works with sites that provide certs signed by a trusted CA, too. In that case, step 2 will transition to step 3 immediately without any need for user intervention.

Well, other than delivering a customized Chrome/Firefox/Safari that accepts self-signed certificates the only options you have is:

• to ask the user to add a permanent certificate exception in its web-browser,
• ask the third party to pay for a valid certificate.

There's nothing you can do HTML/JavaScript-wise to "hack your way through".

Edit

Another option is to set up a proxy server between your application (IFRAME) and the third party server (e.g. Apache HTTP Server as Proxy). It could either:

1. strip off the SSL, i.e. convert third party HTTPS into local HTTP,
2. be a fixed-point-HTTPS-URL that a user can white-list.

If your webapp is running in a local Tomcat server (or alike) - e.g. http://tomcat:8080/app/ - the second option can be improved by adding the Apache HTTP Server as a proxy like this:

ProxyPass /app/* http://tomcat:8080/app/*
ProxyPass /3rd/* https://third-party/*

The user would have to access just one URL - your Apache Proxy at default port 80 - http://tomcat/app/.