Once you identify what is causing your HTTPS insecure content warnings, you can plan an approach to fixing them. Start by classifying your warnings in groups, and then look at how each group can be handled.
Scripts and Stylesheets
Scripts (.js) and stylesheets (.css) are resources loaded by your WordPress theme and plugins to alter the look and behaviour of your website. Some themes and plugins load their scripts and stylesheets in non-standard ways that cause warnings on HTTPS. Most of those will be caught and fixed by the Simple fix level in SSL Insecure Content Fixer. If you have warnings from scripts and stylesheets, try this fix level first. It’s the default level, so just installing and activating the plugin might clean up your warnings.
Sometimes scripts and stylesheets are hard-coded into HTML written onto the page. If you have plugins or a theme that is doing that, i.e. the Simple fix level doesn’t fix them, then you should contact the plugin/theme authors and let them know they need to change their ways! If they won’t and you can’t ditch them in favour of another option, then your best bet is probably the Capture fix level.
Images, iframes, embeds
Images, iframes, and embeds (videos, tunes) are usually items in your content area. The best fix for these is to edit the pages affected, and change the URLs of any such items to either be protocol-relative by removing the http: bit, or force them to HTTPS by changing http: to https:
NB: there is an argument each way on this. Protocol-relative links load resources over the same channel as the page itself, and that can be faster on non-HTTPS pages. However, those resources won’t be cached when the visitor goes to an HTTPS page from an HTTP page, so they’ll need to be loaded again. I’d recommend changing http: to https:, but you should assess what is best on your website.
Of course, a quicker and easier fix is to step up the fix level from Simple to something that fixes content errors. Try each in turn to see which one fixes your problems. Don’t pick a level higher than you need, it will only waste server resources needlessly.
Forms that submit to http:
If you have a nice, secure, HTTPS page that has a form on it, that form ought to send its data to a nice, secure HTTPS page. Your visitors will certainly expect as much if they see a padlock on your page. This is why Google Chrome now gives a mixed content warning on forms that send data over HTTP instead of HTTPS.
To fix, you should first verify that the form’s target URL actually does support HTTPS, and then edit the page to change the form action URL to https: or contact the developer who created the form for you.
Currently, SSL Insecure Content Fixer doesn’t fix such forms. I’m assessing the options for that. The biggest issue is that website owners should be alerted to problems with forms that will fail when submitted by HTTPS. The SSL Labs website is a good place for website owners to start.
If you have trouble cleaning up some warnings, ask for help in the support forum.