Really Simple SSL incompatible?

• 

  rlankhorst · Member · Oct 25, 2019 at 6:56 am

  • Copy link
  • Add topic to favorites

  Hi, I’m the developer of Really Simple SSL, we’ve been getting an increasing number of support requests from users who can’t install Really Simple SSL on wordpress.com, or for who the premium version won’t work anymore because of this. I see it’s on the ‘incompatible’ list now, but can’t think of a reason for this. I was just wondering if you could give any insights into this?

  The blog I need help with is: (visible only to logged in users)

• 

  kokkieh · Staff · Oct 25, 2019 at 8:02 am

  • Copy link

  Hi there,

  All sites on WordPress.com have SSL enabled by default, and Really Simple SSL causes our SSL configuration to break, so we do not allow it to be installed on WordPress.com business plan sites.

  I see it’s on the ‘incompatible’ list now

  Really Simple SSL has been listed at https://en.support.wordpress.com/incompatible-plugins/ for more than a year, but as of a few months ago we also block it from being installed at all.

• 

  rlankhorst · Member · Oct 26, 2019 at 2:41 pm

  • Copy link

  Hi,

  Thanks for the info. Just curious: What is the part that breaks the SSL configuration? The .htaccess redirect? Do you use .htaccess on wordpress.com?

  Otherwise there’s just a redirect to https if the site is not loaded over https yet.

  As it is, these user’s also can’t use the security headers. As stuff like content security policy is pretty advanced and needs some configuration, I’m guessing it’s not included in your default setup.

• 

  staff-doublebassd · Staff · Oct 26, 2019 at 5:11 pm

  • Copy link

  I know the plugin breaks Facebook sharing by causing a 301 redirect error – we default to http for share count but the plugin tries to force it to https causing a loop.

• 

  rlankhorst · Member · Oct 27, 2019 at 7:45 pm

  • Copy link

  Ah, that explains a lot.

  The solution would be to exclude Facebook bots from the redirect to https (which we do in the social add on), but I don’t think this should be default behavior. Additionally, this approach will keep shares on http forever, which I don’t think is the best way to solve it. Better would be to add shares on https, and keep old shares on http, based on post publish date. This way the shares will gradually move to https.

  But thanks for the explanation, good to know where this came from ;)