I want to have a secure connection, when I log into my webmail, phpMyAdmin, etc.

Therefore I signed my own SSL certificates with OpenSSL and told Apache to listen on port 443.

Is this in fact secure? Are all my passwords really sent through a safe and secure layer? What difference does it make, if I buy an SSL certificate from Verisign or sign my own one? At the end of the day, all data will be on my server anyway. So what is the big difference?

4 Answers
4

This is all about trust. If you get a signed certificate from verisign you prove to random clients that your certificate is trusted. If you self-sign the certificate people not having your certificate installed on their computer cannot be sure that they aren't being attacked by an Man-in-the-middle attack.

If your webserver is just used by you, then you do not need a real CA (such as verisign) to sign your certificate. Just install the certificate on the machines that you want to use and you're good to go.

Edit: So to answer your question: Yes everything is encrypted and you can be sure no-one can read your sensitive data if you know that the certificate presented to the web browser is in fact the one you have setup the web server with.

The purpose of the CA is to prove to others that a certificate belongs to who you say it belongs to. Since you already know who the certificate belongs to, in terms of you accessing your own server and presenting your own certificate, a CA serves no purpose. However, others cannot securely access your servers, because they have no way to know which certificate to trust. (You do know -- trust the one you issued.)
–
David SchwartzFeb 25 '12 at 20:31

This would also be a reasonable approach if the server would be accessed by a limited number of users who could directly contact you to verify the certificate -- members of your family, or the staff of a small company, as examples.
–
bgvaughanFeb 28 '12 at 12:21

Can a Man In the Middle who's coordinated with a CA override one's self-signed cert? E.g. Bob connects to Alice's self-signed website, Scar sends Bob a different certificate signed by the CA Scar is coordinated with, Bob's browser never shows an SSL warning. Is this possible?
–
Hello WorldJul 5 '14 at 6:53

Say you visit a popular website that presents a certificate. This is the website saying "This is who I am, you can trust me, because I have this letter of introduction signed by someone you trust."

In this case, the 'someone you trust' is one of the certificate authorties who have, (hopefully) done the leg work in establishing the identity of the presenter of the certificate on your behalf.

What you're really trusting is the browser author's trust in the certificate authority's trust in the identity of the person presenting the certificate. There is also often more than one authority between you and the presenter, hence the term: 'Trust Chain'. [1]

When you sign your own certificate, there is no trust chain . Your site is presenting your own certificate back to you. If you install your own certificate in your browser as one that you trust, then that is treated as an authority, the same as the ones that come pre-installed. You then have a trust chain with only one link.

If you then visit your of of your own sites and your browser warns you that it is presenting an untrusted certificate, you should then have cause for concern, since, as with any other site that presents an untrusted certificate, you can't be certain that you're communicating with the real site.

Note that I made no mention of encryption, yet. Certificates are about authenticating the identity of the party with whom you are communicating. Through trusted certificates there's a way for you to be reasonably assured that your shop or bank is the real one. Once you've established their identity, securing the communications between you is the next step. It so happens that certificates also contain within them the keys required to facilitate this security. Assuming you've set your SSL up correctly, then this communicaiton is as secure as one you'd have with your shop or bank, and your passwords are equally protected.[2]

Actually, self-signed certificates can be secure, just not under the model we're using now.

Under the wide-spread CA (certificate authority) model that everyone uses currently, the purpose of the certificate being signed by a trusted CA is to provide authentication.

When we get a certificate, all we really see is 1's and 0's coming in from the jack in the wall; we have no idea where those 1's and 0's came from. However, because the certificate is signed by a CA - something that no one in the world other than that CA can do - and because we trust the CA to verify the identity of the certificate's owner, we trust that the certificate comes from who it claims to.

However, there is another model, under which self-signed certificates do provide authenticity. It's called the notary model.

Essentially, rather than trusting a single CA, we distribute the trust to any number of notaries. These notaries scour the Internet in search of certificates, keeping a cache of all the certificates they've seen. When you visit a site for the first time and obtain the certificate, you ask a number of globally-distributed notaries what the last certificate they saw was. If they disagree with what you're seeing, you could be a part of a man-in-the-middle attack.

Under this model, self-signed certificates are perfectly secure, as long as we assume the server isn't immediately compromised before any notary can ever view its certificate.

The notary-model is still in its infancy, and its doubtful it will ever take over the CA model (actually, it doesn't have to - they can be used in tandem). The most promising project so far is Convergence.io, which has a plugin for Firefox.

SSL certs can serve two purposes - 1) is the web server you are connecting to the one you want to connect to; and 2) to encrypt the communications.

You can have #2 without #1 which is what you have accomplished. What's left then is the verification that the box you are connecting to is the one you want.

If it is MY server, I have no issue with using a self signed cert from myself - although there is some risk that someone could spoof things to get me to connect to their server instead of mine. Since no one cares about me and my server and I have little of value here, I don't see too much risk in this.

On the other hand, if instead of a server of mine it was a server of yours, then I would be concerned.

Were you going to say: "If it is your server then I would NOT be concerned"?
–
cherrunFeb 25 '12 at 16:20

no, he said "if it is MY server I have no issue... if it is YOUR server then I have issues".
–
FrancescoFeb 25 '12 at 19:57

You are incorrect. Nobody could spoof things to get you to connect to their server instead of yours. They have no key that corresponds to the self-signed certificate you issued, and can't present a different certificate to you since you wouldn't accept it.
–
David SchwartzFeb 25 '12 at 20:29

@cherun My point was I trust me - not you (or anyone else). You can/should trust yourself.
–
uSlackrFeb 25 '12 at 20:58

-1. Encryption is done using symmetric keys negotiated during the handshake. Of course, you use the certificate to check the identity of the remote party, otherwise there would be little point encrypting the communication (it could be a MITM). If it's your server and a self-signed cert, import your cert explicitly into your client.
–
BrunoFeb 27 '12 at 13:22