Why is "deploying a self-Signed SSL Certificate very insecure"

Currently, many important website systems (such as online banking systems) that can be accessed through public networks are using self-Signed SSL certificates, that is, the SSL certificates issued by self-built PKI systems, rather than deploying SSL certificates that support browsers, this is definitely a major decision-making mistake that outweighs the loss. Self-signed certificates are prone to severe security vulnerabilities and are vulnerable to attacks. Main problems:
1. Self-signed documents are most likely to be counterfeited or forged and used by fraudulent websites.
The self-signed certificate is a self-built certificate. Since you can do it yourself, others can do it by yourself and make it exactly the same as your certificate, it is very convenient to forge a fake online banking website with the same certificate.
SSL certificates that support browsers are not forged. certificates issued to users are the only trusted certificates in the world and cannot be forged, once a fraudulent website uses a forged certificate (with the same certificate information), the browser will automatically identify the forged certificate and warn the user that the certificate is untrusted due to a reliable authentication mechanism, attackers may try to fool you or intercept the data you send to the server!
2. Self-signed documents are most vulnerable to SSL man-in-the-middle attacks.
The self-signed certificate is a certificate that is not trusted by the browser. When you access the self-signed certificate, the browser will warn you that the certificate is untrusted and you need to manually confirm whether the certificate is trusted. All websites that use self-signed documents clearly tell users that, in this case, users must trust and continue browsing! This creates an opportunity for man-in-the-middle attacks.
A typical SSL man-in-the-middle attack is that the man-in-the-middle is in the same LAN as the user or server. The man-in-the-middle can intercept user data packets, including SSL data packets, and communicate with users through a fake server SSL certificate, this intercepts user-input confidential information. If the server is deployed to support trusted SSL certificates of the browser, the browser will receive a security warning when receiving the fake certificate. The user will find that the connection is not correct and will not be attacked. However, if the server uses a self-signed certificate, the user will think that the website wants him to trust it again and trust the attacker's false certificate in a numbly place. In this way, the user's confidential information will be obtained by the attacker, for example, online banking passwords are very dangerous. Therefore, important online banking systems cannot use self-Signed SSL certificates!
Comments:At and, the self-signed certificate is not trusted by the browser, and the website tells users to trust it! Therefore, as a user, do not continue browsing websites with the following types of warnings in the browser; As a website owner, do not expose users to the danger of being attacked by fraudulent websites because of the deployment of Self-signed documents. In small cases, the loss of passwords will increase the customer service workload for you to retrieve passwords, if the bank account is too large, the bank account may be missing, and the user's losses may be compensated!
Maybe you or your system integrator said: this is not a big deal. As long as the user installs my root certificate, it will not be prompted next time. In theory, yes, but because the user has had the experience of requesting to click the trust certificate, the user will continue to trust the certificate again and the user will be hacked!
Even if you install your root certificate quietly when installing the USB key management software for the user, there is a problem. The self-signed certificate cannot guarantee the uniqueness of the certificate, your self-Signed root certificate may be forged by hackers like your user certificate.
In addition, except for the above two major problems, the certificate issuing system developed by the user or the certificate issuing system developed by other companies does not have incomplete PKI expertise, the latest development of PKI technology has not been tracked, and other important security problems exist.
3. Self-signed certificates support insecure SSL communication re-negotiation mechanisms.
According to our expert detection, almost all servers using self-Signed SSL certificates have insecure SSL communication re-negotiation security vulnerabilities. This is a security vulnerability of the SSL protocol, because the self-signed certificate system does not track the latest technology and does not promptly fill in the missing information! This vulnerability can be exploited by hackers to intercept users' encrypted information, such as bank accounts and passwords. It is dangerous and must be fixed in time.
4. Self-signed certificates support extremely insecure SSL V2.0 protocol.
This is also a common problem in the deployment of Self-Signed SSL certificate servers, because SSL V2.0 protocol is the earliest protocol, there are many security vulnerabilities, currently, all new versions of browsers do not support insecure SSL V2.0 protocol. Because the self-Signed SSL certificate is deployed, you cannot obtain professional guidance from professional SSL certificate providers. Therefore, the insecure SSL V2.0 protocol is generally not disabled.
5. The self-signed certificate does not have an accessible revocation list.
This is also a common problem with all self-Signed SSL certificates. It is not difficult to create an SSL certificate. It takes several minutes to use OpenSSL, but it is not that easy to make an SSL Certificate play a role. To ensure that the SSL Certificate works properly, one of the necessary functions is that the certificate contains a certificate revocation list accessible to the browser. If there is no valid revocation list, the certificate cannot be revoked if it is lost or stolen, it is very likely to be used for illegal purposes and cause losses to users. At the same time, the browser will receive a security warning during access: the revocation list is unavailable. Continue ?, In addition, the browser processing time will be greatly extended, affecting the browsing speed of the web page.
6. Insecure 1024-bit asymmetric key pairs are used in self-signed documents.
1024-bit RSA asymmetric key pairs have become insecure. Therefore, the National Institute of Standards and Technology (NIST) requires that the use of insecure 1024-bit asymmetric encryption algorithms be stopped. Microsoft has asked all Trusted Root Certificate Authorities to upgrade their insecure 1024-bit root certificates to 2048-bit and stop issuing insecure 1024-bit User Certificates. At present, almost all self-signed certificates are 1024-bit and self-Signed root certificates are 1024-bit. Of course, they are not safe. In other words: Because the self-Signed SSL certificate is deployed, you cannot obtain professional guidance from professional SSL certificate providers, and you do not know that the 1024-bit certificate is no longer secure.
7. The validity period of the Self-signed certificate is too long.
Another common problem in self-signed documents is that certificates are valid for a long period of time, namely, 5 years and 20 or 30 years, they also use insecure 1024-bit encryption algorithms. It may be because you don't need any money when creating a self-signed certificate, but you don't know why the PKI Technical Standard restricts the validity period of the certificate. The longer the validity period, the more likely it is to be cracked by a hacker, because he has enough time (20 years) to crack your encryption.
Maybe you will ask, why are all windows trusted root certificates valid for 20 or 30 years? Good question! Because: First, after the root certificate key is generated, it is an offline lock safe and is not always on the internet like a user certificate; the second is that the root certificate uses a higher key length and a more secure dedicated hardware encryption module.
In short, do not use self-Signed SSL certificates for your important system security, which brings huge security risks and security risks, especially important online banking systems, online securities systems and e-commerce systems. You are welcome to purchase an SSL certificate with a length of 4096-2048 characters supported by the Jingan wosign brand!

Why is "deploying a self-Signed SSL Certificate very insecure"