0

When we add a self-signed certificate to a device's list of trusted root certificates, we're already trusting it. So, why should it be signed with the server's private key?

Signatures only ensure that the certificate was verified by an trustworthy authority and that clients can verify the signature by using the issuer's public key obtained from a different channel. But the public key of a self-signed certificate comes from the certificate itself. The signing seems redundant, no?

3
  • 2
    who said that you need to sign the certificate with server's private key? And what kind of server? Web Server? The question is unclear.
    – Crypt32
    Jun 5, 2020 at 18:20
  • When you create a self-signed certificate and add the self-signed certificate to the device's trusted root certificate store, you are essentially building your own PKI.
    – mti2935
    Jun 6, 2020 at 2:06
  • 1
    RFC 5914 defines a trust-anchor with optional signatures. I'm not aware of any implementations though. Seems using a self-signed certificate in a trust-anchor store is just the de-facto norm. Jun 6, 2020 at 7:22

3 Answers 3

3

A certificate is a kind of envelope that contains a public key, some attributes defined for what purposes this certificate can be used, and the signature of the issuer.

Without signature there is no certificate. If you don't sign certificate, it is not certificate. You cannot add a plain public key to the trust store, you can only add a certificate.

What key you use, does not matter. You can generate a fresh key pair, generate a certificate for public key and sign it using the private key of this pair. Self-signed mean that the certificate is signed by the private key that matches the public key contained in this certificate.

3
  • If you try the last part of your answer in Windows, you get an error and This certificate has an invalid digital signature. on the self-signed Root certificate. I seem to recall it works on some Linux applications though - depends on which tool is used for the validation. Jun 6, 2020 at 8:06
  • @garethTheRed: What you mean by "try ... in Windows"? Try Java application in Windows? This works definitely. Try FireFox in Windows? It works, too. Describe what scenario exactly you mean.
    – mentallurg
    Jun 6, 2020 at 8:09
  • Good point. I tried with Edge as the client and the self-signed in the native Windows trust-store. I've also had the same result with IE a while ago and if I recall, Chrome also failed (which I believe uses the native Windows API anyway). I've not tried others lately, but do recall some success with Firefox on Linux a while ago. Maybe time to fire up a lab again :-) Jun 6, 2020 at 8:40
2

In the X.509 universe, checking the validity (i.e. trustedness) of a signature happens after building the certificate chain. That's a process where each (at this stage possibly-invalid) certificate's Issuer field is looked up and matched with a certificate the verifier knows about. It's important to note that the issuer is specified by "Distinguished Name" (which usually includes the common name, but can have other fields like organization, company, country, etc.) and not public key -- this is because X.509 is part of the X.500 protocol suite, which was intended to be a sort of global telephone directory type thing, and the public-key stuff was added later. (That it's pretty much the only part that anyone ever used matters little.)

When you're building a cert chain, you take the leaf cert, look up the issuer and add it to the chain, rinse, and repeat. If you can't find the issuer, you fail early -- you're either missing the root or an intermediate cert somewhere. In a self-signed certificate, the issuer's DN being the same as the cert's own DN means you've already added the issuer to the chain, and you can terminate the search.

So it doesn't really have anything to do with needing a self-signature -- you really need a self-issued certificate, and the signature is just a thing you have to do to make it semantically correct.

1

By self-signing the certificate, you prove that you hold the private key corresponding with the public key in the certificate.

2
  • How will that help? By placing the certificate among root certificates, we're already trusting that it came from the correct source?
    – Daud
    Jun 6, 2020 at 6:47
  • 1
    @Daud - I agree. However, oddly enough RFC 5280 section 4.2.1.1 does suggest that as being a reason (2nd para). It only proves you have the private key at the point of signature creation and in a self-signed certificate which, if it's a Root, can last 20-30 years, seems rather pointless. Neither does it say what you've done with the private key since signing - it may be on GitHub for all we know :-). Jun 6, 2020 at 7:15

You must log in to answer this question.

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