6

My self-signed certificates are not working over Internet. What can be the problems?

Here are the setup details:

  1. I have a Windows Virtual Machine in Azure with IIS, and a self-signed certificate for HTTPS. Things are working fine. Site is opening up without any issues. NOTE: I have setup domain also, so that i can access this information over Internet.

  2. When I try to access the HTTPS based website from my personal laptop, I get an error message: This connection is not trusted.

In case of above error in browser, I have to accept the setting to browse the site in non secured mode and only then I am able to access the data. But this is not what I want.

I want to access the data in secure mode only.

How is this possible using self-signed certificates?

Improve this question
2
  • What is your browser, is it Firefox? And why do you say you browse your web site in insecure mode?
    – Jyo de Lys
    Aug 3, 2015 at 8:36
  • 1
    I tried Firefox,Chrome and IE. Insecure mode means browser says connection is not trusted and not safe, still do you want to continue? to which i then select "YES".. which i dont want
    – Vipin Tanwar
    Aug 3, 2015 at 8:52

4 Answers 4

Reset to default
2

One possible solution for you is to install your self signed certificate as a Trusted Root CA on your notebook.

See, https://technet.microsoft.com/en-us/library/cc754841.aspx#BKMK_addlocal

This will fix the problem you are describing (on that laptop only and only for browsers/other software that uses roots trusted by the OS, i.e. Firefox will still display the warning, bcs it uses it's own Trusted Root CA).

However, this wont work in production. Every one of your visitor would have to add your self-signed certificate as a Trusted Root CA to bypass the browser's warning. Doing so would be a serious security risk.

Improve this answer
18

Even if you see a message saying the connection is not trusted does not mean it is not an HTTPS connection.

In order to display or not such error messages, browsers try to validate certificates using following criteria:

  • Does the certificate common name match the domain name entered in the URL bar?
  • Is the current date between validity start date and validity end date?
  • Is the certificate signed by a well known Certificate Authority (CA)? (This is something you don't have with a self-signed certificate)
  • Does the certificate have been revoked? (I'm not sure all browsers validate this point)

There are also other mechanisms but let's forget them for now.

In your case, if you want to avoid this error message (which does not mean you don't browse your website in HTTPS), you can:

  • Remember your choice with Firefox (and you should not be warned again)
  • Sign your certificate with your own CA and install your CA as trusted in Windows and Firefox (there is a quite good article here, but it is not up to date due to the use of SHA1 signature instead of SHA2)
  • Get a valid certificate signed by a well-known CA (StartSSL for instance which is free)
Improve this answer
2
  • 1
    "does not mean it is not an HTTPS connection." Yes, but arguably when you don't know who you've created a HTTPS connection to is it really HTTPS?
    – Aron
    Aug 4, 2015 at 5:47
  • It is not because your browser does not recognize the server that you don't. Then, once you taught your browser to recognize it, no more doubts, just like the first ssh connection attempt to a server. And RFC2818 answers yes to your question: In special cases, it may be appropriate for the client to simply ignore the server's identity
    – Jyo de Lys
    Aug 4, 2015 at 6:09
12

The error message you got is the normal behavior of browsers when dealing with self-signed certificates because your self signed certificate can not say who the recipient of the data (your server) really is (trust), so you got that message asking you if you are sure you trust your website (serever). Anyway since your browser can't verify that you are connecting to your (right/real) server given the fact any attacker can create a self signed certificate and launch a man-in-the-middle attack.

To resolve your problem, add a connection rule exceptions depending on the browser you are using to access your website.

Improve this answer
6
  • 1
    "can not say anything about who the recipient of the data" - it can, but it is not trusted
    – Vilican
    Aug 3, 2015 at 10:56
  • 7
    To say it too simply: self-signed cert means the Certification Authority is yourself = unknown. Your Https smells faky. You pretend being certified, the certifier is not registered in the browser list. You are flagged.
    – Strukt
    Aug 3, 2015 at 13:01
  • 1
    -1 Happy with this answer right up until you suggest "add a connection rule exceptions[sic]". Either trust the certificate (bad idea) or go through the proper channels to get a CA signed certificate (Lets Encrypt comes out next month). But to put in an exception, would defeat the point of using https.
    – Aron
    Aug 4, 2015 at 5:45
  • @Aron Thank you for explaining your downvote. You say: Either trust the certificate (bad idea) : the certificate is self-signed so he can ask the browser to trust his server unless if he is paranoid and think of extreme situtions (MITM) ... Life is not all black or all white, I mean he asked a solution for that and I see that adding the exception is a good balance between the 2 extreme choices. This is said, You can answer and purpose him how to resolve the problem and trust me I will upvote you if your solution is genius. Kind regards
    – user45139
    Aug 4, 2015 at 6:37
  • 1
    @Aron You trusting a certificate you generated yourself is not a security risk unless you're a crook (but again, it's not a security risk to "you", only your employer). You asking others to trust a certificate you generated IS a security risk for the others.
    – slebetman
    Aug 4, 2015 at 9:13
2

Https is http via TLS/SSL. TLS provides three things:

  1. Data encryption
  2. Server authentication (the server is who they say they are)
  3. Client authentication (the client is who they say they are)

To achieve 1) a self-signed certificate is enough, but for 2) you need a certificate that is signed by a certificate authority known to the client (your browser). Unfortunately all current browsers always require both 1) and 2) for https and therefore don't accept self-signed certificates (at least not without giving scary warnings and making users jump through hoops to see the page), even though for many situations just 1) might be sufficient.

If the site will only be accessed by you, or a small group under your control, you could install your self-signed certificate in every browser as a trusted root certificate. Basically you become your own certificate authority.

If strangers will be accessing this site you have no choice but to get your certificate signed by a well known certificate authority. Fortunately there are certificate authorities that will do this for free, such as StartSSL.

Note that there is a movement towards "opportunistic encryption", which would solve this problem and would allow https using a self-signed certificate. It will be a while before support for this is commonplace though, if it ever happens. Firefox implemented it, but subsequently disabled it due to security problems. See also episode 502 of the Security Now podcast if you're interested in the details.

Improve this answer
6
  • 2
    Unfortunately all current browsers always require both 1) and 2) for https -- this is not true. They perfectly accept HTTPS connections with 1) only, they just warn you that 2) is not in place (and possibly make you go through hoops to get to the HTTPS page)
    – WoJ
    Aug 3, 2015 at 12:53
  • @WoJ you're right. That's what I meant to imply, but I should make that clearer.
    – Pepijn Schmitz
    Aug 3, 2015 at 13:09
  • It's important to note that without (2), (1) is just a big waste of computing resources. Encrypting data with the attacker's key might as well be a transmission in plain text.
    – Ben Voigt
    Aug 3, 2015 at 16:10
  • @BenVoigt that's not true. It's still the case that the connection is confidential and cannot be eavesdropped, which is what proponents of "https everywhere" are mainly concerned with. There are plenty of trivial websites for which having to prove their identity is unnecessary overkill.
    – Pepijn Schmitz
    Aug 3, 2015 at 16:59
  • @PepijnSchmitz: Pinning of self-signed certificates (like ssh building authorized_keys, where there is no PKI) is useful. Encryption with no authentication whatsoever is not particularly useful. Also, I read the HTTPS Everywhere FAQ and it did not say what you claim.
    – Ben Voigt
    Aug 3, 2015 at 17:25

You must log in to answer this question.

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