Domain mapping SSL SSO insecure endpoint mixed content

Getting a mixed content error on all mapped domain with SSL coming from Domain Mapping SSO endpoint (http://mydomain.net/dm-sso-endpoint/1512169588/?dm_action=domainmap-setup-cdsso).

The main domain and it's original sub-domains are HTTP but can't force https on the whole network because it redirects non-SSL mapped domains to https, which cause an insecure content error.

  • Predrag Dubajic
    • Support

    Hi Sean,

    This is our latest release candidate and so far it has passed all the test.

    However I would still suggest testing it on staging site first, or if you're testing it on live site do it when the traffic is low so you can revert back without affecting many users.

    It shouldn't come to that but it's always better to be on the safe side.

    Best regards,
    Predrag

  • Adam Czajczyk
    • Support Gorilla

    Hello Sean!

    The notice is generated by the browser, not by the site. Furthermore, it's a security notice and that's considered as a "critical" kind of notices by browsers/browsers' developer, so I'm afraid there's no way to legitimately "silence" it from the script (WordPress/plugin) level.

    That said, I'm not able to give you any ETA/timeline, I'm afraid. Since this is RC version, I believe a release should be made quite soon.

    Until the this happens, the ways to go here are either to set the network over https or to put a fix into the plugin's code so the WP/plugin would handle those "insecure resources" in a different way. That's what the RC release shared by my colleague previously is supposed to be doing.

    That being said, "testing" on a live site is obviously not a best idea. However, this is an RC version, meaning it's a "release candidate" so it should be stable. Therefore, I suggest creating a staging site (a 1:1 copy of your current site) and putting the plugin there to test. If it works fine there, you should be safe to install it on a live site to (also, you can always revert back to a current official release at any time, simply by replacing plugin files).

    Kind regards,
    Adam

    • Sean
      • Design Lord, Child of Thor

      Thank you for that. So the update will definitely fix this issue, correct? Lastly, if you could, what is the version number of the domain mapping plugin that I'm looking for that will resolve this when it comes out?

      Thanks!

  • Adam Czajczyk
    • Support Gorilla

    Hello Sean!

    I must say that I'm not quite sure why only some sites are affected by this but I believe our developers took a "holistic approach" to this :slight_smile:

    The current version of the plugin is 4.4.2.5 so I believe that the RC with "final touches/tweaks" added should be released quite soon. I don't know exact ETA but I don't think we'd be waiting long.

    Best regards,
    Adam

  • Predrag Dubajic
    • Support

    Hi Sean,

    I'm afraid that this script is not loaded as regular scripts in WP as it has some other functionality behind it so it can't be simply dequeued and then enqueued with HTTPS.

    I did ping devs about it to see if there's a quick change in plugin files that would sort this out and I'm waiting for their feedback.

    Best regards,
    Predrag

  • Adam Czajczyk
    • Support Gorilla

    Hi Sean

    It should be. I understand that you do have Domain Mapping updated to the most recent version and that is still showing up even despite it, right?

    Would you mind granting access to one of the sites affected by this so I could take another look and consult that with our developers? To enable access, please go to the "Nework Admin -> WPMU DEV -> Support" page in the site's back-end and click on "Grant support access" button there, then let me know here once it's done.

    Best regards,
    Adam

  • Predrag Dubajic
    • Support

    Hi Sean,

    Yes, 4.4.3.3 is the latest version and should have this issue fixed.

    Can you check if you have both "Force http/https" for admin and frontend to force use of HTTPS?

    Trace can you please check above settings as well and if you're still having this issue please open up a new ticket and grant support access to your site so we can check your end further as well.
    To enable support access you can follow this guide here:
    https://premium.wpmudev.org/docs/getting-started/getting-support/#chapter-5

    Best regards,
    Predrag

    • Sean
      • Design Lord, Child of Thor

      Hi Predrag,

      Thanks for that.

      We tested this and it seems to solve the issue, but this assumes that all mapped domains and subdomains of the main domain have SSL/TLS. This is not the case with our network. Is there no other way? Why would this need to be set in order for it to work correctly? Should having the main domain set to https not load the correct file?

  • Adam Czajczyk
    • Support Gorilla

    Hi Sean and Trace

    We tested this and it seems to solve the issue, but this assumes that all mapped domains and subdomains of the main domain have SSL/TLS. This is not the case with our network.

    First of all, thank for confirmation.

    As for the question. Yes, it does "assume" this (though that's not exactly what happens but let's stick to that for simplicity) and it's in fact a valid assumption. In a default WP setup whenever you create a new sub-site the protocol (http:// vs. https://) of the new sub-site would follow current protocol of the main site. It's a natural thing for WP to assume that if the Multisite is protected by SSL then all its sub-sits will be protected too.

    That, of course, is easy to change and is not really a "requirement" but apart of obvious security reasons it has other reasons as well: cookies. Login - to a site and "throughout it sub-sites" - requires cookies and that's also true with SSO. The thing with cookies is: secure (set over SSL) cookies are not available for insecure (non-SSL) sites and it's a browser-side restriction.

    Additionally, there's another restriction - browser-side - that is causing a mixed content errors: an SSL-secured site is not allowed to load resources that are insecure (not SSL secured). If it would, that would in fact violate the SSL protection, thus would make the site efficiently insecure. That results in the fact that when there's a "cross-domain login" attempt where secure site attempts to communicate with insecure resources - or rather load them - the mixed content happens and such attempt is blocked by the browser, thus breaking the process.

    That being said, that applies to a standard setup. Having a mix of SSL and non-SSL sub-sites on the Multisite, while perfectly valid, is not exactly a standard WP setup.

    However, I do see the point in making it work with such setup as well. I'm not sure whether this should actually work out of the box with our Domain Mapping that way or not and if not, if there's a reasonable workaround - but I've asked our developers about it so if it's possible to fix or implement I believe they'll be able to find the solution for this.

    Please "stay tuned" and watch this ticket and we'll be updating it as soon as we get to know more.

    Kind regards,
    Adam

    • Sean
      • Design Lord, Child of Thor

      Adam,

      Makes perfect sense.

      Our issue is that this would requires us to get a wildcard SSL for the subdomains on top of getting every domain we map certified. We normally do this at one point or another, but there may be some time where the a new domain has not yet been certified, but we are still using it or working on it (or perhaps for odd reasons some do not want to certify their domain).

      Perhaps a check should happen if the site is https vs http. If the site isn't http (or https whichever your settings are) then yeah don't do SSO, if it is then proceed to SSO?

      Thanks!

  • Adam Czajczyk
    • Support Gorilla

    Hi Sean

    Thank you for explanation!

    Yeah, that makes sense and I do see the point here. Let's see what our developers will come up with then. As I've already reported the case to them, I believe they'll be able to find some reasonable solution for is. I'm awaiting their response (please note: this might take a bit more time than it usually takes us to answer here as they are dealing with a lot of complex stuff on daily basis) and we'll let you know here once we get to know more.

    Best regards,
    Adam

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.