If I view a site that has a unsigned or self-signed SSL cert, my browser gives me a warning. Yet the same browser has no problem allowing credentials to be sent across unsecured pages.

Why is the self-signed cert treated worse than having no cert?


There are plenty of people that feel that this system is broken.

Here's the logic behind why your browser will give you such an alarming warning when an SSL cert is invalid:

One of the original design purposes of the SSL infrastructure was to provide authentication of web servers. Basically, if you go to www.bank.com, SSL allows the webserver that responds to prove that it does, in fact, belong to your bank. This stops an imposter from manipulating DNS or using another method to have a malicious server respond.

The "Trust" in SSL is provided by having a trusted third party (companies like VeriSign and Thawte Consulting) sign the certificate, indicating that they have verified that it is owned by who it says it is (in theory by visiting the IT administrator in person or another method that creates direct trust, although evidence shows that they're actually rather lax about it - all it takes to get a signed SSL cert is often an 800 number and a bit of acting skill).

So, if you connect to a web server that provides an SSL certificate, but it is not signed by a trusted third party, in theory this could mean that you are communicating with an imposter that is pretending to be a server belonging to a different organization.

In practice, a self-signed certificate generally just means that the organization that runs the server chose not to pay for a signed certificate (they can be quite expensive, depending on the features you want), or lacked the technical expertise to configure one (some small-business solutions offer a one-click mechanism for a self-signed cert, but getting a trusted cert requires more technical steps).

I personally believe that this system is broken, and that communicating with a server offering no encryption is much more dangerous than communicating with a server offering SSL with a self-signed certificate. there are three reasons browsers don't act like this is the case:

  1. Unencrypted communications are the norm on the internet, so if browsers made you click through a warning to view websites not offering encryption, you'd quickly get annoyed and disable the warning.
  2. Because of the dire warnings to clients, it's abnormal to see a self-signed cert on a production website. This establishes a self-perpetuating system: self-signed certs are suspicious because they're rare, they're rare because they're suspicious.
  3. This is cynical sounding of me, but there are companies that stand to make a great deal of money off of signing SSL certificates (cough Verisign cough), so they use whitepapers (an IT term meaning "long and boring advertisement") and other publications to enforce the idea that unsigned certificates are dangerous.
  • 5
    Without a chain of trust, which is what you get with a CA signed certificate and not a self-signed, there is no way to verify that the server you are connecting to is who is says it is. Self-signed certificates are dangerous in the sense that they do not provide any means for a user to verify that the data they are transmitting is reaching the destination that they say it is. People are beginning to learn to look for "https" when doing secure transactions, so having a big warning about an invalid or self-signed cert is 100% warranted, because they are losing one of the main benefits of SSL. – MDMarra Jul 10 '10 at 0:14
  • I wouldn't say 'broken'. I think that the Firefox Certificate Patrol add-on is a lot closer to the correct implementation of certificates and managing trust than the default. Still, the default is better than ignoring trust networks entirely. – Slartibartfast Jul 10 '10 at 0:18
  • 4
    @MarkM - My feeling is that authentication should not be considered the main benefit of SSL. I don't have the data to back me up, but I think that far more security incidents result from data transferred over unencrypted connections (as an example, the Facebook security engineer who's password was stolen - they sniffed the password off of a wifi network, since facebook login is not encrypted) than through MitM or imposter attacks, which are relatively much more complicated to implement. The focus on authentication over encryption in SSL is, as I noted, precisely what creates this situation. – jcrawfordor Jul 10 '10 at 4:07
  • 1
    @MarkM - while there definitely is overhead, which is a legitimate concern, use of unsigned certs will not put any stress on CAs, specifically because a CA wouldn't be used for a self-signed cert. Also, for organizations with sufficient power, it's not a concern - consider that Google now defaults to https for gmail and some other services. I understand your point that without authentication, SSL's usefulness is degraded. The current model is not well designed. What we really need is a standard encrypted protocol, and an authenticated protocol for more secure uses. – nhinkle Jul 10 '10 at 5:47
  • 5
    The greater significance of my point, and NRHinkle directly said this, is that we need to start considering encryption and authentication to be separate goals, and allow them to be achieved separately. These are the fundamental flaws with the SSL system right now: 1) We see encryption and authentication as being inextricably attached - to achieve one, you must achieve the other. Providing only one is 'suspicious'. 2) Authentication must be obtained from a limited number of primarily for-profit CAs. In general, CAs are either very expensive (Verisign etc.) or very shady (NameCheap etc.) – jcrawfordor Jul 12 '10 at 1:19

Sending credentials from page to page is basically doing HTTP POST. There is nothing special about sending credentials comparing to sending e.g. Search terms via POST.If any post to unsecure page would trigger warning, users would be bombarded by pointless warnings.

Using secure channel indicates programmer intention to secure the transfer. In this case, using self-signed certificate warning is very right thing to do.

  • Fair enough to me. – dag729 Jul 9 '10 at 18:16
  • As a matter of fact, I recall that at least old versions of Netscape Navigator did pop up a warning for every unencrypted POST. Of course, everyone disabled them after five minutes, so I guess that's why they took it out... – sleske Oct 10 '10 at 21:08

I can't comment, so I'll post this information that complements the correct information of user40350.

Yet the same browser has no problem allowing credentials to be sent across unsecured pages.

That is actually not even true. Most browsers will show a warning like you're about to submit data over an unsecured connection when you first try that, but you can turn it off so it never shows again, and I bet that is exactly what you have done...

Miro A wrote:

Sending credentials from page to page is basically doing HTTP POST. There is nothing special about sending credentials comparing to sending e.g. Search terms via POST

This is also incorrect, as password fields are special html tags for example. On top of that the labels like "username" and "password" also betray a lot of their sensitiviy. It would be perfectly feasible for browsers to take this kind of information into consideration.


Connections that are secured by the https:// protocol are indicated by the browser to be "secured". For example, a little Padlock is shown or parts of the URL are marked in green.

The user therefore is supposed to trust that the pages he is visiting are indeed from the URL he had entered and are not from someone else.

If he is using no https://, the user is supposed to know, that the data entered is not protected and the site he is surfing at might be imposted.

A self signed certificate does not make sure - againts expectation, that the page surfed to is not imposted, therefore it gives no extra security.


A distinction must be made between a trusted (signed by an authority you trust) and untrusted certificate. Otherwise someone could impersonate your bank (for example) by using a self-signed certificate with relative impunity.

An in-your-face warning is preferable to a subtle one in this case because the potential risk is relatively high. People might click on an https link and not even think that someone could be sitting in the middle monitoring the connection. If the indication that the certificate is untrusted is subtle (say a red instead of green icon, etc), then people could be easily fooled, removing the benefits of SSL.

  • Isn't it easy to impersonate a bank anyway if you have the access to the user's computer and modify their certificates? If the user's computer is not altered, then the web browser would not be able to modify the URL of the webpage to claim that they are the bank; and if they get a very similar URL, they can still get a certificate for that website and the user won't care who the the webpage is signed by, they'll just see that it's https and hopefully notice that the URL is not the URL of their bank... – Dmitry Sep 19 '16 at 3:27
  • The benefit of SSL is not trust that the website is who you think they are(This is impossible since a 3rd party application can alter your certificates, or the bank can get hacked); but rather trust that the communication between you and whoever the site thinks it is, is only between you two and nobody else can make sense of that communication. Not having a certificate is worse than having a self signed one because it doesn't matter who you're talking to, what matters is that nobody else should be able to intercept what you're saying. – Dmitry Sep 19 '16 at 3:28
  • Besides as a user, do I really know who Verisign is and why I should trust them? Isn't their interest in selling certificates higher than holding certificate owners accountable for misusing information you send to them? – Dmitry Sep 19 '16 at 3:47

Many good reasons have been listed. Here's one more:

Think about cases where one secure web page embeds elements from another. An attacker could detect which requests are for the outer web page (say by looking at the timing, it has to come first) and which are for the inner elements. He could inject himself as a MITM in just the inner elements, use a self-signed certificate, and control parts of the page. Unless a warning was presented for the inner elements using SSL but not using a trusted certificate, the security of the outer page would be compromised.

Here's a realistic example. Say I'm a vendor, and I have a 'pay with PayPal' link. You click on that, and I know. I redirect you to PayPal, and let you get the legitimate, secure PayPal page. If I'm watching your network, I know that will be your first request from PayPal, and soon after that you'll submit your password. So I MITM the submit containing your email address and password, substituting my self-signed certificate for PayPal's.

You see how the security of the outer page is compromised by not warning if the certificate of the inner page is self-signed? So it must warn on self-signed certificates that come from links.

And, of course, if you enter https manually, it must warn you. Because you expect it to be secure.


When man in the middle attack is executed in https:// website the warning is only indication of something wrong to average user. Therefore it's very important part of HTTPS security.

The good question is why the partially unsafe encryption is not possible for example over HTTP.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.