I'm using a self signed SSL certificate on the homepage for our prom. I know almost everybody who uses this website personally, so I can assure them that the certificate is trustworthy, even though the browser displays a warning.

The question is: If I use this self signed certificate and my classmates visit the website anyway, are they less safe from hackers, malware attacks a.s.o?

The website doesn't require highest security: The only purpose of the website is for chatting and for ordering tickets; the payment doesn't happen on the website!


When you enter a not encrypted website, no warning is displayed. Does this mean no encryption is better than self-made encryption? I don't think so!

  • 2
    You could also obtain a certificate from Let’s Encrypt. It would be trusted by all modern browsers. – Daniel B Feb 28 '16 at 16:57
  • Any certificate is only safe if you trust the signer of the certificate. – Ramhound Feb 28 '16 at 17:18
  • The real question is why are implementing SSL/TLS in the first place? What features are you hoping to gain by providing the encryption? Self-signed certificates can work just as well as any other certificate, but it usually places the burden of verifying trust on the user. If the user is not going to actually verify that trust (or doesn't know how), using a self signed cert is only slightly better than unencrypted (and not worth the hassle IMHO). – heavyd Feb 28 '16 at 18:19
  • To answer your edit, yes it is better IMHO, self made encryption is equal to no encryption in security but it gives people a false sense of security so they end up doing things they would not have done on a unencrypted connection, that is what makes self made worse. – Scott Chamberlain Feb 29 '16 at 1:01
  • The answers given so far are technically correct, but they miss one point: Do you want to train/learn your visitors that self-signed certificates are acceptable? I suggest you don't do that. Since you also mention in a comment answer that tour visitors are not tech savvy, the best solution is to go the LetsEncrypt way. That works as intended, so there is really no reason to hack around and 'do your own stuff'. – Jan Doggen Mar 2 '16 at 8:57

A self signed certificate provides encryption like a normal certificate. But it does not provide the usual identification. But proper identification is essential for HTTPS, because otherwise impersonation of a server and man in the middle attacks are possible, which in effect make the encryption useless.

You can provide a proper identification with a self-signed certificate too by giving everybody who likes to connect to your site the up-front the essential information which certificate should be expected, i.e. by giving the certificate itself or the fingerprint. Of course you must give this in a secure way (i.e. not in-band during the connection). You should also somehow make sure that the other one actually compares the certificate it gets to the expected one instead of just simply clicking through it. This works if only a very few people will visit the site but will not scale with more visitors.

Another problem with certificates not issued by a public CA is when SSL interception is done. This is often the place in companies but also several antivirus products do it. In this case sites using a certificate which cannot be verified will often simply be blocked by the SSL interception and one would need to explicitly add exceptions.

  • Thank you very much! Unfortunately, your suggestion won't work, as the fewest of my classmates would know how to do this. But I don't think that a man in the middle attack will take place in the next few months when the website is needed. – Aloso Feb 28 '16 at 17:33
  • @Aloso: If you don't fear an attack then why do you use SSL at all? Apart from that: this way you will teach other to blindly click through these insecurity warnings and the next time they do this it was a real attack. It's better to just get one of the free certificates instead of rolling your own insecure thing. – Steffen Ullrich Feb 28 '16 at 18:00
  • @Aloso: also see the edit I just made about the problems you might get with several antivirus products. – Steffen Ullrich Feb 28 '16 at 18:04
  • @Aloso if you don't fear a man-in-the-middle attack, and are not worried about the warning, you are OK to use a self-signed SSL cert - that said, there would seem little point in doing so ! – davidgo Feb 28 '16 at 19:32
  • @davidgo There may be a point. For instance: let's just assume that I trust the connection well enough to believe that info I receive is actually coming from the right server. SSL still helps to encrypt the traffic so that others, like my ISP, who might record traffic, won't get to see the traffic contents if they review a logged (saved) copy of the traffic. So, identifying the remote system, to prevent MITM attacks, is one benefit of SSL, but that isn't necessarily the only benefit, and using a self-signed cert may provide some benefit(s) even if other(s) are not provided. – TOOGAM Feb 29 '16 at 8:23

Possible attack

There's a slim chance that someone can hijack the connection (especially if they use public WiFi) using software like sslstrip in order to replace pages you send to their browser with whatever the attacker wants. They can, for example, send the victim pages that look just like yours and the actual credit card accepting website, capturing anything that looks like credit card data.

Besides that, as you've noted, the imposing-looking warning browsers like Chrome display for self-signed certificates can scare users.

Free certificate signing

There's no need for self-signed certificates. There are certificate authorities that will sign your certificate for a short period (which should be fine for a prom coming very soon) for free if you can prove you own the domain. Use one of those.

Here are a few examples:


A self signed certificate will still encrypt the communication between the client (browser) and your server.

Your concern should be whether the server that your friends connect to is your server, which is fine; or another server inserted by an attacker, which is definitely not fine.

Your users have no real way of knowing this, short of you telling them by some out-of-band method of a property of your certificate that shows that the certificate is yours. You could let everyone know the thumbprint of the certificate, but it is extremely unlikely that your users will want or know how to check this. They would no doubt accept any certificate that appears whether it is the genuine self signed you created or a self signed created by a malicious attacker.

  • "short of you telling them by some out-of-band method" -- right. So, as long as you can effectively use an out-of-band method, then you're fine. e.g., distribute the certificate via an already-secured network, or on trusted hardware (like a USB memory card that you trust) possessed only by trusted couriers (like yourself). – TOOGAM Feb 28 '16 at 17:08
  • @TOGOGRAM - The certificate will be passed by the server to your client (browser) at which point the browser will complain that it's not trusted. If the user chooses to view the certificate they would see its thumbprint (a hash). That hash is unique to that certificate. If they then (for example) telephoned you and asked you to confirm the hash value then that would confirm that the certificate originated from you and not an attacker. The issue is that it's 99.99999% certain that the users aren't that tech savvy and wouldn't do this. – garethTheRed Feb 28 '16 at 19:00
  • It sounds like the real issue, in the scenario you describe, is that experts aren't taking care of the certificate deployments. Using Microsoft Windows as an example, my understanding is that professional networks using Active Directory can have the domain controller push configuration details to workstations that are configured to trust the domain controller. So a private cert can be deployed without a user needing to manually do anything to trust that cert, so then you don't need to worry about how tech savvy the users are. The company can use a "self-signed" trusted cert; little problem. – TOOGAM Feb 28 '16 at 21:56
  • @TOOGAM - In a MS Windows environment you could operate your own corporate Certification Authority. The Root CA certificate could be distributed using AD so that all Windows devices trust that cert. From there on certificates could be issued by the CA to (for example) web servers, which would be trusted by all Windows devices by virtue of the fact that these devices trust the Root CA. There would be no need for self-signed certificates as you would be operating a 'proper' CA. – garethTheRed Feb 29 '16 at 7:26
  • The definition I've understood of "self-signed" cert is that it is ultimately signed by "myself", not one of the CAs widely-recognized by the world (based on what is pre-bundled in most browsers). Instead of trusting the worldwide CA networks, trust is based on "myself" being the signer. That has everything to do with the signing, during the cert-creation process, and nothing to do with whether a CA is providing the cert. By this definition, a private CA may distribute a self-signed cert; they aren't mutually exclusive. You appear to be operating under a different definition – TOOGAM Feb 29 '16 at 8:16

Sure. Just do it.

From a technological point of view, who signs the certificate is not all that important as long as the signer is trusted. The big problem with most self-signed certificates is that the web browser doesn't trust the certificates. However, if you can get people to trust the signature of the certificate, then it functions just as well.

Getting people to trust the certificate is the key challenge. The easy way is to pay a certificate authority that is widely trusted by today's popular web browsers. However, if you're in a more contained environment (which sounds like is the case), you may be able to distribute the keys using private resources. You may even be able to use some sort of automated means, so end users don't need to go through any work. But, failing that, you could provide a set of directions for end users to follow. That might be feasible, largely depending on the abilities of the end users.

The improper way to handle this is to tell them to just ignore the warning every time they visit the website. The proper way is to get your certificate to be trusted by their browsers, and then their connections will work just fine without any scary security warnings. (Instead of working against the web browser's security-related functionality, you're using the web browser's security-related functionality in an effective way, which is the way that it was designed to work.)

  • "Getting people to trust the certificate is the key challenge." - no, I can tell them on facebook that it's trustworthy :) I don't want to pay money for this. – Aloso Feb 28 '16 at 17:28
  • @Aloso: I'm sorry I wasn't clear that "trust the certificate" was meant as a technical phrase, referring to the act of getting the certificate into the web browser's "certificate store". So the challenge is in getting users to actually do that, unless you can deploy the certificate via automated means. (For instance, computers can have the certs be pushed to them if they are configured to trust an Active Directory domain controller.) I understand you may want to not pay,which is why most of the 2nd paragraph discussed the alternative. (Of course, another option may be free, by StartSSL.com) – TOOGAM Feb 28 '16 at 17:57

Absolutely it is less secure. Certificates are not for "do you trust this website or not", they are for "as any computer in the chain between me and the user viewing the website modified or viewed what was posted".

If you use a self signed certificate and I was a bad guy who had control of a computer between your server and a person accessing the site I could make my own self signed certificate, with the exact same information as your certificate. This would let me intercept the data, decrypt it, do whatever I want with it, re-encrypt it with my fake self signed certificate, then send it off to the user.

Self signed certificates are only secure when you have a secure way to distribute them before the user visits the site that does not rely on the certificate itself.

Honestly if the site is just for chatting and ordering tickets (but not paying for them), there is no need for SSL.

  • That scenario would only be applicable if the user in question connects to the service for the first time. After that, the certificate is known and your attack can be detected. Also, the question today should rather be: Why not use SSL/TLS? With Let’s Encrypt and SNI and all, there is virtually no reason not to use it. – Daniel B Feb 28 '16 at 16:54
  • Many wrong details; certs do also ID the website (which can detect an impostor site, affecting trust). Without the right private keys, you should not also be able to use "the exact same information" including the ability to appropriately encrypt/decrypt messages. (You can have an equivalent key, but not the same.) 4th paragraph over-generalizes assumptions of purpose; people may want to chat privately, and have different priorities than major commerce sites. 3rd paragraph is the only one completely right, though Daniel B's right: the major concern is just the pre-trust distribution. – TOOGAM Feb 28 '16 at 17:03

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.