I got the error NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM when accessing one website using Chrome browser on macOS. The url of the website is corporate / internal so I can't paste the url here (you won't have access anyhow).
Chrome version 75.0.3770.142.
macOS version is Mojave (10.14.4).
Chrome devtools Security tab show 2 errors:
Certificate - insecure (SHA-1) : The certificate chain for this site contains a certificate signed using SHA-1.
Certificate - missing : This site is missing a valid, trusted certificate (net::ERR_CERT_WEAK_SIGNATURE_ALGORITHM).
I can bypass the warning, but it come back after each page change/page refresh (so boring).
I know why the warning 1 is shown: the leaf certificate is signed with a certificate which signature algorithm is SHA-1 with RSA. Chrome detects this as weak. (I'm ok with this behavior)
I guess the warning 1 implies the warning 2: the leaf certificate can't be trusted.
The things I don't understand are:
why I don't have the problem using Firefox, on the same macOS computer
why I don't have the same problem using Chrome, same version, from another macOS computer
why I don't have the same problem using Chrome, same version, from a Windows computer
As a side note, Chrome on Windows computer show the same Certificate - insecure (SHA-1), but the warning 2 ERR_CERT_WEAK_SIGNATURE_ALGORITHM is not present.
This drives me crazy !
Does anyone have an idea on this ?
Does anyone knows how/when/why those warnings are raised ? (I may look into Chromium source code but I don't know if Chromium handles this mecanism)
I really don't understand why there are such different behavior on configurations that looks similars...
Thanks for your help,
Romain
The URL is corporate, so the certificate is signed by your corporation. This is normal for many corporative sites/intranets.
Chrome assumes SHA1 is weak, but this is OK. It is the company certificate for the corporative intranet (i am assuming it is an intranet URL, or alike), so no problem it uses SHA1.
The site is missing a valid trusted certificate, means the current URL certificate could not be validated by any worldwide authority (this is normal, it was created by the intranet admin, internally, for internal use), and then the message is warning you that it is not trustable: Not trustable here means your computer does not know what to do, it tried check it to validate via internet if it could be trusted but it couldn't find any authority who replied, so the warning is for you to take some action (ignore, avoid the url, check the certificate, or trust it)
Solution:
On MacOS you have to add that certificate to the KeyChain, this way you are intentionally telling the operating system and any application who need to verify the certificate that it is trustable.
To do it:
open the certificate by clicking "View Certificate" on Chrome (like it is on your image above)
Once it is opened, click on its square drawing (difficult to explain this, I will put a picture below), and
Drag the certificate to your desktop (or any folder, this is temporary)
Go to finder, double click the certificate you just saved, you will se a dialog box like the image below:
Click Add (keychain must be login, like the above image)
Keychain Utility should open automatically at this point, if it doesn't, open KeyChain Utility on your Mac. Locate the certificate inside the Login Keychain (example picture below)
You'll see it was added, but yet not trusted. So we will tell the system we trust it, and by trusting it applications like Chrome and Safari will not display that warning anymore. Because they will check that the system trust that certificate for SSL connections.
Double Click it on the Keychain, it will open, click the little triangle to expand "Trust" item.
Select the item "Secure Sockets Layer (SSL)", and put the value "Always Trust"
Close the certificate by clicking on the red X button on its window. It will ask for your password to save the new settings for the certificate.
Put your password, click Update Settings
It will now show a blue icon, along with a message telling it is marked as trusted for your account.
This is it.
The Chrome messages will disappear because now that certificate is trusted.
Note: You may be thinking now... "I never did it on the other Mac" and you explained that you don't have that problem on Chrome on that other Mac. I suppose on the other Mac you have accessed that corporative URL using Safari at least once. When you access via Safari it will present you a similar warning like Chrome does, but if you ACCEPT it on Safari, it automatically does all this tutorial procedure for you transparently: it just ask if you want to proceed anyway, you click "proceed", Safari asks you for your password then it put the certificate on the keychain and mark it as trusted [exactly like we did] but transparently. And the next time you access the corporate URL you will not be asked because its certificate is already trusted on your keychain. Later if you then access it using Chrome it will not ask you, because it will see that the keychain already has that corporate certificate as trusted.
This is very probably why your other Mac does not have this situation.
PS: I could have answered here just: Access it using Safari, accept and proceed, and it will never ask again. But this would not be the correct answer. It would not explain the reason, and would be out of your presented scenario. So since you are using Chrome, I described this procedure considering the exact application and the exact situation that you have presented here, clarifying the reasons behind it.
Of course, now, since you know there is 2 ways to make this certificate installation procedure, you can opt for the one you like better.
_
Note: as mentioned by #patrick-mevzek
"On MacOS you have to add that certificate to the KeyChain", and you
will need to to it again each time the certificate changes or is
renewed. And if signed by a private CA, and if you add the CA in the
trust store, you are then open to various MitM attacks, as this CA can
sign certificates for any name, which is/may typically be the standard
setup inside corporate PKIs, but you have to be aware of consequences.
"
I agree with #patrick-mevzek, he is right and he made an important observation on this topic.
I'm extending the point he mentioned (specifically for MacOS) by showing how you can check if the corporate certificate you are about to add to your keychain is a CA Certificate or just a common innofensive end-to-end SSL certificate.
Open that certificate again, scroll down the information of it, until you find the item "usage" as shown on the picture below.
On the image below, there are 2 kind of certificates:
on the left, there is a CA Certificate: it can be used as MitM decryptor if your company wanted. It would only require a proxy between you and the internet, where your browser traffic would passes through. And if you have this kind of certificate trusted on your keychain, you have to be aware that the company proxy can (if a malicious admin wanted) decrypt your encrypted HTTPS traffic and log every confidential information on your connection to anywhere.
on the right, there is a simple and common SSL Certificate used by all of websites and internet domains, its purpose is just end-to-end encryption between you and the visited domain, to encrypt your traffic. It cannot be used as a MitM decryptor of your connection traffic data. This kind is totally safe to be trusted on your keychain.
Let's consider that you have the dangerous case, which the certificate is a CA Certificate and you added and trusted it.
Is there a way for you to know if your traffic is being decrypted by your company and your information being exposed?
Yes, there is.
On any browser, when you are accessing any important site, choose a bank for example, for this example I am choosing "hsbc.com.br", and I will show both situations:
The normal end-to-end encryption as it always must be
The MitM situation decrypting the banking sensitive private data.
While accessing any important https site, even if you see the Green icon on chrome or safari telling the connection is encrypted, check the certificate of it if you want to be sure that nobody is in the middle.
_
Here is the normal & SECURE situation:
HSBC Certificate is issued by DigiCert Inc and also is of type EV, which offer stronger guarantee of identity.
Now lets put a proxy in the middle, and do the MitM atack.
Here is the same HSBC bank I just acessed minutes ago, but I inserted a MitM proxy technic on my network, and I trusted that kind of certificate [CA Certificate] on my MacOS keychain.
Let's see what Chrome tells about the banking website:
It is telling me that it is secure, and also says that my information will be private!
But Chrome is WRONG!! (And it doesn't know it is wrong, because it is beyond it)
Lets open the certificate again: (I just activated the proxy and reloaded the page)
It is easy to notice the difference, the fake HSBC certificate was issued by my own personal certificate authority inside my network. This was done automatically by my proxy, which is capable of reading all the information I insert on the HSBC bank website, in pure TXT format, in both ways. Then it encrypts the data again and send to my Browser, and vice versa, do the same re-encryption while talking to HSBC servers.
The browser "think" that everything is OK, because the connection is encrypted, the site name on the certificate MATCHES the URL address I am accessing, the certificate is valid, and the CA Authority it is trusted on my keychain!
Everything technically is fine, except that is not.
This is the real danger, exposed, as mentioned by #patrick-mevzek that you have to be aware.
Related
I've a problem in my browser !,
I watched many solutions on youtube to fix this problem.
I did everything, I changed date and time of my computer.
I think this error occurs as a result of a browser that does not recognize the authority of the certificate.
I can browse all sites like "Google, Youtube, Gmail, stackoverflow, etc .." "except for this site" https://id.sonyentertainmentnetwork.com/id/management/ "
I use windows 7 home premium 64 bit,
Google chrome -> last version,
IE -> 11
Please try to browse this site "https://id.sonyentertainmentnetwork.com/id/management/"
"Problem with this website's security certificate" is a generic error message that Internet Explorer gives you when there is a problem establishing a secure connection (https://) to a website using the site's SSL certificate.
This error message can be caused by any number of issues. For example, here are some of the causes:
Your computer and the website's server could not agree on cryptographic algorithms to use for the secure connection. This can sometimes happen for older versions of Internet Explorer.
The authenticity of a website's SSL certificate could not be verified by a Certificate Authority (CA).
You did not provide enough detail in your question to figure out the exact cause of the issue. But, in this case, updating your web browser may help fix the issue.
I think it is just a common browser error that is not letting you visit that website with HTTPS.
I tested that website and it working fine in my browser. (Tested through Chrome, Firefox, Opera, and IE). So I think the issue is with your system.
Try clearing the cache and cookies for that particular website
Clear the SSL State from Internet Options
Disable QUIC Protocol of Google Chrome
Source: https://aboutssl.org/fix-google-chrome-error-err_ssl_protocol_error/
Try this:
Download de certificate:
https://letsencrypt.org/certs/isrgrootx1.der
Right click on this file.
Install Cerficate
Next
Click on second opticn. (my windows on pt-br -"colocar todos os cerficiados no repositorio a seguir") Browser
Select = Autoridade de certificação Raiz confiável.
OK
Next
Finish
I have 2 code signing certificates, for both CSR is created same way, also import and export is done same way. The only difference that I see is that one of certificates Common name contains Quotes, and the other doesn't.
e.g.
some cert and
some "cert"
CSR creation
Request format PKCS #10
disabled "Strong private key encryption"
Entered Common name, Organization, Locality, State, Country
2048 bytes for private key
set private key exportable
Import
place all certificates in Personal store
Export
Include all certificates if possible
Enable certificate privacy
encryption algorithm TripleDES-SHA1
Misleading thing is that this Common name value is NOT taken from the value I entered when I created CSR request
I am using those certificates to sign Winforms applications in Visual Studio. Certificate without Quotes in common name is working correctly (i.e. when I install application user is not getting security warning about unknown publisher), but when I install application which is signed with the other Code signing certificate (with Quotes in Common name) - it does not recognize Publisher. No error when published my application. When I take a look at setup.exe properties in Windows Explorer I see a Digital signatures tab which contains row for my certificate.
I tried to sign files with signtool and then verify - it said that certificate is valid.
I tried to get help from godaddy.com where I bought my certificate, they said that it should work with quotes, too, but didn't offer help to solve the issue. Rekey also didn't help.
I see that there are some suggestions to use Pre Publish, Post Build tasks, but I am not using those for my first certificate which is working.
So, is anyone here using code signing certificate for Winforms application with common name having quotes in it? Or maybe anyone knows about this problem and how to solve it?
Had to revoke (common name which is entered when creating CSR is not taken into account, so rekeying is not enough!) my code signing certificate and create from start without quotes/brackets in company name.
So this means, you will have to wait again for few days, because verification process is made from start again. When you will be contacted by issuer, they will verify / ask you about company name - make sure that they do not include quotes/brackets.
Revoking means that you will basically have to buy your certificate once more, because after you revoke it (at least in godaddy case) in your account you don't have options to create it again. So, you have to contact support (use call center and not chat ;)
I have a IIS website with a security certificate setup using SelfSSL (part of the IIS Resources toolkit). The certificate appears valid when I view it in ISS and it works fine for IE, Safari and Google Chrome. However, in Firefox 3 it does not consider the certificate valid and therefore shows a certificate warning when you view a secure page on the website.
This is only a problem because I am using Selenium to automatically test the site. I have tried using custom Firefox profiles to solve this problem and this works ok with one IIS site. But when each developer has their own site you have to keep adding exceptions to this custom profile.
I can use other browsers for the Selenium scripts, but I would rather use Firefox (the form input on IE seems to run much slower than Firefox).
I think the easiest way around this problem is to have valid certificates in the first place, hence I started using SelfSSL. Any ideas why Firefox doesn't seem to take any notice?
SelfSSL does not generate a valid certificate - it generates a self signed one. To get a valid certificate you have to buy one from a certificate authority.
If your IE, Chrome or Safari do not show a warning when visiting your secured page it means that you have added this new certificate to trusted certificates database of your account. You can do this in Firefox too - it just has a separate database. But your every user has to do this for himself.
i.e. I just want them to be permanently accepted all the time.
No, you cannot. Other people answering this question, please read it more closely. He wasn't asking how to add an exception, or fix a broken certificate. He wanted to TURN OFF THE CHECK COMPLETELY.
The Mozilla people erred on the side of caution by making this impossible. On the one hand it's annoying, but on the other hand, their security mindset is one of the reasons Firefox is so much safer than IE.
If you want to make exceptions just a little bit easier, type "about:config" in the address bar (no quotes), and type browser.ssl_override_behavior into the Filter, double-click the "Value", and change it to "2". Now exceptions require one less click.
check out the perspective firefox addon. It makes firefox 3 automatically accept self-signed certificates.
http://www.cs.cmu.edu/~perspectives/
Here's the answer!
* Tools -> Options -> Advanced -> Encryption -> View Certificates
* Under Authorities tab, enter "RSA Security 1024" in the Search textbox.
* Select RSA Security 1024 V3 and press the Edit button.
* Uncheck all three options
* Press OK and close out the rest of the dialogs.
The certificate authority won't be trusted for anything, and so have been effectively disabled.
The certificate authority is not unknown or in malicious hands or anything, its just not in use and hasn't been audited. See http://blog.mozilla.com/security/2010/04/06/removing-the-rsa-security-1024-v3-root/
You need to import the certificate issuers certificate so that any other certs. issues by that issuer don't give this warning.
In firefox go to:
prefs
advanced
encryption
view certificates
authorities
and then click import
If you have a root certificate for your issuer you can import it here and never see that error again.
For those of us who either...
Don't trust one of hundreds/thousands built-in "authorities" (which occasionally found to be on the list "by accident", or can be used for outrightly malicious purposes - think goverments) and/or security policies of any of them (any single compromised key can forge silent "all clear" for any site, after all, and - surprise - they do).
Don't like the cool tradeoffs like five clicks to get any cryptographic protection against casual listener on a site which somehow didn't paid it's ssl tax (and no, you can't know in advance whether owner actually did that and you're victim of MitM attack)... hm, you can actually buy an item and pay for it in less than that in a sensible UI.
Don't want to take part (for some mysterious reason) in all this commercial "pay or we'll spam you to death" circus altogether (which apparently can be mistaken for security).
Have need to connect to lots of various router/server https interfaces which generate their certificates.
...
...partial solution can be a "MitM me" extension, which at least lowers the click count.
I know it's an old thread, but for future reference, this FF extension makes the trick:
https://addons.mozilla.org/en-US/firefox/addon/skip-cert-error/
I think you need to get the certificate issued by a "root certificate authority" that the browser will know in advance, e.g. Verisign.
http://www.verisign.co.uk/ssl/ssl-information-center/
There's other suppliers too. Trail ones available here....
http://www.geotrust.com/
Good description of the issue and what might work best for you depending on your requirements here...
http://www.boutell.com/newfaq/creating/whichcert.html
I am maintaining a few web applications. The development and qa environments use invalid/outdated ssl-certificates.
Although it is generally a good thing, that Firefox makes me click like a dozen times to accept the certificate, this is pretty annoying.
Is there a configuration-parameter to make Firefox (and possibly IE too) accept any ssl-certificate?
EDIT: I have accepted the solution, that worked. But thanks to all the people that have advised to use self-signed certificates. I am totally aware, that the accepted solution leaves me with a gaping security hole. Nonetheless I am to lazy to change the certificate for all the applications and all the environments...
But I also advice anybody strongly to leave validation enabled!
Try Add Exception: FireFox -> Tools -> Advanced -> View Certificates -> Servers -> Add Exception.
I ran into this issue when trying to get to one of my companies intranet sites. Here is the solution I used:
enter about:config into the firefox address bar and agree to continue.
search for the preference named security.ssl.enable_ocsp_stapling.
double-click this item to change its value to false.
This will lower your security as you will be able to view sites with invalid certs. Firefox will still prompt you that the cert is invalid and you have the choice to proceed forward, so it was worth the risk for me.
Go to Tools > Options > Advanced "Tab"(?) > Encryption Tab
Click the "Validation" button, and uncheck the checkbox for checking validity
Be advised though that this is pretty unsecure as it leaves you wide open to accept any invalid certificate. I'd only do this if using the browser on an Intranet where the validity of the cert isn't a concern to you, or you aren't concerned in general.
In the current Firefox browser (v. 99.0.1) I was getting this error when looking at Web Developer Tools \ Network tab:
MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT
I was trying to debug an Angular app which is served at https://localhost:4200... however the real port it's pointing to and being debugged from in Visual Studio 2022 is 44322.
I had to follow these steps to fix the issue:
Open Firefox Settings;
Look for Privacy & Security tab on the left;
Scroll down to the bottom and look for Certificates;
View Certificates;
In this window you must click Add Exception and enter the location. In my case it was:
https://localhost:44322
Click Get Certificate button;
Click Confirm Security Exception button.
After that, try reloading your page.
Instead of using invalid/outdated SSL certificates, why not use self-signed SSL certificates? Then you can add an exception in Firefox for just that site.
Using a free certificate is a better idea if your developers use Firefox 3. Firefox 3 complains loudly about self-signed certificates, and it is a major annoyance.
If you have a valid but untrusted ssl-certificates you can import it in Extras/Properties/Advanced/Encryption --> View Certificates. After Importing ist as "Servers" you have to "Edit trust" to "Trust the authenticity of this certifikate" and that' it.
I always have trouble with recording secure websites with HP VuGen and Performance Center
Create some nice new 10 year certificates and install them. The procedure is fairly easy.
Start at (1B) Generate your own CA (Certificate Authority) on this web page: Creating Certificate Authorities and self-signed SSL certificates and generate your CA Certificate and Key. Once you have these, generate your Server Certificate and Key. Create a Certificate Signing Request (CSR) and then sign the Server Key with the CA Certificate. Now install your Server Certificate and Key on the web server as usual, and import the CA Certificate into Internet Explorer's Trusted Root Certification Authority Store (used by the Flex uploader and Chrome as well) and into Firefox's Certificate Manager Authorities Store on each workstation that needs to access the server using the self-signed, CA-signed server key/certificate pair.
You now should not see any warning about using self-signed Certificates as the browsers will find the CA certificate in the Trust Store and verify the server key has been signed by this trusted certificate. Also in e-commerce applications like Magento, the Flex image uploader will now function in Firefox without the dreaded "Self-signed certificate" error message.
For a secure alternative, try the Perspectives Firefox add-on
If this link doesn't work try this one:
https://addons.mozilla.org/en-US/firefox/addon/perspectives/
The MitM Me addon will do this - but I think self-signed certificates is probably a better solution.