When are self-signed certificates acceptable?

There truly are some clueless comments on that thread. As you said, the purpose of the certificate is for establishing trust (ie, for the client to verify the identity of the server).

Really, the way I think the certificate model should work is this:

1. The first time you connect to a secure site, ANY secure site, your browser says "you've never connected to this site before. It has offered this certificate."

2. You then review the certificate and see what its credentials are. Those credentials might be the fact that a CA signed it, and you may or may not trust that CA. An EQUALLY VALID credential is that you know what the fingerprint should be, because someone communicated it to you earlier by some other means (e.g. your bank gave you a piece of paper that said "when you connect to our online banking site, make sure the certificate you see has this fingerprint").

There should be no difference in validity between these methods in the browsers' UI, because security-wise the fingerprint method is actually more secure (because you're not trusting a third party).

Presently, the browsers give absolute credance to CA-signed certificates, while erroneously advising users that all self-signed certificates are bad and dangerous, sometimes without even giving the user a chance to verify it as correct.

3. If the remote site's certificate changes in ANY way, no matter what, the browser should advise the user. Even if the new certificate is signed by the same CA, the browser should advise the user.

Presently most browsers do not do this, so if a forged certificate (perhaps a CA was compromised, or one of their root certificates was successfully cracked) replaces a legitimate one, the user gets no warning at all. In this case, the CA-signed certificates are far LESS secure than self-signed ones because of the browsers' behaviour: if a trusted self-signed certificate is replaced with a different self-signed certificate, the user at least gets a warning.

Most users are not technically skilled enough to effectively evaluate whether or not to trust a particular cert. 99% of them would simply click "trust" immediately every time the warning pops up, making this proposed scheme almost completely useless.

Not to mention it'd be extremely inconvenient to have to go through a rigorous process of checking the cert for every. single. website. you visit.

Despite its flaws, the current CA-based trust model is better.

I agree with @thetrivialstuff. The hole system is, at least for me, outrageously expensive, and more insecure than a self-signed certificate, what kind of misses the point of SSL certificates (to be secure). The browser should always alert you for any change of the website's certificate. What about some kind of malicious software (including anti viruses, that are sending all your traffic to a server to "analyze" it for malicious things) that "replaces" (please don't correct me, this is simplified) all trusted certificates with it's own? What would happen? Exactly, the browser think it's 100% trustworthy and there's no need for any alert to the user like "Your bank's website certificate fingerprint seems to have changed, could you check this really quick? [Show certificate button]". What I'm going to do is to make a HTTP redirect to a website, where it says "Hey, we've our own secure certificate that is more secure than others. Please complete the instructions below and click on continue if you're done". Let's Encrypt is no exception, it is free, but has the same problems including all other "secure" and overpriced SSL certificate provider.

BTW, why don't they remove the "I agree to additional processing of my information, including first and third party cookies, for personalized content and advertising as outlined in our Data Sharing Policy" text? We already have enough personalized ads and spam emails.

what about self-signed certs used for client authentication? Can't we trust them? If the server admin receives the client cert directly from the client and imports it in the trust store, can't the self-signed cert now be trusted when the client establishes SSL connection? This seems like a case where self-signed cert would offer strong authentication on the server than if the client presented a CA signed cert, in which case anyone with a cert signed by a trusted CA could connect to the server. This matters if the goal of using SSL is to allow only selected clients to connect and not just anyone with a, say, Verisign cert.

am also confused.. If you buy SSL cert from 3rd CA, will that mean that same cert will be publicly available? what if if we are talking about A server to server communication only, One belongs to company A, another to Company B, they need to integrate using API to access each other's resources, hence a mutual SSL will be needed. Do you need to buy Cert from 3rd party? Or can you just use self signed "with a twist" like if I'm Company A, I will sign Company B's cert, so I'm certain he's who he says he is. Its like saying I dont need someone to vouch for him, I ID'd him becuase I myself signed his Identification docs. something like that...

They will need to buy a 3rd party trusted certificate. They could also manually allow a particular self-signed certificate but if they rely on the signature, it will need to be updated when the certificate is replaced and if they don't rely on the signature, the certificate could easily be spoofed.

If you can get the client certificate installed on the server beforehand, then there is no problem with a self-signed client certificate because there is no chance of a man-in-the-middle attack.

Duane,

You are correct in distinguishing between different kinds of trust. An SSL Certificate primarily allows a customer to "trust" that the website they're using is actually owned by the company listed on the certificate and that all the encrypted communications will be sent to that company's servers. It can also increase trust a little because a a company is verified by the certificate authority to be an active entity and have a verified address.

However, an SSL certificate doesn't stop the company from lying or commiting fraud. The only way for that kind of trust to be gained is for the customer to use the web site and have a good experience.

For someone trying to clean up the myths surrounding what SSL is and what it isn't you still perpetuate the trust myth, trust is a much to fluid term even in such a specific context to use so flippently.

You aren't trying to establish trust that comes over time by dealing with the same person or compamy repeatedly with amicable outcomes, it certainly doesn't come from some faceless multinational corp that says this is Joe Smith, just like drivers licenses can be faked, Verisign has issued false certificates in the past too.

What SSL certificates really do is try to express a level of confidence that you have that people are telling the truth or acting in good faith, sure this is a type of trust, but it is by no means the same thing as trusting someone with your car or your child.

My belief is this: if I run the CA, I know what it's doing. It's been shown that Comodo (at the least) has issued improperly-authenticated certificates (they say they're "domain control validated", but Eddy Nigg of StartCom was able to obtain one for mozilla.com, a domain which he certainly does not control or have the ability to send mail from or place content on the website of).

All TLS certificates do is state that someone has authenticated the endpoint. If I've authenticated the endpoint elsewhere, and I've issued a certificate to it, I know for myself that it's the right entity. The only reason why CAs get into the browsers is because they're theoretically audited and their internal controls are deemed to be sufficient to prevent unauthenticated issuance.

Obviously, in the case of Comodo, this trust was misplaced.

(Nevermind Verisign's mis-issuance of two certificates for Microsoft Corporation way back when, which forced MS to come up with CRL-handling code very quickly.)

I look at my own issuance of certificates very much like signing an OpenPGP key. I've done my due diligence, and if you believe that I have you can add my root to your trusted store.

I didn't bother reading all the comments on the slashdot thread, but I'm sure there is still a bug open on the mozilla bug tracker about Verisign, they are in a position to issue certificates trusted by most browsers, they also control a root server and more directly control .com and .net.

Browsers never warn the user when certificates change, so how do we know we aren't suffering a man in the middle attack being proxied via a Verisign redirection.

A Verisign employee went so far as to say they would issue duplicate certificates to government entities if they were compelled to on one of the Mozilla newsgroups/mailing lists a few years ago.

SSL certificates really shouldn't be trusted for anything more than financial transactions and maybe protecting passwords, after that all bets are off.

Is the man in the middle part true to that extent. Doesn't the man in the middle guy need the private key that generated the Self Signed Certificate. My understanding is that an SSL Certificate needs a private key on the Server end that verifies the data, that was encrypted using the public key, sent by the client? What is the likelihood of the "man in the middle" getting your private key. If he is able
to get your private key then you have a different problem other then the self signed certificate issue.

My position is Self Signed Certs are ok between two agreeing parties where the public cert is exchanged through private or other agreed ways.

If the "man in the middle" got your private key then yes he could spoof but then he would not need to generate a false certificate at that point. The question is isn't that always the case. we can make up any scenario and give the "man in the middle" any ability we want to make our case.. Let just say the "man in the middle" gets your server CSR and spoofs your DNS would that not also work with public Certs? After all the Cert is not bound to the IP but to the FQDN

At this point the Verisign's of the world are selling identity checking and charging a subscription to do it. weather they actually verify identity themselves is debatable.

The point is the man in the middle doesn't need your private key, they can just create their own. The fake certificate authenticates the fake server, which uses the imposter's private key. The fake server can then connect to the real server (using the real cert) and relay everything.

Without either a trusted third party or a "sneakernet" physical hand over how will the *client* know the certificate is the real one.

How do I create a new TLS/SSL server certificate that is NOT self-signed?

You will need to order a certificate from a certificate provider (https://www.sslshopper.com/certificate-authority-reviews.html

Bla Bla Bla... All this SSL is just another money grab in layman's terms another way to make money off me and you and anyone else that wants to build a website online. listen we don't live in a fantasy land this is the real world and nothing is truly secure. Just my two cents

Nothing's truly secure huh? So you'd be totally fine with posting your CC number here then?

Just because there's always the possibility of something being compromised, doesn't mean we should just ignore security entirely.

Also, you can get TLS certs for free.

Far too many mistakes above. For example, a web server doesn't 'require a certificate so that it can do the encryption.' It requires it so it can send a Certficate message. The 'The biggest problem with a self-signed certificate is a man-in-the-middle attack' only if the client is incorrectly configured or programmed to accept all self-signed certificates. 'It all comes down to, can you determine that you are using the same crypto key that the server is?' is complete nonsense. 'Before you can begin encrypted communications, you must do an *unencrypted* key exchange, where the server gives you it's crypto key' ditto. The crypto key is never transmitted in SSL.

> For example, a web server doesn't 'require a certificate so that it can do the encryption.'

Yeah, I think that's a typo. It should be "The web server (IIS, Apache, etc.) _doesn't_ simply require a certificate so that it can do the encryption. It could do it all automatically if it wanted."

> The 'The biggest problem with a self-signed certificate is a man-in-the-middle attack' only if the client is incorrectly configured or programmed to accept all self-signed certificates.

Or if the user is programed to accept all self-signed certificates. ;-) I think the point the article is making here is that you can't just blindly accept any certificate a website presents to you, because there might be someone MITMing your connection. If there was no possibility of an active MITM attack, there'd be no problem with just blindly accepting all self-signed certs.

> 'It all comes down to, can you determine that you are using the same crypto key that the server is?' is complete nonsense. 'Before you can begin encrypted communications, you must do an *unencrypted* key exchange, where the server gives you it's crypto key' ditto. The crypto key is never transmitted in SSL.

No, the article is actually completely correct here. The whole purpose of a TLS handshake is to negotiate a shared key between the client and server. This page, for example, uses ECDHE_RSA with P-256 to exchange keys with the server, and the connection is then encrypted with AES_128_GCM using that shared key.

The article is completely incorrect here. The key is never transmitted in TLS, or DHE. It is negotiated independently at both ends via a key agreement algorithm. THe Diffie-Helmann key agreement algorithm. That's what DH stands for. You therefore don't have to 'determine' anything, you 'compute' it.

Actually, upon closer examination of the surrounding context I believe that part isn't talking about Diffie–Hellman key exchange. (Which, by the way, is actually more commonly referred to using the term "key exchange" not "key agreement", even though I agree the later term is technically more accurate.)

Rather, it's talking about the server's public key embedded in the TLS cert. That key absolutely is transmitted in plaintext by the server as part of the TLS handshake, and the client does have to ensure that it's using the same key that the server has before proceeding, otherwise it would be opening itself up to a MITM attack.

The client, on receipt of the CertificateVerify message, has to ensure that the certificate embedding the public key was signed by the corresponding private key, via verifying the digital signature in the message. This proves that the server owns the certificate and that he isn't just a MITM. None of this has anything to do with 'using the same key', or the session key, or encryption.

> None of this has anything to do with 'using the same key'

Yes it does. If the client gets a cert containing a public key that _isn't_ the server's public key and accepts that as valid (i.e. the client is not "using the same crypto key that the server is") then the client is open to a MITM attack.

> or the session key

Agreed. Sorry, that was my own misunderstanding of the article text. Like I said, it sounds like it's talking about the key in the TLS cert, not the session key. (Although, you could also argue that it's impossible to be sure you're using the same session key the server is if you don't even know you're actually talking to the server in the first place. E.g. You're blindly accepting a random self-signed cert.)

> or encryption

Uh... yes it does. When it comes to TLS, encryption without authentication is pretty useless. If you establish a nice, secure, encrypted connection to an attacker's computer, that buys you nothing. The attacker can still read and modify all the data you're sending and receiving.

I think you're just being unnecessarily pedantic in about an article targeted at beginners. This article isn't intended to be an explanation of the low-level implementation details of TLS. It's a high-level description of why it's necessary for certs to be signed by a CA.

1. I haven't stated that authentication isn't necessary, which vitiates most of your reply.

2. You keep saying 'using the same key' as though it means something. It doesn't. 'Using the same key' has no meaning in SSL when referring to the server's public key. The server doesn't use it for anything, for a start. The key that is the same is the session key, not the server's public key. The client uses the server's public key to verify the CertificateVerify digital signature, and that's it. No shared use at all, and no further use of it by the client.

3. I am here correcting a widespread misconception about SSL. I don't see anything unnecessary about that, and it is rather shocking to me that the article hasn't been corrected in the 7 months since I first posted here.