6

I am new to SSL / digital certificates / signatures.
What I know is that a digital signature must be verified/decrypted using the public key.

So a cert that is signed by a CA must be verified/decrypted by using the CA's public key which are installed in most browsers.

  1. But how about a self-signed certificate? How does a client get the public key to verify/decrypt the self-signed certificate?

    Is this the scenario where the browser will prompt that the certificate is from untrusted source and require the client to trust it?

    By trusting, does that mean that the digital signature of the certificate is no longer verified? And that the cert is used directly ?

  1. http://webdesign.about.com/od/ssl/ht/new_selfsigned.htm

    In the link above, is "server key" a private key or public key? Its seems like the "server key" is used throughout the generation of the certificate.

    I would have thought that a "public key" will be stored in the certificate and the certificate will be signed by a private key.

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
Noob
  • 501
  • 1
  • 7
  • 11

3 Answers3

4

To understand self-signed certificate, at first we need to understand the role of Certificate Authority(CA). I will explain things in the context of web servers and browsers.

The role of Certificate Authority(CA) in HTTPS:

HTTPS employs Public-key cryptography which uses a key pair to encrypt and decrypt content. The key pair consists of one public and one private key that are mathematically related. A web server who intends to communicate securely with browsers can distribute the public key  but must keep the private key secret.

Now the problem is browsers cannot know with certainty that the key a web server used for encryption actually belonged to the web server. It is possible that another party monitoring the communication channel between the web server and the browser substituted a different key. Certificate Authority(CA) concept has evolved to help address this problem. Certificate Authority(CA) is a trusted third party which establishes the integrity and ownership of a public key. CA does it by signing the certificate (the public key of the web server) by using its private key. The browsers have built in public keys of well-known CAs and uses these to verify the certificates.

Self-signed certificate:

In case of self-signed certificate, the webserver signs its own certificate instead of getting it signed by a third party CA. In other words, the webserver itself works as a CA for itself. OpenSSL can be used to generate self-signed certificate.

In case of self-signed certificates, browsers(e.g. Chrome) would not be able to verify the certificate, therefore it will complain. To solve the problem, you can install the certificate of the self-signed CA in browsers.

References:

Wikipedia

Microsoft MSDN

Oren Milman
  • 149
  • 7
Razan Paul
  • 156
  • 4
  • 1
    -> what does the "signing" encompass ? hashing the entire cert together with the public key and encrypt it when the CA's private key ? – Noob Jan 19 '17 at 14:38
  • 1
    Yap, you are right. Signing a certificate by CA is effectively a way of saying that CA trust the public key of the certificate is correct and the certificate is associated with a particular individual or identity(certificate owner's identity). In the signing process, CA adds the digital signature of CA in the certificate. To compute the digital signature of CA, CA would compute the hash of the certificate and encrypt it using its private signing key. For more: https://en.wikipedia.org/wiki/Public_key_certificate – Razan Paul Jan 19 '17 at 23:30
2

1)

  • A self-signed certificate uses your key to sign itself; there is no CA involved, there is nothing to verify. The certificate will basically verify that it is matching the key but nothing more, so it serves no real verification purpose.

  • Your browser will pop up a self-signed certificate warning, which means that the key is not certified by anyone. This is different from the keys which are certified by a CA the client isn't familiar with (untrusted CA), where the client have the option to trust the unknown CA manually.

2)

Here you don't work with public and private keys, only with a key and its certificate which is a signature and metadata for the key. The key in question is your private key: keep it private.

You provide the secret generated from your private key to the user along with the certificate (signature and metadata from a certification authority), where the certificate should match the secret generated from your key and tell the client about the key name, owner, validity and other metadata.

However the certificate could have been created by anyone (it is only required to match the key), so the client only trusts the certificate if it is signed by a master certificate (which certifies that the certificate is authoritative), or by a chain of certificates, where the top signer should be trusted by the client, and all the signatures throughout the signature chain must be valid.

Top certificates may be built into your client (either browser or generally the trusted security certificate database) or may be imported and accepted by the user. A homemade but trusted top certificate (CA) may sign keys which would verify in every client trusting that homemade CA, but not in others.

grin
  • 166
  • 6
  • thanks for your reply. for 1) a self signed cert uses my own generate private key to sign itself. So do you mean that when presenting this cert to a web client, the client is not going to require any public key for verification of the signature. It is "going to" trust the cert and use the cert directly without verifying the digital signature right ? – Noob Jan 19 '16 at 14:46
  • @noob Most browsers use the OS's root certificate store. But they might match those against their own store to see if they are still trustable. If not the browser will still let you visit it but it will ask you if you wish to trust it first (add an exception). Your self signed cert will most definitely get flagged until you add an exception. You can even make and install your own root CA, client cert, and server cert (corporate networks/applications for example) and the browser will still ask for an exception. This doesn't prevent, but it does help fight against malicious certs. – Bacon Brad Feb 20 '16 at 00:27
  • 1
    @noob You can get a better idea of how a browser would go around treating certificates by reading Chrome's root CA policy. As you can see they take trusted CA's pretty seriously. So anything not a trusted CA (like a self signed certs) are most definitely going to be skeptical to the browser until the user tells them differently. - https://www.chromium.org/Home/chromium-security/root-ca-policy – Bacon Brad Feb 20 '16 at 00:30
1

Q1 For public websites the most safe approach, or the only safe way is to use certificates from a trusted CA. However, in many scenarios we can use a self signed certificate to get "safe" connections with a web site. Browsers can't trust in SSC at all, but it launch a scary warning to prevent users about a posible untrusted and risky site.

Q2 A server key is private, is the sensible part of asynchronous encryption, and it's used to sign a certificate, or public part of the asynchronous encryption as well. Both are stored in server file system, but only the public part it's known by the client/browser for encrypt/decrypt data.

Check Ivan Ristic OpenSSL Cook Book if you want depper.

jpdrummer
  • 11
  • 3