Major bug with domain mapping and forcing http/https

Domain mapping on a multisite network is a difficult because at best we can use a wildcard domain which allows SSL in admin areas network-wide and site-wide on the primary site on the network, but not on mapped domains of subsites. This isn't a big deal, it's just hard to get working properly.

I'm not sure how long this has been an issue, but I've noticed all sites on my network (including the primary site) are accessible via either http or https. This is a major issue for SEO and usability, it should redirect to one or the other.

I thought this may be just an issue with my network, but I noticed that Edublogs.org has the exact same issues where (I assume) you use the same plugin for domain mapping.

There should be an option in domain mapping (or just detect config) to set the primary network site as http or https and always force it. Mapped domains on all network subsites should always be forced http since there's no way (that I know of) to have a separate SSL cert for a mapped domain on each network sub site.

I think SSL has become more important lately with all of the recent security issues. I also know that WordPress is moving to SSL as well. WordPress.com now forces SSL and the core team has some things in the works. Google is also starting to reward sites who https, which is much faster these days with SPDY support.

Thoughts?

  • Jack Kitterhing

    Hi there @Gabe,

    Hope you're well today! :slight_smile:

    I can certainly see what you mean here, there is a way to have the mapped domains have their own SSL with one dedicated IP, using a Multi-Domain SSL https://www.globalsign.co.uk/ssl/multi-domain-ssl/

    What was your thoughts here, have say a checkbox option to force http or https in the plugin? Or maybe even a per site switch in the network admin > sites list?

    Thanks!

    Kind Regards
    Jack.

  • Gabe

    @Jack Kitterhing

    I think the first step would be to fix the bug that allows a site to display as both http or https. I've never seen a situation where that was desired, it's always considered an error.

    Now that I think about it, whether a site is http or https is usually set at the server level or in the wp-config, it'd be too inefficient to define it in a plugin. Wouldn't you think so?

    That said, fixing the bug allowing a site to display as both http and https may fix the whole issue since whatever is set by the server is forced.

    The only issue may be that different hosts/sites have different ways of forcing https, but maybe there's a way to universally detect it. Though I guess unless SSL is explicitly defined, it may be safe to assume http. Thoughts?

  • Gabe

    @Max yeah, they've made some awesome improvements to the plugin this year, particularly in reference to SSO and SSL support.

    I doubt they'll put it at the plugin level since it's inefficient (website slow downs), but it might make sense to do in the sunrise.php or wp-config like how WordPress normally handles it.

    99.9% of multisite networks that use SSL will force it in the admin area network wide (domain.com/wp-admin and subdomain.domain.com/wp-admin), keep mapped domains as HTTP (http://mappeddoman.com), and may or may not force HTTPS on the primary site frontend (http://domain.com or https://domain.com).

    Since that's true in the vast majority of cases, I'd first evaluate how many people are actually in a situation where a per site setting would useful first since multi-domain SSL is prohibitively expensive on larger networks ($100/site/yr). My guess is that many will say they want it, but most won't use it since it's so expensive.

    It just sounds like a lot of complexity (e.g. per-site settings) to add to an already complex situation (e.g. the current plugin doesn't even work correctly) without first validating the need for it. It'd probably be smart to just fix the bug first, then reevaluate. Thoughts?

    Additionally, we're looking at some improvements to SSL in 4.0 of core coming next month (sorry for bad formatting):

    Component: Security (4 matches)
    Ticket Summary Owner Type Priority Version Severity
    #27954 Add FORCE_SSL option to enable HTTPS everywhere on the site johnbillion task (blessed) normal trunk normal
    #28426 An HTTPS scheme in siteurl is ignored enhancement normal normal
    #28487 Introduce a function to determine if the scheme of a URL is https enhancement normal normal
    #28427 All cookies should be secure when home and siteurl use HTTPS johnbillion enhancement low minor

  • wp.network

    Hey @Gabe, again you kinda rock :slight_smile:

    99.9% of multisite networks that use SSL will force it in the admin area network wide (domain.com/wp-admin and subdomain.domain.com/wp-admin), keep mapped domains as HTTP (http://mappeddoman.com), and may or may not force HTTPS on the primary site frontend (http://domain.com or https://domain.com).

    With maybe a quibble on the decimal, I absolutely agree.

    The only reason I imagine that an option to force SSL for only login vs all admin would be nice is server load/performance related, but I don't know if this would actually be a significant load.

    I agree with you about the economics of the MultiDomain Certificates, though I believe that COMODO offers one thats a bit cheaper ($2500/y with all 100 slots filled?).

    I'm beginning to understand that the issues involved here are a lot deeper than I had blithely thought. So it goes... :slight_smile:

    (In the past I have relied on Yoast's SEO plugin to force the whole site HTTP or HTTPS if needed, but I didn't want to even bring that into this if I could help it.)

    I do think that overall, there is a great value proposition in using WIldcard SSL Certs with subdomains. Its all about building value around security.

    If securing login as well as the entire backend is what makes sense, then I'm all for that solution. I had wondered about user cookies working... (again, I'm really glad you've posted some of your recent support questions.)

    Regarding the central login at the primary, then a redirect to the user's site... again, I'm all for whatever is the more effective and workable solution - the sooner the better. :slight_smile:

    My main thoughts on the login at primary model are about branding. Yes, I appreciate the opportunity it gives to rep my platform, I also would love to give my clients the abiltiy to individually co-brand 'their' login page... does that make sense? If Ultimate Branding would work in this scenario, then that would do the trick, yes?

    Regards & Aloha,
    Max

    • Gabe

      @Max That makes sense.

      As for the performance issue, if your host supports SPDY (a technology Google and Automattic [using nginx] helped develop) then HTTPS can actually end up being faster than HTTP[1].

      In the next few years we'll start to migrate to a mostly SSL web, especially as Google starts to give SSL sites a rankings boost.

      Note: [1]

      SPDY, a networking protocol primarily developed by Google that you can enable for SSL traffic, is awesome. It makes your website faster and funnily enough that means that your fully SSLed site could actually be faster for those people who visit your site with modern browsers than your plain http site.

      From this article.

      • wp.network

        Hey @Aurelio

        Glad to see you updated your plan! I was headed to the keyboard to point out this comment from the lead dev:

        We have two approaches based on your need: [...] 2) Customer wants all of his website under SSL, then they can order an ssl cert for their domain, with the coming release of domain mapping you have the ability to force the mapped domain to use either http or https

        from https://premium.wpmudev.org/forums/topic/i-see-a-number-of-threads-but-not-clear-which-one-would

        I guess now that you may already have seen this...

        I'm glad to hear your high opinion of the plugin! I am not an able coder myself, so I always value the insights of those who are.

        Personally, I'm not ready to move to full HTTPS, but the backend and some 'original' address checkout pages will be awesome meantime :slight_smile:

        Cheers, Max

        • Aurelio

          Hi Max,
          I should add that buying a certificate does not make a website more secure nor does it decide if you use SSL. There are plenty of geeks that just want their self-signed certificate to be applied for their friends and family, which you can roll with any Linux distro. Actually, in a way it can be more secure because once you approve it then you get warned any time it changes to re-approve. "Buying" a certificate lets the commercial SSL authority system decide if it's considered secure and gives it a pretty face, that some geeks don't care about one way or another. I'm sure you're familiar with certificate errors which don't mean it's not encrypted, just that it's not approved by the authorities.
          Buying a certificate just gets rid of "application designed errors", where a browser or program is designed to check with a certificate authority, etc.
          That aside, there are plenty of options, but first thing is respecting what the web admin decides, to use SSL or not and where, at least in my mindset. To an end user I would surely explain the advantages and caveats of self-signed certificates anyone can use anywhere to encrypt the whole thing without paying a dime, but the price to pay in deliberately scarey error messages to the less versed and constant "warnings" is not worth it for most.

  • Jack Kitterhing

    Hi there @Gabe and @Max,

    Hope you're both well today!

    I've notified the lead developer about this issue, from testing I can certainly see what you mean, though I can't get it forcing https on all sites? I can try to access a site via https and I get the warning message, as of course I don't have a SSL on that domain.

    Though that is the same for any domain and wouldn't be WordPress specific.

    Say for example, you have a html site running a SSL on domain.com and then you have a sub domain of say sub.domain.com another pure HTML site, no SSL, you'll get the SSL warning, but it'll still allow connection via https if you accept the security warning from your browser.

    But I do agree, that domain mapping should have some form of workaround for this, so it redirects those requests.

    Kind Regards
    Jack.

    • Gabe

      @Jack Kitterhing

      Thanks for checking it out. Yeah, I agree that the issue is common for all websites, but it's still a bug.

      Any webpage that uses SSL should force https and any webpage that does not use SSL should force http so that all visitors are redirected to the correct version of the site. If you check out WordPress.com, Yoast.com, or any other authoritative site they will properly redirect you to https if you enter the http version of the site.

      If users can access both versions of the website so can search engines, which leads to duplicate content and other issues. Unfortunately, most websites are incorrectly configured and it's so common that many believe that it's acceptable, but it's not. Allowing users to use both http and https is tantamount to allowing both the www and non-www (naked) version of a site to be used.

    • Aurelio

      Hi Jack, for what it's worth, the plugin I used before this, Wordpress MU Domain Mapping plugin by Donncha O Caoimh kept SSL as I directed. In a way, it wasn't as refined as this one. If I had https set for URLs, it was everywhere, front and back on all sites, which is what I wanted.
      I rejoined and switched to this for the session/cookie synching, but noticed right away it over-rode my settings to set http specifically on the front ends while keeping admin areas https.
      It seemed fairly deliberate and sophisticated.
      I've seen other code that does the same thing, presumably setting http to avoid front end cert errors and I'm wondering if this does the same thing and if that feature/filter can be disabled.
      An "all or nothing" encryption option is better than "half or nothing" :slight_smile:

  • wp.network

    I agree with @Gabe absolutely on this topic.

    Allowing users to use both http and https is tantamount to allowing both the www and non-www (naked) version of a site to be used.

    SEO impacts have been a major driver of my interest in explicitly forcing HTTP or HTTPS in using Domain Mapping.

    That evolving security considerations create the need to have HTTPS over at least the login and backend seems fairly obvious to me (esp. in a premium product/service). It may complicate the situation, but is never the less increasingly a market reality. I'f I'm going to be competitive, I need to at least keep pace.

    The technical and cost constraints of most SSL certificates, and the prevalence of cpanel at many hosts, seem to indicate that using WP Multisite to offer fully HTTPS networks is rather impractical at this time.

    For now it seems to me to be most approachable to run the frontend over HTTP and the backend over HTTPS... and that brings us back to this thread.

  • Jack Kitterhing

    Hi there @Max and @Gabe,

    Hope you're both well today, i certainly 100% agree on this.

    I have notified the lead developer of Domain Mapping, but in the mean time we should be able to do this with your .htaccess rules, can you paste your current .htaccess please? :slight_smile:

    It may not work, but I'm pretty confident that this can be done the .htaccess way. :slight_smile:

    Thanks!

    Kind Regards
    Jack.

    • Gabe

      @Jack Kitterhing

      My .htaccess is below. I'm using WP Engine. Have you testing setting it in the .htaccess on a multisite network with https in the admin area and http on the front-end for mapped domains? I assumed that'd cause issues. Seems like there'd be more flexibility to do it in the sunrise.php or something.

      RewriteEngine On
      RewriteBase /
      RewriteRule ^index\.php$ - [L]
      
      # uploaded files
      RewriteRule ^files/(.+) wp-includes/ms-files.php?file=$1 [L]
      
      # add a trailing slash to /wp-admin
      RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
      
      RewriteCond %{REQUEST_FILENAME} -f [OR]
      RewriteCond %{REQUEST_FILENAME} -d
      RewriteRule ^ - [L]
      RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
      RewriteRule ^(.*\.php)$ $1 [L]
      RewriteRule . index.php [L]
  • wp.network

    My .htaccess (and I'm at SiteGround, fyi)

    Also, I have done my best to deactivate all of SiteGround's caching systems for the moment, but obviously there are some lines in here about caching. Not knowing any better, I have left things as I found them... I can easily ask my host about the caching stuff if needed. Please advise. :slight_smile:

    # BEGIN WordPress
    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^index\.php$ - [L]
    
    # add a trailing slash to /wp-admin
    RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
    
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
    RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
    RewriteRule ^(.*\.php)$ $1 [L]
    RewriteRule . index.php [L]
    </IfModule>
    
    # END WordPress
    # compress text, html, javascript, css, xml:
    <IfModule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE application/xhtml+xml
    AddOutputFilterByType DEFLATE application/rss+xml
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/x-javascript
    AddType x-font/otf .otf
    AddType x-font/ttf .ttf
    AddType x-font/eot .eot
    AddType x-font/woff .woff
    AddType image/x-icon .ico
    AddType image/png .png
    </IfModule>
    
    ## EXPIRES CACHING ##
    <IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpg "access 1 year"
    ExpiresByType image/jpeg "access 1 year"
    ExpiresByType image/gif "access 1 year"
    ExpiresByType image/png "access 1 year"
    ExpiresByType text/css "access 1 month"
    ExpiresByType application/pdf "access 1 month"
    ExpiresByType text/x-javascript "access 1 month"
    ExpiresByType application/x-shockwave-flash "access 1 month"
    ExpiresByType image/x-icon "access 1 year"
    ExpiresDefault "access 2 days"
    </IfModule>
    ## EXPIRES CACHING ##
  • Jack Kitterhing

    Hi there @Gabe and @Max,

    Hope you're both well today! :slight_smile:

    You'll be pleased to know that after discussing this with the lead developer of Domain Mapping today, we'll implementing a few options.

    These are to force http or https on the front-side or admin side (you can control each individually), then another setting that controls it for the mapped domains, so that same option will be available for mapped domains and the primary domains, if that makes sense?

    This should resolve this for you, once implemented. :slight_smile:

    Thank you!

    Kind Regards
    Jack

  • wp.network

    Hey @Jack Kitterhing

    Any words on this?

    Assuming the answer can only be somewhat vague, if its at all feasible I'd love to get some help with temporary but functional .htaccess rules to apply as a rough work-around patch until the release is ready, as you above indicated might be possible.

    I have a thread going here for the issue, and of course if @Gabe has any input I'd love to hear it. If this is just a real tough cookie, perhaps I'm best served in waiting for the release? I'm too new at htaccess to knowingly discern.

    Kind Regards,
    Max

  • Jack Kitterhing

    Hi there Max,

    Hope you're well today! :slight_smile:

    We're hoping for we'll have it released next week, I can't give a exact date and of course that may slip, but that's a extremely rough ETA.

    Personally I'd recommend waiting for this release, it'll be a lot easier to use than .htaccess and personally I still haven't got .htaccess rules that would work for what you and Gabe need.

    Thank you!

    Kind Regards
    Jack.

    • Aurelio

      Hi Jack,
      Any word on ETA for this fix? Does this week still look good? I would rather not remove domain mapping and go back to my old plugin just to go back to this one again since it's one of the less trivial ones to install and config (both this and my old one). Not too bad but a little pain and risk making big changes like this. My site's not really as safe anymore because it pops into http even on some front end logins, and it's so smooth you have to really pay attention if the login is over http now. Plus user activity and session info is no longer as protected I think. I changed a lot of things to http because trying to push https was now breaking views with so much redirected to http.
      I like the idea of a per-site setting, though that sounds like more work for developer, but if you guys can pull it off it'd be cool :slight_smile:.
      The main thing I need is for it to stop redirecting my front ends to http, if I have the site set to https, as I bought a multisite certificate for this network and I can't use the same secure verbiage anymore until I fix this one way or another. I really like the convenience of the cookie synching though and aside from pushing things to http (or breaking https views if I try to force or work around it sometimes), I really like this plugin, but I'm hoping for an ETA to help plan around. thank you!

      • wp.network

        hey @Aurelio... my guess is that they're working on it, and will get it out asap, which could be soon or possibly later... :slight_smile:

        While my use case is for a Wildcard SSL at the moment, I dig what you're saying!

        I'm basically hoping to see the functionality of the WP HTTPS plugin taken care of by DM: allowing for various configurations (from single/wildcard certs for backends to UCC certs or SNI to include frontends).

        Perhaps some of these options would effectively require the network to be treated as a 'closed network' wherein user signup and site creation is not fully automated, requiring admin intervention... idk :slight_smile: I do look forward to the release!

        Cheers, Max

  • Jack Kitterhing

    Hiya @Aurelio and Max,

    Hope you're both well today! :slight_smile:

    We are indeed working on this and hope to get it out ASAP, I can't give a exact ETA, but on how it's currently going I would say around (1-2) weeks, as we still have some development work to do and then need to test to make sure it all functions correctly and won't break your sites in anyway of course! :slight_smile:

    Hopefully we'll have it out ASAP.

    We really appreciate everyone's patience on this.

    Kind Regards
    Jack.

  • David Labbe

    @Jack Kitterhing I domain mapped one of my subsites and I need the front and admin to be https. However, only the front end is https and the admin for the mapped domain is http. The settings for the mapped domain on the subsite is set for https, but it is not working for the admin.
    You stated above that the developers are making it so https will be controlled on a per site bases (admin side and front end) as well as the primary site of the network.
    I see in the main settings for the Domain Mapping plugin I can set the main site to either http or https for the front side and admin side, but child sites has only the https/http setting and does not specify admin or front side.
    I am a little confused, but what I need is to make a child site/subsite that is domain mapped https for both the front and admin side.

    • Aurelio

      Hi David,
      If this is not really working I would like to know.
      I joined this discussion because when I first came over to WPMU the SSL was not working right and I had to revert to my old custom setup, to force SSL everywhere.
      I admit, I am a little lazy and this kind of setup, multisite with SSL is time consuming to set up as a test to make sure I don't break my main site, etc.
      WPMU multisite domain mapping didn't work with my old SSL everywhere setup but in a test I am working on here and there the options seem fantastic and it seems to work right.
      I will devote more time to it this weekend, and I realize the burden testing and waiting for this kind of setup fix, on a dummy multisite, independent IPs and SSL everywhere site (who has an extra one of those lying around?).
      In my first tests everything seems to work perfect. Please let WPMU know anything they ask on the site and let us know if it's really not working as intended. I barely reinstalled this on a new test site as I'm getting ready to really try to make the switch back to WPMU domain mapping but so far it seems great, but this is a complex question and I'd really like to know where it's not working and in what situations.
      Thank you so much!
      Aurelio

    • Aurelio

      Hi TiViSM,
      If he starts a new thread, can you let us who are subscribed to this one know an easy way to connect the two? This seems very relevant to the question we had, which I think is solved now but I didn't get the update in this thread??
      I am working on testing a new multisite, to see if I can move my other multisite, multiple IPs, multiple site certs, etc. to this plugin and I realize I am late doing so. I didn't realize this was fixed but want to keep on top of any issues others have utilizing the new options.
      Thank you!

  • e

    A few points I'd like to make having gone through this thread quickly.

    1) You absolutely do not need a multi-domain cert to get multiple SSL running off of a single IP. As was stated before, you can use SNI, which is ubiquitous.

    2) Cloudflare now supplies every single domain with an SSL cert. It's important to remember that this from the user to Cloudflare only, so it is still insecure to transport it to your server. However, you can use your firewall rules to only accept traffic that is proxied through Cloudflare which would effectively secure that pipe.

    Thus, you can force your customers to use Cloudflare for their DNS (and thus their SSL). That does mean you can't use the "verification" feature, though.

    3) .htaccess really isn't the right place to control proto, architecture wise. It should be handled by the application itself. This is because the proto/host that is being processed by the app server could very well not be the same as the one that was accessed. For example, if you're behind a load balancer or reverse proxy - or more importantly, you're having the proxy handle SSL termination.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.