Proper TLS certificate on static.askmrrobot.com missing

It is great to see that almost all ressources of AMR can be rewritten to use TLS.
Only the pictures on static.askmrrobot.com can’t because the certificate is not valid for the domain.

Not sure why you are getting that… I just checked and the certificate is still valid. Otherwise you would get all sorts of warnings on e.g. the account pages served over https.

https://www.askmrrobot.com works, but it causes mixed content warnings because pictures like
http://static.askmrrobot.com/wow-icons/spell_monk_brewmaster_spec.jpg are transferred inscurely.

This site only has a valid cert for

 *.vo.msecnd.net, *.adn.azureedge.net, *.ads2.msads.net, *.aspnetcdn.com, *.azurecomcdn.net, *.azureedge.net, *.azureedge-test.net, *.cdn.skype.com, *.cdn.skype.net, *.cmsresources.windowsphone.com, *.cmsresources.windowsphone-int.com, *.dev.skype.com, *.fms.azureedge.net, *.microsoft-sbs-domains.com, *.secure.skypeassets.com, *.secure.skypeassets.net, *.wac.azureedge.net, *.wpc.azureedge.net, *.ec.azureedge.net, *.wpc.ec.azureedge.net, *.wac.ec.azureedge.net, *.adn.ec.azureedge.net, *.fms.ec.azureedge.net, ajax.microsoft.com, cdnads.msads.net, cdn-resources.windowsphone.com, cdn-resources-beta.windowsphone.com, ecnads1.msn.com, iecvlist.microsoft.com, images-cms-pn.windowsphone-int.com, images-cms-tst.windowsphone-int.com, lumiahelptipscdn.microsoft.com, lumiahelptipscdnqa.microsoft.com, lumiahelptipsmscdn.microsoft.com, lumiahelptipsmscdnqa.microsoft.com, montage.msn.com, mscrl.microsoft.com, r20swj13mr.microsoft.com, *.streaming.mediaservices.windows.net, *.origin.mediaservices.windows.net, download.sysinternals.com, amp.azure.net, rt.ms-studiosmedia.com, gtm.ms-studiosmedia.com, *.aisvc.visualstudio.com, *.cdn.powerbi.com, dist.asp.net, embed.powerbi.com, msitembed.powerbi.com, dxtembed.powerbi.com, *.cdn.powerappscdn.net, downloads.subscriptionsint.tfsallin.net, download.my.visualstudio.com, cdn.vsassets.io, cdnppe.vsassets.io, stream.microsoft.com, datafactory.azure.com, *.cortanaanalytics.com, do.skype.com, software-download.office.microsoft.com, software-download.microsoft.com, prss.centralvalidation.com, *.gallerycdn.vsassets.io, *.gallerycdnppe.vsassets.io, global.asazure.windows.net, download.learningdownloadcenter.microsoft.com, www.videobreakdown.com, www.breakdown.me, *.gallerycdntest.vsassets.io, download2.microsoft.com, cp.dsp.microsoft.com, agavecdn.o365weve-dev.com, agavecdn.o365weve-ppe.com, agavecdn.o365weve.com, download.visualstudio.com, *.Applicationinsights.net, *.Applicationinsights.io, *.Applicationinsights.microsoft.com, *.sfbassets.com, *.sfbassets.net, download.mono-project.com, *.streaming.media-test.windows-int.net, *.origin.mediaservices.windows-int.net, *.mp.microsoft.com, download.visualstudio.microsoft.com, software-download.coem.microsoft.com, cdn.wallet.microsoft-ppe.com, cdn.wallet.microsoft.com, vi.microsoft.com, www.videoindexer.ai, *.nuget.org, *.nugettest.org 

not for static.askmrrobot.com.

Securing only the login page won’t help much against determined people trying to get your credentials because the rest of the page can still be modified on the wire.

From the Gear Optimized page.

If you are manually switching to https, you would need to change the css to use image urls that are https also. We do this automatically on our pages designed to work over https, we have separate stylesheets for them.

Also, we have two different certificates, one for the “www” subdomain, and one for all the other subdomains.

I don’t. I just go to www.askmrrobot.com and this warning pops up at chrome console.

Yeah the home page should just be http, not https. It isn’t designed to run as an https page right now.

OK – I think I see what’s up, there is a javascript somewhere that generates an icon URL, and it is hard-coded to the non-https version at the moment. I can see if I can change that, should get rid of the mixed content message for people who want to use https instead of the normal http.

@espenlaub Just to reiterate, we have an ssl certificate for the static (and static2) subdomain, but it is a different certificate than the one for our main site. I’ll check… it could be that those couple icons are coming from a different CDN that doesn’t have the certificate. Regardless, it’s just a couple icons.

Also, there is a second level of authentication required to access any account-related page. The login information that gives you access to the non-https pages is not sufficient by itself to grant access to an account page.