56

I have locally made a Root CA certificate. I used the CA cert to sign the IA cert and used the IA cert to sign the server certificate. When I try to access the local server which uses the server certificate, it gives me a security risk warning. Is there a way to make it not give the warning?

All I basically want to know is, is it possible to make self signed certificate trusted?

Kevin
  • 151
  • 5
Praz
  • 585
  • 1
  • 4
  • 3
  • 69
    A self-signed certificate is like making a gold-colored badge looking thing in your home and then going around showing it to people saying you're a police officer. Maybe you can pull that trick with members of your family who accept that you're in charge, but if you want to be a real, public, law enforcement official, you have to be **trusted by a central authority** that everyone else trusts, like the government of your town or city or state. Otherwise, you're just impersonating a police officer and people would be wise to distrust you. – Todd Wilcox Feb 04 '16 at 16:41
  • @CristianTM: Often when someone "STFW" for an answer to a question, StackExchange is the top result - which is great and speaks highly of StackExchange! I don't think it's a legitimate reason to disqualify a question from being posted here. BadSkillz' answer below it simple, useful, and may drive this very page to the top of everyone's search results on the topic -- AND it took his as long to produce it as it took you to post *your* comment. :-) – loneboat Feb 04 '16 at 18:13
  • 14
    'Self-signed' is orthogonal to 'trusted'. All certificates in my trust store are self-signed, what about yours? So the questions is simply "how do I tell my browser to trust a previously untrusted certificate?". – kubanczyk Feb 04 '16 at 18:36
  • 1
    This is why we don't accept self-signed certs: > Please excuse Juan's absence from school yesterday. > > -Epstein's Mother. (If you aren't familiar with the TV program *Welcome Back, Kotter*, you might not get the reference.) – Monty Harder Feb 04 '16 at 17:35
  • @ToddWilcox very nice, to-the-point explanation. I may end up using that one. \*yoink\* – Philip Rowlands Feb 05 '16 at 09:39
  • @kubanczyk - He could get his server certificate trusted by the browser by putting it directly in the trust store, by putting the IA certificate in, or by putting the CA certificate in. Typically, he'd want to put the CA in, but the trust store doesn't have to be only self-signed certificates; with cross-signing, certificates can be both self-signed roots and signed by another certificate. – armb Feb 05 '16 at 11:50
  • @ToddWilcox Thats the same thing the "central authority" does except we all trust the auths instead of just close family. Instead of a sticker badge though, think of it this way: It's equivalent to the coolest kid at a party inviting you and telling everyone "he's cool" because you paid him to do so. There is no actual authority, trust, etc beyond the name of the coolest kid chiseled alongside few other cool kids on the monolithic granite rock that is the SSL auths. Comodo? C'mon....remember how they were in the 90's? They still are: annoying relentless SSL telemarketer spammers. No trusty ;) – dhaupin Feb 05 '16 at 15:01
  • 1
    @ToddWilcox A bit of a rough analogy that implies there's something inherently unlawful, or dishonest about self signed certificates. There isn't. A self signed certificate doesn't pupport to be anything other than what it is. A certificate signed by someone who hasn't gained the trust of the OS maker, the browser maker, or the app maker. – Steve Sether Feb 05 '16 at 20:31
  • Side note: if you're trying to get a valid cert for a public domain, you can use letsencrypt. They're finally in public beta, I discovered this last night while working on a client's server and I got 4-5 domains set up with certs in a matter if minutes. It's free & open source - https://letsencrypt.org/ –  Feb 06 '16 at 00:27
  • @ToddWilcox That'd be a great _answer_... – Lightness Races in Orbit Feb 06 '16 at 15:21
  • You can also skip the CA part, create a self signed server certificate and distribute it to all browsers which should trust it. This actually removes a lot of complication and implicit trust (it just does not scale very well) – eckes Apr 21 '17 at 15:56

8 Answers8

57

You need to import the root certificate into the trust store for the browser. Once the browser knows you trust this root certificate, all certificates signed by this will show up as trusted.

Note that this will only make the connection trusted for you, any others who don't have the root certificate installed will still receive an error.

BadSkillz
  • 4,404
  • 24
  • 29
  • 5
    Note that, depending on how the certificate is configured and how you add it, this may allow your self-signed certificate to sign certificates for any domain. (This is *not* something you want.) –  Feb 04 '16 at 19:48
  • 2
    @duskwuff: Actually, it _may_ be exactly what you want - if you want to set up your own Certificate authority, something many companies do for their internal network. Probably not the case here,though. – sleske Feb 05 '16 at 09:07
  • 3
    @duskwuff, that's exactly how an https proxy, such as BlueCoat, works. The organization buys the proxy, then installs the proxy's self-signed certificate in the trusted root store of each of the organization's computers. The proxy then MITMs all connections, including encrypted connections, to ensure that "bad things" aren't allowed to pass through the proxy. – John Deters Feb 05 '16 at 20:06
41

Self-signed certificates are inherently not trusted by your browser because a certificate itself doesn't form any trust, the trust comes from being signed by a Certificate Authority that EVERYONE trusts. Your browser simply doesn't trust your self-signed certificate as if it were a root certificate. To make your browser accept your certificate, go into your browsers configurations and add the certificate as a root certificate.

The best way to get a self-signed certificate trusted is to go through a Key Ceremony, which is basically a big public event where all cryptographers and security experts gather together to witness a root CA generate their key-pair and declare themselves a root CA. Everything is recorded: video, who everyone is and what everyone does by lawyers. The private key is split into many different parts and stored separately in safes typically after signing a single certificate which is used as an intermediary to sign other certificates. You can read about the typical procedure if you'd like. Of course, you need to have state of the art security, both technological and physical, to do this and have anyone want to use or trust your root CA. After doing this your certificates may be included in browser distributions and then can be used by the general public to create trust chains of certificates.

Community
  • 1
sethmlarson
  • 1,479
  • 10
  • 17
  • 10
    The "everyone trusts" portion of the statement above is the key failing of the entire system. In my opinion, the whole TLS infrastructure is built on a house of cards and no one wants to admit it. – Jon Trauntvein Feb 04 '16 at 15:59
  • 14
    @JonTrauntvein I agree with this (and others are willing to admit it) that there are some parts of TLS that are not good. The first being the certificate revocation system which basically does nothing as most browsers will ignore whether or not a certificate is revoked and secondly that some nation-state CAs **don't** follow the security guidelines above but are still packaged with all major browsers because of business political reasons. – sethmlarson Feb 04 '16 at 16:26
  • 1
    I would say that "The trust comes from being signed by a Certificate Authority that your browser maker trusts and you trust your browser maker". If there are some differences between you and your browser maker, then you can add/remove root CAs to/from your browser. – sm4rk0 Jan 10 '19 at 13:45
  • 1
    @JonTrauntvein Well what I'm wondering is, why don't we have any **alternative** method(s)? For instance, if I host my own SSL web server at home, why isn't there a built-in way for me to e.g. enter a login in the browser and then use cryptography to verify on the client-side (e.g. with a server-generated/signed response hash) that the server is legit? Something like that. I **know** that this is possible, and it could be made to be secure. This has to be in strong demand. – Andrew Mar 02 '21 at 03:10
21

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.

Of course, if the CA is compromised or doesn't correctly verify the owner, all bets are off.

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.

Community
  • 1
BlueRaja - Danny Pflughoeft
  • 1,943
  • 13
  • 18
  • 5
    +1 for explaining a better model instead of just re-iterating the auth schema (known as "profit model") we currently allow ourselves to roll with. God forbid the CA's lose out for doing...pretty much nothing. (GlobalSign -> $250/yr DV -> ...ROFL) – dhaupin Feb 05 '16 at 15:18
  • This is essentially a textbook distributed authentication algorithm wherein as long as a certain threshold of nodes trust a certificate, the network trusts it. There is a still a lot of ongoing research in this area and it is interesting if you are into that sort of thing. –  Feb 06 '16 at 15:23
10

Shorter answer.

A lot of answers here, but none seems to get straight to the point: Without a neutral and recognized third party — such as a certificate authority — verifying certificate ownership, a certificate is meaningless.

Longer answer.

To better understand, when doing something like creating an HTTPS connection you have the following chain:

  • A client web browser making the request to the server.
  • The remote web server sending data back to the client.
  • And an HTTPS certificate authorized by a neutral 3rd party that vouches that the server is who it is and the encryption is valid because of that.

A self-signed certificate is inherently untrusted because anyone can generate a self-signed certificate. Anyone including an entity that deliberately pretends to be something/someone they aren’t. With a self-signed certificate there is simply no trusted third party that has the basic human procedures set to simply state, “Okay, this domain has a certificate we issued them and thus you can trust them. We say they are in fact the domain the claim to be and not an imposter.”

And since anyone in the world can create a self-signed certificate on their own, it’s usage has inherent trust issues. What makes a certificate valid has very little to do with deep technology or encryption techniques but what makes it valid is a process centered around a neutral — and recognized — third party validating a usage procedure and browser makers adhering to a respect of those procedures.

At the end of the day an encryption key pair is an utterly meaningless pile of bits and bytes without the enforcement of the processes and procedures that surround them.

Giacomo1968
  • 1,185
  • 5
  • 16
4

We all need a little context.

There is a difference between "untrusted" and secure.

And "Trusted" does not necessarily imply Secure (or Authentic)

A self-signed certificate on an isolated network with only one server and one client is probably more secure than any "trusted" certificate.

And "trusted" implies ONLY that a Certificate Authority Certificate has been added to the "Trusted Certificate Store" for the client. If the Certificate Authority Certificate was added during a "phishing" session, then there is nothing Secure about the certificate.

I am not a fan that there are often hundreds of "Trusted" Certificate Authorities placed in the client by "others", but I also do not know of a better approach.

Certainly the Certificate Authorities need to perform better "vetting" process (in general) than they are doing now before they issue a Certificate.

jwilleke
  • 221
  • 1
  • 6
3

Self-signed certificates can't be trusted because anyone is able to craft one.

An attacker performing a MITM attack could easily replace any certificate by a self-signed one and impersonate any website you're browsing, even if you're using HTTPS.

That's why we are using trusted Certificate Authorities to ensure that certificates cannot be falsified.

Benoit Esnard
  • 13,942
  • 7
  • 65
  • 65
2

Any application must be given the list of "root certificates" to be trusted.

In case of a browser, there is a defined list that comes by default with any browser, but this list does not contain your certificate.

Imagine you don't need to actually give the list of certificates that you trust, then anyone would be able to setup a https website that an browser in the world would accept without warning of the security risk.

On the other hand, it would work out of the box is your CA certificate is itself signed by one of the default trusted certificates... but you have to pay.

There are enough answers as of how to add a CA certificate to the trusted list so I'll skip this part.

Gryzorz
  • 121
  • 1
1

If you want to do it for browsers, here are the steps:

For Chrome 58+: - Settings -> Show Advanced Settings -> Manage Certificates -> Import -> browse -> choose Trusted Root Certification Authorities -> click Yes on the pop up.

Dio Phung
  • 131
  • 1
  • 1
  • 6