Why are SSL/TLS certificates self-signed if they have no real signature/CA?

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?

Raised

That is definitively a good and valid question. I hope it gets some attention. – Arcanum

Related question (with better answers IMHO): crypto.stackexchange.com/questions/29427/… – Decrepitate

Answer 1

A self-signed/root certificate offers no evidence as to the author of the certificate. Self-signed certificates must establish trust in some method other than checking the signature created by a certificate authority since these certificates are the final authority. Thus self-signed certificates must be delivered via an alternate mechanism such as bundling them with an operating system or web browser, or other--hopefully secure--side channel.

Anyone can create a self-signed certificate with a valid signature using a key pair they own. So what is being protected by the signature on a self-signed certificate? The certificate metadata.

For X.509 certificates some of the metadata is: serial number, issuer name, validity period, subject name, etc.

The signature on a self-signed certificate proves the certificate creator actually had the private key for the certificate at the time of creation and used it to sign the specific metadata included in the certificate. Modifying the any part of the certificate would invalidate it. Given that the signature protects against the modification of the certificate itself, what security would validating the self-signed certificate signature provide? I argue: nothing really.

The ability of an attacker to influence the root certificates on your machine in any way would constitute a serious security vulnerability since that would allow an attacker to add a new self-signed/root certificate and issue forgery certificates for existing websites, or create certificates for websites that shouldn't normally be trusted. Thus it is already necessary to ensure the secure delivery of trusted self-signed certificates and thus there is no extra security to be gained by verifying the signature on a self-signed certificate.

Allow me to present definitive evidence that the signature on a self-signed certificate doesn't matter: the OpenSSL documentation.

By default when you use OpenSSL it doesn't verify a self-signed/root certificate's signature! If you run the command man openssl-verification-options you will find the following:

-check_ss_sig
       Verify the signature of the last certificate in a chain if the certificate is supposedly self-signed.  This is prohibited and will result in
       an error if it is a non-conforming CA certificate with key usage restrictions not including the keyCertSign bit.  This verification is
       disabled by default because it doesn't add any security.

Key quote: "it doesn't add any security".

But maybe there is some non-security functionality to be had! Well you could ignore validating the X.509 bits for reasons described in the OpenSSL man page and verify the signature against the public key in the certificate. If the signature is valid using that technique you could use that as a way to identify self-signed certificates. Alas there is already another recommended way to identify self-signed certificates, see https://security.stackexchange.com/questions/93162/how-to-know-if-certificate-is-self-signed

So the final question: why do self-signed certificates have a signature if it doesn't add any security or useful functionality? My conjecture: Self-signed certificates are signed so that they have the same format as other X.509 certificates (metadata + public key + signature). Anyway that's my guess.

Another reference: https://security.stackexchange.com/questions/150882/security-benefit-purpose-of-signature-on-self-signed-certificate-in-trusted-st

Same conclusion in accepted answer:

That's why it is also not seen as a problem if there are certificates in the trust store which still have a SHA-1 signature, since this signature does not add any security anyway in this case.

Torsk

Thank you a lot! Best answer, reliable sources – Hearse

Answer 2

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...

Mesdames

+1 Your response describes the purpose of ordinary certificates very nicely. It still doesn't give a good reason for self-signed certs. – Arcanum

I'm amazed how many of the responses completely miss the point. The poster knows what self signed certificates are, and why you use them, but is asking what the point is of self-signing instead of simply leaving it unsigned. – Lenny

I think I did answer it. The signature of a self-signed certificate is nothing more than an assertion that the person signing holds the private key that matches the public key in the cert. – Mesdames

My apologies - I meant to post my comment on the original question, not on your answer. Yours is one of the few answers that actually gets (and addresses) the point. :) – Lenny

It's really not that hard. It's not a valid cert unless it's signed. It either can be self-signed or signed by someone else. With no signature, it's not a cert. Why can't a byte represent the range 0-300? It's too small. What is something that can represent 0-300? not a byte. – Recife

@Charlie: I think the question is a little bit deeper than that. I think the OP wants to know why it's defined that way, not just what the definition is. – Mesdames

Answer 3

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.

Recife

I don't see how this answers my question. I know the process, the question was, why self-signed instead of no signature? – Raised

Because "no signature" is meaningless. You can't generate a cert without a signature of some sort. Look up the X509 spec. – Recife

And the question is about why you can't generate a cert w/o a signature, right? :) – Strumpet

Okay, then the answer is "because that's the way it works." You can't make a valid cert without a signature because a cert without a signature isn't valid. – Recife

Ok, so the answer would be "A certificate must always contain a signature, because X509 demands it". Then of course the next question would be why it was defined that way... – Raised

Charlie, how do you verify a public key contained in a self-signed certificate really belongs to the person claimed in the certificate? I hope, you are not doing this by verifying the signature, because that would not be secure. Anyone can generate public keys claim they are Microsoft and self-sign this. – Arcanum

@A, you have to go outside the certificate system. The "chain of implication" always comes down to how you trust the root signer. If you want a high-assurance cert, you pay a well-known CA like Verisign some amount of money, and they take steps to verify your identity. (Google "Verisign Extended Validation" for their marketing hype, the URL is too long for a comment.) When you self-sign a cert, you're saying "trust me". – Recife

@Sleske, it's defined that way because a cert is intended to support this notion of a chain of trust. A cert with no signature whatsoever is a vcard; you have no reason to trust the contents at all. A self-signed cert at least can't be modified once it's created. What you're asking is like asking why a floating-point number needs an exponent part of it represents an small natural number: the answer is, without the exponent part it's not a floating point number. – Recife

Ok, I think I know where the problem is. You claim that a self-signed cert cannot be modified. Assume an attacker gets a cert and replaces the public key in the cert with his public key. Then the signature does no longer match, so the attacker has to generate a new signature. Can he do that? Of, course. His public key is in the modified certificate. Hence it is absolutely not problem to modify self-signed certificates and the self signed cert doesn't give the assurance that you would want. It doesn't add to the chain of trust. Only ordinary certs do. – Arcanum

Yup. You have to trust the signer of the cert. If it's self-signed, you have no more trust than your trust in the signer of the cert. Very good. Now, how do you develop trust in a cert signed by someone else? – Recife

Ok, so we have established that self-signed certs cannot be trusted regardless of whether there is a signature there or not. (Hence we need to get the trust into the root keys by some other means, e.g. by trusting that Microsoft wouldn't deliver software with fake keys.) This brings us back to the original question by sleske. Do the signatures in the self-signed certs make any difference? You claim that without a signature something essential is lost in self-signed certs, but so far you have not been able to subtantiate that claim. I think you'll have to revise that opinion. – Arcanum

If you can't trust a self-signed cert at all then you can never trust a cert, because somewhere at the root of the process is a self-signed cert. What you mean is that you can only trust any cert as much as you trust the root signer. As to your other point, well, it's silly. It is no more a valid cert without ghe cryptographic component than an IEEE floating point is a valid floating point without an exponent part. You may imagine that I'll "have to revise that opinion" but the X509 standard will disagree with you. It's just part of the definition. – Recife

Go read the Wikipedia article on it: en.wikipedia.org/wiki/X.509 One of the components of a valid cert is the signature. – Recife

Charlie, you are funny. You are the one who makes serious mistakes, such as the one the one I pointed out above. And now you are refering me to wikipedia. If you want to understand cryptography then you should read real research papers, books, join conferences, talk to real cryptographers, do research yourself. Please read the comments so far again. If you still can't understand the original question after that, then I'm sorry that I couldn't help you. – Arcanum

In science, arguments such as "I must be right, look at my reputations" have no value, neither has your attempt to patronize. Rather I take this as a sign that you have not one single valid argument to support your claim. Hence this discussion should end now. – Arcanum

@A, you're making the silly claim that the X509 spec doesn't include a signature. If I don't know anything about cryptography, somehow I've managed to be a technical editor of IEEE crypto specs and do 30 years of computer security research without it being noticed. But consider the odds. There's a standard spec. Either it meets the spec or it doesn't. But don't mistake my use of "son" as patronizing; it was more dismissive. – Recife

@Charlie: I appreciate your answer. So basically, the answer is that since a certificate normally needs a signature anyway, it simplified the standard not to allow a special case for certificates that don't have a signature. Instead X.509 says there must always be a signature, but it can be (from the security point of view) meaningless, and the simplest thing to do to get one is to selfsign. – Raised

Pretty close, except for the part about a self-signed cert being meaningless. A cert with no signature can be forged by anybody. A self-signed cert can only be constructed by the person with the private side of the signing key. So there is no reason to trust anything about an unsigned "cert", but you can trust a self-signed cert exactly as much as you trust the issuer. – Recife

Answer 4

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.

Sacculate

Answer 5

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.

Strumpet

Answer 6

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.

Multipartite

So the questions is: If you don't care about the verifiability of the signer or if you verfied by other means that a public key belongs to a certain person, why do you need a cerfificate? What is the advantage of having a self-signed cert over just a pair (public key, owner)? – Arcanum

Because most software only accepts keys in the form of certificates. You can't feed popular browsers (without addons) simple known keyring data and do anything useful with it, while the same data in the form of certificates allows all sorts of things – Multipartite

Answer 7

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

Renferd

Answer 8

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.

Arcanum

This is the best answer so far, the others don't even answer the intended question. I added an additional answer with some hard evidence but ultimately my answer comes to the same conclusion. – Torsk

Answer 9

The purpose of a certificate is to verify identity. The signer of the certificate is asserting to all recipients of the certificate that they have verified the authenticity of the identity information and it's association with the public key contained in the certificate. If the certificate is not signed then there is no verification of identity and thus no reason to use a certificate. In such a scenario you could use a cipher that does not require authentication and thus does not strictly require identity information. I think RC4 fits this description.

Your question implies that you wouldn't need to self-sign a certificate since you know that you trust yourself. Thus you could pre-share the certificate between the server and client. From a hypothetical cryptographic standpoint that would work; your authentication information would be protected. However neither asymmetric key crypto tools nor the certificate formats support such a use because it doesn't provide any benefit over a symmetric key cipher with a pre-shared secret.

Salazar

Answer 10

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?

Not much. It allows all certificates to have a single specification. One thing that we can really do without is having another option within the X.509v3 specificiations.

Still, I can think of a few other reasons that are not really necessary but they could be handy:

1. making it harder for a man-in-the-middle to "accidentally" alter the certificate information - faking the information would require an adversary (possibly within the organization of the receiver) to actually generate a new key pair + signing service;
2. simple verification (for the issuer) that the public key in the certificate is actually belonging to the private key that was used to sign it;
3. the certification and key pair creation require different levels of authentication within the issuer's architecture;
4. the fact that linked certificates exist on the same level as the root cert, where the linked certificate does obviously require signing (this is linked to having a single spec, of course);
5. sometimes the same private key can be used for an updated certificate information, in that case it it useful if the public key is explicitly trusted in a previous certificate.

Self signed certificates can either be root / CA certificates or root / leaf certificates. In both cases the certs need to be trusted explicitly.

---

Do note that I created embedded implementations that simply accepted certs after signature verification and then only stored the public key and required parts of the received certificates, showing that the signature is often not needed anymore after the certificate has been verified (date & CRL validation etc. is another matter of course).

Compatible

Answer 11

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.

Tungting

Actually, a certificate does guarantee identity. Even the CAs that give you cheap certificate will somehow varify that you are the owner of a domain name (via an automated email procedure) before giving you a cert for that domain name. Identification is neccessary because without it encryption isn't really secure after all (because of a MITM attack). Still, I agree with you that encryption without identification should be available for everything, as long as browsers indicate that it's still leaky. – Kerseymere