Before I installed the certificates I was able to see the page with all the formats.afterwards I can only see the page but only the text, no formats at all, please check the site and you´ll see.
however if you check the site using the server ip address you will be able to see the page as it should be https://104.197.75.120/
so it seems the page is not loading ok using the domain name
There is definitely "mixed content" (content served over http instead of https) on the page though I'm not seeing it being reported by whynopadlock.com or missingpadlock.com. See my next post.
You need to change the following settings in WordPress from "https://104.197.75.120" to "https://salfate.com":
Site Address (URL)
WordPress Address (URL)
Even though https://104.197.75.120 has https in the URL, your SSL/TLS certificate does not (and can not) cover an IP address as the host name. Since https://104.197.75.120 starts with https, whynopadlock.com and missingpadlock.com will both falsely report that there's no mixed content.
I discovered this by viewing the source code of your website with the following address in chrome:
you have no mixed content, because all resources are loaded via https.
Resource in a https page loaded via http -> mixed content.
When a user visits a page served over HTTPS, their connection with the web server is encrypted with TLS and is therefore safeguarded from most sniffers and man-in-the-middle attacks. An HTTPS page that includes content fetched using cleartext HTTP is called a mixed content page. Pages like this are only partially encrypted, leaving the unencrypted content accessible to sniffers and man-in-the-middle attackers. That leaves the pages unsafe.
So it's ok that whynopadlock doesn't report a mixed content error.
But the certificate of the resource is wrong, because the ip address isn't included. So the resource isn't loaded -> your content looks broken / doesn't work.
Such certificates are possible - see https://1.1.1.1/ -, but currently you can't create Letsencrypt certificates with ip addresses. Change your WordPress.
When an invalid certificate is presented for a resource, is that resource fetched over http? My screenshot from Samsung Internet seems to indicate it is so. It might not be a good indication of what's actually happening though.
The error message here is certainly confusing, but I think Jürgen was right to interpret it as an invalid certificate (for the name being used) rather than an HTTP mixed content problem, even though the error message doesn't distinguish these cases very clearly. (The "other resources which are not secure" would usually be HTTP, but here it seems to be a different problem announced with the same warning.)
Maybe the definition of "mixed content" needs to be expanded to include all content that is attempted to be loaded by any insecure means and not just by http (like, for instance, an invalid certificate)?
Does anyone here know specifically if content attempted to be loaded over https (when an invalid certificate is presented) is actually loaded over http by fallback? For my own knowledge I would like to clarify this. The error message in my Samsung Internet screenshot in my post above might be in dire need of clarification if the content is still loaded over https using the key associated with the invalid certificate.
Just for posterity, here's the html source code in question:
Thanks a lot guys, making the changes from https://104.197.75.120 " to " https://salfate.com ":
did the trick,
now the certificate looks legit and the page display properly.
One thing I realised was that the Wordpress address was pointing to http://104.197.75.120 and not to https://104.197.75.120 so maybe that was the reason of the certificate issue.
now I pointed out as recommended by Grifin to https://salfate.com and everything is dandy
Those two settings in WordPress actually cause security woes quite often. I've encountered many WordPress users here who have "http" instead of "https" in those two settings. When combined with an http to https redirect in their webserver configuration, it has often produced a circular http to https to http... redirect. Based on your comment about the setting actually having "http" in it, maybe the WordPress people finally got wise to that particular issue and coded around it. In your case, trying to use a host name (an ip address in this case) that is not covered by the certificate being presented (it only covers your domain name and not your ip address) was the cause of the resources being dropped for being delivered unsecurely. Honestly, I wish there were a simple way to just make a website unreachable when presenting the ip address as the host name. It would safeguard against this hole.
