I have multiple sites secured with SSL. All is from the same provider. At one domain Chrome says:
This site uses a weak security configuration (SHA-1 signatures), so
your connection may not be private.
I tested the domain with ssllabs.com and I got an A. Also tested with shaaaaaaaaaaaaa.com and it says, my domain has a verifiable certificate chain signed with SHA-2.
Here are my SSL settings in Apache2:
SSLEngine on
SSLProtocol all -SSLv3 -SSLv2
SSLHonorCipherOrder On
SSLInsecureRenegotiation off
SSLCipherSuite "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA"
SSLCertificateFile /etc/ssl/certs/xxxcert.cert
SSLCertificateKeyFile /etc/ssl/private/xxxkey.key
SSLCertificateChainFile /etc/ssl/certs/sub.class1.server.ca.pem
I haven't got any errors in my error.log. Can somebody help me, where should I continue the debugging?
The problem is likely that a certificate upwards in the chain is using SHA1, whereas your own one is using SHA2. My advice is to see if you can find an updated version of your chain file which uses SHA2.
Given that Google announced this in September 2014, you would think any reputable certificate authority would be supplying secure chain files by now.
You can find more information on this particular issue here: Why Chrome Thinks your SHA-2 Certificate Chain is "Affirmatively Insecure"
More information on why Google are sunsetting SHA1 is available here: Why Google is Hurrying the Web to Kill SHA-1.
Related
I'm using powershell New-SelfSignedCertificate to create a certificate and import into trusted root for a .netcore project.
It has been working fine, but has recently stopped, certificate doesn't expire until 2024.
I'm on Chrome 106.
Any ideas on why it would stop and how to fix?
Yes, Chrome has introduced its own certificate root store. They say this happened back in Chrome 105 but we've only started experiencing problems since Chrome 106 on enterprise environment.
On Windows you may disable this new feature via registry:
Create a REG_DWORD value ChromeRootStoreEnabled = 0 at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome
Restart Chrome
Taken from chromeenterprise. But don't forget that disabling this feature without understanding what you do may be a security risk - not a big one in this case but anyway.
The docs actually state that the new root store takes locally trusted certificates into account:
The Chrome Certificate Verifier considers locally-managed certificates during the certificate verification process. This means if an enterprise distributes a root CA certificate as trusted to its users (for example, by a Windows Group Policy Object), it will be considered trusted in Chrome.
We use our own CA to sign test websites HTTPS certificates on enterprise environment. So we seemingly must not have been affected. But even though everyone on the dev team has our CA installed in trusted root - we still face this issue. I'm not sure whether it's a bug or there is something else we need to know about which CAs are accepted and which are not.
Update 2022-10-24
I found out that there is another local enterprise CA apart from out team's one. Сertificates issued by that CA are accepted by Chrome without disabling the new root store - so Chrome obviously does not ignore locally trusted certificates.
After some trial-and-error I've figured out that the problem was not about the CA certs - but about the endpoint CA-signed certificates. The old now-rejected test certificate contains these properties:
Basic Constraints: subject = not a CA, path length = 0
Key Usage: Digital Signature, Key Encipherment
Extended Key Usage: TLS Server, TLS Client + 9 internal custom OIDs
Subject Alternative Name: localhost + around 30 test websites DNS names in various domains
Removing the Basic Constraints property made Chrome finally accept the cert.
So there have been more changes to certificate validation procedure apart from the new root store. By far I haven't found any documentation about what exactly they've also changed. And AFAIK Basic Constraints is an absolutely fine property to have even in a non-CA certificate, so it looks like a bug in Chrome to me.
console error is
getCurrentPosition() and watchPosition() no longer work on insecure
origins. To use this feature, you should consider switching your
application to a secure origin, such as HTTPS.
To answer your question directly: no, you cannot use those two methods in the API with insecure origins, because they reveal potentially personally identifiable information. It says so right in the error message.
You can get around this by either using a dev box with a certificate for development, or if you need to iterate quickly locally, consider issuing and whitelisting a self-signed cert, then setting your local machine as a trusted origin.
How resolve this problem in google chrome for my site:
The certificate for this site expires in 2017 or later, and the certificate chain contains a certificate signed using SHA-1.
in Internet Explorer functions normally.
You resolve the problem by getting a new certificate that uses SHA2. The SHA1 algorithm has been proven to have collisions, which means someone could make up a fake certificate and impersonate your site.
Chrome on purpose warns and does not accept those certificates anymore.
Typically, if you revoke and re-issue a certificate with your CA, you will get credit for the remaining time of your existing certificate.
The problem is not with Chrome, but with your certificate being considered 'unsafe' and Chrome taking a hard stance to make sure things are actually secure.
Compare the 2 screencaps below.
Each is to a different unsecured page where a login can be performed.
Why does Chrome warn only in the first instance and not the second?
I'm assuming it is something to do with encryption... and if yes, what exactly?
Note:
the first screencap is from a visit to: http://test.idempiere.org/
the second screencap is from a visit to a PrestaShop installation on a private VPS. PrestaShop is a popular e-Commerce CMS
If you use http connections you are always prone to many attack vectors, but they are still so used that no browser warns about them yet (although, see Mozilla proposal for deprecating unencrypted http). But you are right, those connections are definitely insecure.
However, currently HTTPS connections are checked against "known good" Certificate Authorities. If your connection does not have a trusted certificate chain, it is frowned upon.
Thankfully, these days you can get a free HTTPS validation thanks to EFF's initiative Let's Encrypt.
First the SSL Certificate is created by PrestaShop, not by an SSL company, your os does not know the issuer of the SSL Cert. And the cert is expired. You can make a certificate at letsencrypt, if you want to make it free: https://letsencrypt.org/.
That was my browser say(in german)
Is there any reason why a file may load over http but not over https?
I am curious because I just enabled ssl on a subdomain and it does not seem to be properly. I can see the green lock but if i load the site with it, i see no files.
Like if I have a file at
http://site.exmpl.org/file.html
when i go to
https://site.exmpl.org/file.html
it does not load.
I have ssl enabled because i have the green lock, also i am using cloudflare if that helps
I assume that you may have your SSL mode configured to "Full" in the CloudFlare Crypto section- But lack a ssl certificate installation on your subdomain.
--If not--
You may not have SNI or a Dedicated IP setup for your website then your apache server is likely using your certificate, but connecting to the web space of whoever first setup a SSL Certificate on that server. This is often a problem on shared web hosting environment. You can attempt to contact your provider to ask for help in getting SNI properly configured. You can also acquire a Dedicated IP from your provider.
in cloudflare dashboard under SSL/TLS section go to Edge Certificate instead of overview.
In Edge Certificate there is option called "Always Use HTTPS" which explains "Redirect all requests with scheme “http” to “https”. This applies to all http requests to the zone." just turn in on and after sometimes you are good to go.