Hey @eLDog –
Working with HTTPS and SSL certificates, in general, is a complicated topic so I definitely know why it can be confusing. Let’s start by going over in a little more detail what SSL certificates are.
To be specific, HTTPS is a way to securely connect to a site within your web browser. It uses SSL certificates under the hood to ensure that the browser is actually talking to the correct server.
You can think of SSL certificates as a sort of “ID” card, like a passport. It says that your server running coolmat.com is who it says it is.
Let’s imagine for a second that you and I meet in real life. You want to make sure that you are really talking to me, Ben Turner, so you ask for some identification. What happens if I give you a plain business card with my name, “Ben Turner” printed on it - would you trust that it was me?
What if I instead give you an actual passport that says “Ben Turner” on it – would you trust that?
In some cases like if you just wanted website advice, you might accept the business card. In other cases where the consequences might be greater, you would only want to speak to the “Ben Turner” who has a valid passport.
SSL certificates are similar. For a development site running within Local, the “Self-signed” (printed business card) certificate is enough. In your case, you are using the 3.3.0 version of Local which uses a Virtual Machine to manage WordPress sites. Whenever Local was installed, that’s when the Virtual Machine was created. One of the things that is done when creating this VM is creating a self-signed certificate so that all of the Local sites have the option of running over HTTPS.
This is why you are seeing different times for the SSL certificates and the version of OpenSSL between your machine and ours. You could probably re-install everything and get current with those versions, but that’s probably more work than it’s worth.
It’s also important to note that these certificates within Local aren’t being used on the remote, “real” site, so clicking the “Trust” button within Local doesn’t have any effect on the remote site’s SSL certificates. The certificate on the remote site is generated on that specific server, so having an exactly up-to-date SSL certificate on the Local site is more work than it’s worth.
You have another question about a “subdomain development site” that isn’t showing up as HTTPS. That could be due to mixed content warnings, but it’s hard to say. I would first start by trying to access the site over both protocols: secure (HTTPS) and unsecure (HTTP):
From there you can start to zero in on if the SSL certificate has been set up correctly. If you can’t access the site over HTTPS, then I would contact the hosting provider and work with them to finish creating and setting up the certificate.
To your specific questions about what “Mixed Content Warnings” are – they are basically the browser saying “Hey, you told me to load the website over HTTPS, but the page that I’m loading is trying to load other assets (like css or js files) over regular HTTP. Because you wanted this to be a secure connection, I’m not loading those other assets.”
You can imagine that this might be a problem if one of those assets was the site styles for the whole site!
Bottom line is, I think your setup for Local sites is just fine in terms of HTTPS and SSL certificates.