After the conversion of all outgoing links to HTTPS, I now get this error.

enter image description here

I get that error for, near as I can tell, for any page rooted at http://stackexchange.com/ but not for subdomains, such as http://meta.stackexchange.com/. The offending source is <script src="https://edge.quantserve.com/quant.js"></script>. (around line 1345 for the home page.) This only shows up in my Konqueror browser, which seems to be stricter than Firefox, which doesn't complain when loading the SE pages, but does give and error if I directly load the offending URL. (Possible bug, or security issue with Firefox.) Interestingly enough, that tag is absent in the HTTPS version of the same pages, so I don't know how it would respond when the browser is supposed to check the page for mixed content.

Retrieving the certificate offered from that URL yields

        Version: 3 (0x2)
        Serial Number:
    Signature Algorithm: ecdsa-with-SHA256
        Issuer: C=US, O=Symantec Corporation, OU=Symantec Trust Network, CN=Symantec Class 3 ECC 256 bit SSL CA - G2
            Not Before: Jul 28 00:00:00 2016 GMT
            Not After : Jul 28 23:59:59 2017 GMT
        Subject: C=US, ST=Massachusetts, L=Cambridge, O=Akamai Technologies, Inc., CN=a248.e.akamai.net
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Subject Alternative Name: 
                DNS:*.akamaihd.net, DNS:*.akamaihd-staging.net, DNS:*.akamaized-staging.net, DNS:*.akamaized.net, DNS:a248.e.akamai.net
            X509v3 Basic Constraints: 
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Certificate Policies: 
                CPS: https://d.symcb.com/cps
                User Notice:
                    Explicit Text: https://d.symcb.com/rpa

            X509v3 CRL Distribution Points: 

                Full Name:

            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Authority Key Identifier: 

            Authority Information Access: 
                OCSP - URI:http://rc.symcd.com
                CA Issuers - URI:http://rc.symcb.com/rc.crt

            CT Precertificate SCTs: 
                Signed Certificate Timestamp:
                    Version   : v1(0)
                    Log ID    : DD:EB:1D:2B:7A:0D:4F:A6:20:8B:81:AD:81:68:70:7E:
                    Timestamp : Jul 28 20:05:03.628 2016 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                Signed Certificate Timestamp:
                    Version   : v1(0)
                    Log ID    : A4:B9:09:90:B4:18:58:14:87:BB:13:A2:CC:67:70:0A:
                    Timestamp : Jul 28 20:05:03.721 2016 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
    Signature Algorithm: ecdsa-with-SHA256

I don't know if the URL is co-owned with the subject of the certificate or not, but I'm not adding exceptions for miss-configured servers.

I realize that this is part of the overall migration to HTTPS for SE site-wide, and I expect that there will be other problems/bug to track down. In that vein, I'm not complaining about the error. Rather, I'm raising it so that the developers can track down problems and correct them. In this case it probably involves getting the third-party site to correct their issues.

This seemed like the best place to raise the issue. If it's better raised elsewhere, please tell me where and I can post it there instead.

  • In Chrome I only get this error in the dev console, but yeah something is broken in there. Thanks for the report! :) – ShaWiz Mar 9 '17 at 9:53
  • The website whynopadlock.com shows a large number of HTTP assets on that page. – TRiG is Timothy Richard Green Mar 9 '17 at 10:20
  • 1
    @TRiGisTimothyRichardGreen The items found are links not yet converted to HTTPS on the HTTPS version of the home page. All are Gravatar images. The problem here is on the HTTP pages with a link that is HTTPS, but that serves an invalid certificate. It's a problem SE will have to get that site to fix. Because it's part of their metrics, I believe, it's also a link they can't "just drop" to avoid page load errors. SE needs it to work for their benefit, not mine. It has to be fixed - at the source, not on SE - so the sooner they know, the longer they have to get the other site to fix it. – Gypsy Spellweaver Mar 9 '17 at 10:35

This should behave correctly in the latest version of all sites - we're https:// across the board with Q&A now.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .