Why are SSL certs self-signed if they have no real signature

Question

I understand that normally an SSL (or more precisely X.509) certificate is supposed to be signed by some certifying authority to assure that it is genuine.

In some cases no such signature exists, e.g. if you generate a cert for testing purposes, or if you are the certifying authority (root certificate). In these cases, self-signed certificates are used.

My question: Why use this weird construct of self-signing? Why can a certificate not simply not have any signature? What does including a self-signed signature gain?

Or is it just because it's technically easier (no special case for no signature) to always have a signature in every certificate, even if it's a meaningless signature?

Answer 1

I imagine it's to ensure that you can't "lie" with certificates - ie, you can't create a certificate unless the private key holder agrees to it. This is ensured either by the CA verifying that the entity named by the certificate is the private key holder, or in the self-signed case, by having the key holder sign the certificate itself.

Answer 2

Imagine that you're setting up your own certification authority, the very first one: who signs your cert?

The way to understand the whole certification process is to think of it as a chain of implications: You have a cert presented to you. Should you trust it? Either you can trust the issuer, or you look at the certificate, and agree that you trust the signer. If you don't know the signer, you can follow it back to THAT signer's signer, and so on. Eventually, though, you'll get to a self-signed certificate.

Getting a cert is relatively expensive and can be complicated, though, so some people make their own signing authority directly. It's left to you to decide if they can be trusted.

---

Some of the comments about this have gotten a little silly. You can't make a cert without a signature because a cert, to be a valid cert, must have a signature. That's the way they're defined. You might as well ask why you can't have a floating point number without an exponent. Certs exist so that there is some collection of identity information and a cryptographic mechanism for identifying the issuer in order to determine trust. Without the signature, something essential to the "cert-ness" of the certificate is lost.

---

Okay, let's ask some other questions:

• Why does a social security number have 9 digits? Why can't you have a 5 digit social security number?
• Why does a mailing address have that silly zipcode?
• Do we really need to keep first and last name for a person?

---

Let's try once more. What is a cert? Its a data structure that binds a name to the public side of an asymmetric encryption key. That structure is "signed", which means you can detect if it was changed by anyone other than the owner of the signing key. Because you can verify that signature, you have a degree of trust in the certificate's authenticity. Thus a valid cert must have a verifiable signature.

"Trust" in this context means that you are willing to risk failing to perform something you're responsible for, on someone else's authority. If you have a cert that is signed by a well-known CA like Verisign, the entity whose authority you're placing your trust is Verisign; you use a cert you obtained from them in some trustworthy manner to verify that they signed the certificate you're considering.

When you have a self-signed cert, instead of one signed by a well-known authority, then you're saying you're willing to trust the self-signer if you accept the cert. The only authority on which you can base your willingness to accept is the direct trust you put in the self-signer. But you at least have confidence that the cert is uncorrupted because you can verify the signature.

So, now consider a cert with no signature whatsoever. (Technically, this is called "a data item.") Iy may contain an association between a name and a public-side key, but without a signature, you can have no confidence it hasn't been modified by a third party.

See the difference? With a signed cert, you have an agreed-upon trusted third party that both whose authority both sides accept. With a self-signed cert, there is no third party but you can be confident the cert hasn't been corrupted by a third party. It can be trusted as much as you trust the issuer of the cert: you can verify that it was issued by someone who had the other side of the appropriate key.

With an unsigned "cert", you neither have the assurance from a trusted third party that the cert was issued to the right person, nor do you have any assurance that the "cert", once issued, hasn't been modified by a malicious third party. This is why, by definition a cert must have a signature.

Answer 3

A certificate has three main parts

1. identity information
2. a public key
3. a digital signature

A certificate is signed by encrypting the first two parts with a private key, then appending that encrypted information to the end of the certificate. If you can decrypt the signature with the public key contained in the certificate, then you know that certificate was signed by the person that holds the matching private key. The signature binds the identity information to the public key. I sign my certificate with my private key so that you know only I can read messages that you might encrypt with my public key.

Now, unless you've really met me in person and I hand you my certificate, you can't really know that the identity information is legitimately mine. The original purpose of certificates was to establish a web of trust by first obtaining the certificates of people that you have met in person, then trusting people that have certificates signed by those people, then those people...

Answer 4

You need to understand how RSA encryption works. The signer generates two encryption keys, one private and one public. They give you the public key, and encrypt data with the private key. Having the public key, you are able to verify that the data was encrypted by the correct person, because no one else has their private key. In the case of a signed certificate, there is a web of trust, in which you can verify the identity of relatively few individuals (the certificate authorities), and you trust them with regard to the verification of third parties. Every certificate must be signed, by the very nature of how the system works. A certificate can be signed by anyone, and "self-signed" certificates are the simplest approach when you don't care about the verifiability of the signer.

Answer 5

The difference between the two is who ran the program to generate the certificate. Some big corporation or some joe in his living room. The whole 'signed certificate' business is nonsense. A certificate allows you to encrypt data but large companies with something to sell you would have you believe that implies trustworthiness and identity. Encryption does not guarantee identity, and even more importantly, that you can trust the originator. Even assuming they have 100% good intentions just look in the news. How many big corporations have had data breaches this year?

I self signed my own certificate so I could encrypt the web traffic between my server and any users. I believe all traffic should be encrypted because no third party should be able to see what you do. I believe you should have a reasonable expectation of privacy. You should never completely trust anyone, particularly anyone who wants to sell you something.

Answer 6

Certificate contains the server's public key. Self-signature is a proof that whoever generated the certificate also posseses the private key.

Answer 7

Certificates give you information about the entity of the key that is signed, but they don't give you infromation about the entity that is signing the key. So self-signed cerfificates serve at least one purpose: They tell you who the the owners of the root keys are, without having to implement special data structures.

In my opinion these things shouldn't be called certificates, because they have different properties. Ordinary certificates don't need to be stored/transmitted securely. If an attacker manages to substitute a legit certificate with a fake one then the certificate verification should fail. The same isn't true for self-signed certs. If an attacker has the opportunity to substitute a self-signed certificate he/she can substiture that certificate with one that is signed with his/her private key and the forgery cannot be detected by verifying the cert.

Also notice, that logic of self-signed certs is somewhat backwards. The first thing you have to do is trust that some public key is authentic. If you do so you can learn to whom the public key belongs. Usually one would want the reverse. You decide that an entity can be trusted. Then you try to learn the public key that belongs to that entity.

In my opinion, self-signed certificates should be abandoned. E.g., I'd prefer to have all root keys in the Internet Explorer signed by Microsoft. After all it is Microsoft who validated that the certs belong to legitimate CAs and it is Microsoft who decides that the average user should be able to trust these CAs. Now if I'm worried that someone tampered with my certs, all I have to do is check that Microsoft's key is still theirs and then verify the signatures on every cert.

Answer 8

If you self-sign the certificate, it proves to someone that you actually control the secret key to that signature - ie, it is your certificate.

Otherwise, you could just create a public key that is random numbers and conforms to the format of a certificate, but isn't a real certificate.