HI i'm accessing http://videobrochurecanada.ca/ on macs and it is prompting an ssl certificate error and then not running the stylesheet. Works fine on PCs Chrome.
Can someone help fix this?
The SSL certificate that is returned when accessing videobrochurecanada.ca has the wrong name. It's actually issued to newserver.dolcemag.com.
See the SSL Labs report (Archived here.)
Related
I am having this strange issue with SSL on my site. The domain is pointed towards Cloudflare and I am using flexible SSL settings. The universal default certificate is set on Cloudflare.
Now all my devices ( android, ios, windows, and any browser Edge, Chrome, Safari ) it works perfectly. But some users are complaining that they get NET::ERR_INVALID_CERT_AUTHORITY.
I have tried it with a lot of versions of google chrome(56-77). And both developers on the team all tried plus for other people I know it works. But some users ( according to client 70%) face this issue. Even the client is not having this issue.
Website is : https://beinhaoranim.co.il or https://www.beinhaoranim.co.il
please don't duplicate or something like that. I have serched through whole web and my problem is unique. Other solutions are most related to google chrome and its same on all devices.
I also faced the same issue long time ago which you can read in my post ERR_CERT_AUTHORITY_INVALID. I am explaining the same below.
The main reason is "SSL Certificate" conflict. What was happening is that
there was already a SSL on the hosting and sometime the SSL is
self-signed so make sure there is no other ssl certificate for that
site as it will conflict with the SSL provided by CloudFlare.
Download the SSL provided by CloudFlare and install on the
hosting. Remove any earlier SSL of that site first. Wait for upto 24
hours so that new changes are reflected everywhere.
We're having some issues on some machines related with ssl when connecting to our sites through https. sometimes, some of the users get the err_ssl_protocol_error when they try to load one of the sites. now, the weird thing is that hitting f5 solves the issue and the page that was returning the ssl error gets miraculous loaded. we've already tried most online suggestions (checking date and time, cleaning the browser/ssl cache, etc).
we have changed the ssl certificate recently (a month ago), but the issues have only started now. btw, all our requests go through our firewall (forti adc) which is responsible for enforcing the https to all our clients.
any clues on why we're getting this error?
edit: adding more info
sites are hosted in iis (windows server 2016)
our firewall is running forti adc
the requests go through a load balancer before hitting firewall
the firewall has the wildcard certificate used for ssl (all. sites)
sites are built with aspnet
it only happens on some pcs, and only with chrome (Firefox is working without any problems)
edit 2: More info from wireshark
So, I've used wireshark to capture the traffic and when I get the ERR_SSL_PROTOCOL_ERROR on chrome, I've noticed that wireshark is showing me an alert with a decrypt error in response to the server hello message:
Any clues on what's going on here?
After lots of digging and testing, it seems like there's an issue with openssl and ECDHE algorithms. Changing the algorithm to a non ECDHE seems to have solved the issue for our chrome users...
I got a very simple website without any link or something else. I created a self-signed certificate. (link to create self-signed certificate). After this I added it to my site in the IIS (link to add the self-signed certificate to IIS site). My Problem is now that my site is still not secure (local). Chrome, Firefox and IE are not accept my certificate. When I look if my certificate is valid: It's valid.
Can Anyone tell me why it's still not secure and how to fix it?
Self signed certificates are not trusted by default. You need to get the certificate from a trusted CA so that the users web browser trusts it. One recent example of a CA that issues free trusted certificates is Let's Encrypt.
I can see that you are using WordPress for your blog. Let's try a plugin really simple SSL. If you have any certificate install on your site it will detect and convert your pages in https. LetsEncrypt.org also is a way to obtain CA certificate.
You must need to install SSL certificate October 2017 onwards as per Google.
If you need further help read my blog to know that why we need SSL October onwards.
Hopefully, your issue will be resolved by a plugin.
Thank you
I've got a web site that uses SSL Client certificate authorization.
All client certificates are generated using OpenSSL and are self-signed. Everything worked with all web-browsers, but the recommended one was Google Chrome, because it uses same SSL warehouse as IE, so certificate installation was pretty easy (click-click-password-done!).
After last update of Google "Chrome 29.0.1547.57 m", noone can access my web-server, even me.
Google chrome error only! IE and FF working fine.
Error is: ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED.
Same in server error log.
Do you have any suggestions?
The problem is that most part of clients are non familiar with PC's and they got very frightened about that situation. So phone support guys are under the wave of calls.
We are experiencing the same problem. As Sean has reported, it seems that Chrome on Windows XP
negotiates TLSv1.2 even though the operating system does not support SHA-2 (say, SHA-256 or SHA-384)
hash function.
We found that Chrome fails when it receives "client certificate request" following SERVER HELLO.
SERVER HELLO itself negotiates RC4-SHA1 (in our environment) which should succeeds. The problematic
packet seems the "client certificate request" that includes SHA-2 (as well as SHA1) functions for hashes.
Invoking Chrome with "--enable-logging --log-level=0" outputs the following message:
ERROR:nss_ssl_util.cc(193)] ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED: NSS error -12222, OS error -2146893816
This is an Operating system error corresponding "NTE_BAD_ALGID" for CryptSignHash function:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa380280(v=vs.85).aspx
Disabling TLSv1.2 on the server should fix the problem. But I think Chrome should prefer SHA1 on Windows XP.
I'm experiencing the same thing here with Windows7 client systems unable to authenticate with client certificates against some of our systems, but not others. The affected servers are running Apache Tomcat while the unaffected are running IIS7, though I'm hesitant to identify that difference as the culprit.
Anyone else seeing this?
EDIT:
I'm able to eliminate the problem by disabling TLSv1.2 on the server. Is anyone else able to replicate this experience?
I would also be interested to know whether anyone else is seeing this on anything but the Windows platform, as it's the only place it's happening here (same version OSX has no issues).
EDIT2:
Chrome Bug Report here: https://code.google.com/p/chromium/issues/detail?id=278370
EDIT3:
Should be working again in latest Chrome stable. Chrome 30 will have a more robust fix, but 29.x should also work now.
I recently had a similar issue in Chrome on Mac OS. It worked fine with Firefox, but started failing in Chrome and Safari after changing my corporate (AD) credentials -- I guess the issue was a mismatch between system creds and the keychain creds.
The solution for me was a reset of the private key(s) access permissions in the Keychain Access app.
To do the reset:
In Keychain Access app right-click each private key that fails and select "Get Info".
Go to "Access Control" tab and set "Allow all applications to access this item" -- click on that option even if it's already set. Then click Save Changes.
Refresh the website that fails and you should be prompted to enter keychain password -- enter it and select Allow Always.
It is combination of Win XP and Google Chrome 29.0.1547.57 m
On Win 7/8 this problem doesn't occur.
You could install older working version 28.0.1500.95
http://www.filehippo.com/download_google_chrome/15657/
But settings for disabling updating are not so easy.
http://dev.chromium.org/administrators/turning-off-auto-updates
The problem is caused by Chrome running TLSv1.2 on Windows XP.
This can be disabled on the server side but also on the client side.
To run Chrome with a lower version of TLS, start it with the command-line option --ssl-version-max=tls1.1
I had this problem Connecting Chrome with WebSockets to apache throw proxy_wstunnel_module.
My solution was configuring httpd.conf
ProxyPass /wss2/ ws://127.0.0.1:8080/ retry=0 keepalive=On
ProxyPassReverse /wss2/ ws://127.0.0.1:8080/ retry=0
<Location /wss2/>
SSLRequireSSL On
SSLVerifyClient none
SSLVerifyDepth 1
SSLOptions +StdEnvVars +StrictRequire
SSLRenegBufferSize 10486000
</Location>
Chrome WebSockets does not like the parameter SSLVerifyClient optional
I hope this helps.
I have created my own CA and signed a certificate for use on an internal HTTPS website. I have imported the CA Certificate into both the Trusted Root Certificate Authorities and the Intermediate Certificate Authorities on the IIS machine and the site certificate is bound to the site on port 4433.
This works fine on IE9 and Firefox (i.e. the site is trusted) but I still get an HTTPS with a red score through it in Chrome (version 23.0.1271.91) saying that the site is not trusted.
Everything I have come across thus far says add the CA to Trusted.... But this seems to be of no avail in Chrome.
Any Ideas?
I believe this is a server/IIS issue.
Try to restart the server and check your SSL expiration date....
Check this page it might help you