In chrome, when I visit a site that is served using SSL with an untrusted certificate, the privacy warning kicks in and prevents me from connecting unless I really want to. In this case, with a self-signed certificate, is my connection still encrypted (or what other dangers arise from this scenario)?

  • Yes, it is encrypted. You can use it for testing purpose. You need a Trusted CA signed SSL Certificate to imply that you (website) are who you are claiming to be and induce trust in your audience. Commented Jan 12, 2016 at 6:08
  • Yes it is encrypted, however you might be encrypted with the wrong person. So you would have to verify the exact reason why it is marked as not trusted. For some situations you can know better! (For example if the browser does not know the CA but you verify the certificates fingerprint you are actually much more ensured to have the right peer than chrome would ensure with 200 CAs)
    – eckes
    Commented Apr 26, 2017 at 22:28

2 Answers 2


SSL consists of two major parts:

  • the encryption of the data
  • the validation that you are actually talking to the expected server

If you get the warning about an untrusted certificate than the encryption will still work, but you cannot be sure that you are talking to the expected server. This means a man in the middle attack might be possible where an active attacker will decrypt, sniff, and re-encrypt the traffic. That is instead of this:

     Browser <----------- encrypted -----------------------> Bank

you get this:

     Browser <-- encrypted --> Attacker <--- encrypted ----> Bank

In this case the attacker can sniff all data (passwords etc) and even modify the data and the client will not notice it. The connections are still encrypted, but not end-to-end (browser-to-server) but browser-to-attacker and again attacker-to-server.

Usually you should not override the warning by the browser because chances are high that there is a man in the middle attack going on. Only in the case where you know that the certificate is the expected one (verify fingerprint, not just the subject of the certificate) you can override the warning.

Note that there are cases of legal man in the middle attacks, i.e. SSL interception done by antivirus proxies or by middleboxes (firewalls) so that these can analyse the encrypted traffic. In this case your computer is either automatically configured to trust these certificates or you need to explicitly import the proxy-CA which signed the new certificates. If you are having such kind of problem while using your own computer inside the company please ask the network administrator how you should proceed and don't simply accept the certificates.

  • 1
    'chances are high that there is a man in the middle attack going on.' Is this particular to OPs case or in general? Because all the SSL errors I get are always related to misconfigurations. Commented Feb 17, 2020 at 18:51
  • @NathanGoings: Browsers (contrary to other applications) usually make a good job to work around the most common misconfigurations of missing chain certificates. And many reports I see are caused by SSL intercepting proxies in companies or schools, which is a kind of attack since the user did not yet knowingly accept the proxy CA as trusted. But deliberately malicious attacks are probably uncommon. Commented Feb 17, 2020 at 19:07
  • "This means a man in the middle attack might be possible where an active attacker will decrypt, sniff, and re-encrypt the traffic" - In case of self signed cert, this is only possible if they have access to self signed certificate's private key ?
    Commented Oct 10, 2020 at 10:14
  • 1
    @SRIDHARAN: It depends how the verification of the self-signed certificate is done by the client. If the client expects a specific self-signed certificate (for example with certificate or key pinning) then the attacker would need the original certificates private key. But it can be often seen that implementations simply disable any kind of validation if a self-signed certificate is expected. In this case the attacker could use an arbitrary certificate. Commented Oct 10, 2020 at 11:27

Your connection is encrypted, but unless you do manual verification of the certificate, you are not sure who is the peer you are connected to (which by definition would be able to eavesdrop on the connection). This is the so-called person (or man) in the middle attack.

  • how to verify a certificate manually? Commented Jan 12, 2016 at 6:46
  • @a3.14_Infinity You simply examine the contents of the certificate to make sure that everything matches (most importantly the server's public key, if that can be verified). Commented Jan 12, 2016 at 7:48
  • I would remind that the last part of your answer "you ar not sure..." stands also for any magically recognized certificate imbedded within any web browser.
    – dan
    Commented May 12, 2016 at 8:15
  • @a3.14_Infinity you can verify it by importing it from a trusted channel or by comparing the fingerprint. Both of course only if you know for sure which is the correct cert. Both methods are much more specific than the CA PKI system.
    – eckes
    Commented Apr 26, 2017 at 22:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .