Help Me Test SSL on PowerShell.org

I'd appreciate your help in testing HTTPS/SSL here on PowerShell.org. Right now, it's "voluntary," meaning you have to explicitly ask for https://powershell.org. If you have any problems, please note them in a comment on this article.

Some notes and known problems:

  • Most pages will not show the "lock" address bar icon in your browser, because we're delivering mixed content. For example, the site logo is being hardcoded as http:// by some Javascript in our theme, which I need to sort out.
  • Your connection will be to CloudFlare, which is who issued the certificate you'll see. We've also SSL'd the traffic between them and our server using a DigiCert SSL certificate. We're also going to enable client certificate authentication, so our server will only deliver content to CloudFlare, which then delivers it to you. That's ahead.

I think we can solve the mixed-content problem by forcing HTTPS, which is easy, but I want to make sure it's otherwise working before taking that step. We already have a WordPress plugin in place that's rewriting http:// or https:// with just // in URLs, but there're a couple of places where that plugin isn't able to help, and that's why we're delivering mixed content still.

I'll point out that this is mainly a bonus-points project; because almost everyone logs into the site using an external account, we don't store many passwords (and thus don't transmit them in the clear or otherwise). We don't store or transmit any other personally identifiable information. Still, SSL has some other benefits, and it shouldn't hurt to have it on, so we're giving it a shot.

Thanks!

UPDATES 15 June 2016

  • The Lock icon in browser address bars should be working; we've fixed the mixed-content issues I've found.
  • We're forcing HTTPS.
  • We use CloudFlare; you're getting SSL from you to them, and they're getting (forced) SSL from them to us.
  • We're getting an "A" from SSLLabs and SecurityHeaders.io - thanks for that suggestion, Paal. CloudFlare doesn't let us implement every security header yet, but we've got most of the recommended ones.
Posted in:
About the Author

Don Jones

Profile photo of Don Jones

Don Jones is a Windows PowerShell MVP, author of several Windows PowerShell books (and other IT books), Co-founder and President/CEO of PowerShell.org, PowerShell columnist for Microsoft TechNet Magazine, PowerShell educator, and designer/author of several Windows PowerShell courses (including Microsoft's). Power to the shell!

17 Comments

  1. If you come to site as HTTPS without being logged on first then logging into WordPress site will redirect you back non-HTTPS enabled link

  2. I was automatically using HTTPS when visiting the site, getting the green padlock in Chrome.

    I can't seem to login at the moment, however, using a social account. It goes through the process (all over HTTPS from what I can see) then redirects me to the homepage but still logged out.

    • Now that I am logged in, it appears that I'm being authenticated by IP address? I made some changes to my profile and wanted to see what they look like when not logged in so fired up another browser (that I'm not even signed into the social account on), navigated directly to my profile and was greeted as a logged in user.

      Tried a third browser, my phone, and even a freshly imaged desktop that I've never touched before. All showed up as logged in with the ability to make edits. Given we have one or two public facing IP addresses for a few hundred users... this could be an issue.

      • We don't authenticate by IP address, no. It's more likely you're using a browser which is sharing cookies amongst instances of itself. Authentication on the site is cookie-based. I can't imagine how stupid it would be to try and authenticate by IP address; certainly, WordPress has never done that. And if your test was done with an entirely different brand of browser, then it's entirely possible something else on your network is doing some caching or cookie-handing-over on your behalf, without you realizing it. Believe me, people got some funky stuff going on on their networks. I see a lot of odd behavior traceable to proxies and firewalls.

  3. I can no longer connect from behind my corporate proxy. This could be our setup but reporting for info.
    Error 1409443E:ssl routines:ssl3_read_bytes:tlsv1 alert inappropriate fallback
    The SSL handshake could not be performed.