There’s more to migrating a complex site to HTTPS than just enabling TLS in your web server or reverse proxy. All links to embedded resources like style sheets, images, or scripts need to be served via HTTPS and potentially have to be rewritten. In a well-designed site that’s not an issue, but in most peoples’ organically grown setups it can be a huge effort.
Recent versions of Google Chrome no longer flag the entire page as insecure, but rather block the offending resource. This is a good thing, but visitors still get a warning about mixed content in their browser’s address bar (see below).
For local references, you can easily find offending references via your server logs, but it’s much harder for externally referenced resources. Fortunately, there is a mechanism called Content Source Policy (CSP) that can help here. While there’s a lot you can do with CSP (see this introduction), one use case is to instruct the browser to send you a report if a plain HTTP resource was requested from an HTTPS page.
As per CSP specification, this works by configuring your server to send an HTTP header like this:
Content-Security-Policy-Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval': report-uri https://example.com/reportingEndpoint
The reporting endpoint points to a server you choose. It receives a JSON POST request and typically logs it to a file. See the excellent Google I/O talk Mythbusting HTTPS: Squashing security’s urban legends for a more detailed explanation. If you don’t want to run your own server, you can use the Report URI service to collect the reports for you.