35

When someone says that a particular digital certificate (like an SSL cert) has been "signed with a key", what does that imply? Does that mean the certificate simply includes a key that should be used for further message exchanges? Does that mean that the cert itself is encrypted and can only be decrypted with that key? Does it imply something else? Thanks in advance.

zharvey
  • 911
  • 3
  • 10
  • 14

3 Answers3

26

Ideally, it means that someone looked at the certificate and decided that it is correct and legitimate. Once they've done that, they want to tell people "Hey, I've verified that this certificate is good. I trust it". To do this, they use their signing key to sign the certificate.

Now when someone gets the certificate they can see who signed the certificate. If they trust one of the signers, they can trust the certificate itself. This is the basis of Web Of Trust in PKI.

The actual signing probably depends on what kind of certificate it is. I think this is a useful read.

A digital certificate consists of three things:

  • A public key.
  • Certificate information. ("Identity" information about the user, such as name, user ID, and so on.)
  • One or more digital signatures.

Typically the "one or more digital signatures" part is done by listing a set of encrypted hashes of the certificate. So when you want to sign a certificate, you would compute the hash of the certificate, encrypt it using your private signing key, and add it to the cumulative list of digital signatures.

Community
  • 1
Oleksi
  • 4,809
  • 2
  • 19
  • 26
  • 2
    Thanks @Oleksi - but I think you misunderstand what my question was! You say "*To do this, they use their signing key to sign the certificate.*" **I don't understand what the "signing" part is!!** Are they encrypting the cert with their signing key, or are they adding their signing key to the cert? Thanks again (and +1)! – zharvey Jun 28 '12 at 16:51
  • @zharvey Sorry, I've added to my answer. Does that answer your question? – Oleksi Jun 28 '12 at 17:01
  • 1
    I think you mean Chain of Trust, not Web of Trust. If you read carefully, the link you posted says that Web of Trust is an alternative to, not a part of, PKI. http://en.wikipedia.org/wiki/Chain_of_trust – Hans Mar 29 '15 at 16:35
  • 1
    Useful read link is dead. – Koray Tugay Oct 07 '17 at 12:52
  • 1
    Note that *encrypting* and *signing* are not the same thing. Mathematically, generating an RSA signature of a hash digest is basically the same as encrypting the digest using RSA (except that you use the private key when signing and the public key when encrypting), but that's not generically true of digital signatures. Signatures do not need to provide confidentiality, merely prevent forging (which encryption doesn't necessarily do). [DSA](https://en.wikipedia.org/wiki/Digital_Signature_Algorithm), for example, is a signing algorithm without a corresponding encryption/decryption operation. – CBHacking Apr 28 '20 at 09:49
9

Here is the structure of an X.509 certificate:

    Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

   TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        extensions      [3]  EXPLICIT Extensions OPTIONAL
                             -- If present, version MUST be v3
        }

The data contained in the certificate itself is the TBSCertificate part: it binds the public key (subjectPublicKeyInfo) to an identifier (the subject), and various other attributes extensions).

This is then combined with the signature to form a Certificate structure. The signature algorithm dictates how this should be done.

Essentially, a digest of TBSCertificate (typically SHA-1) is computed and then signed with the private key of the signer (the issuer in X.509 terms). The slightest modification of the TBSCertificate content should make the digest change, which should in turn invalidate the signature.

Using RSA keys, the signing of the digest using the private key is mathematically very similar to what would be done for encryption using the public key. This is not the same conceptually, though, and DSA doesn't have that reciprocity, for example.

The principle is the same for other types of certificates, although the structure may differ. Considering that PGP public keys are in fact certificates, you may be interested in these questions too:

Community
  • 1
Bruno
  • 10,765
  • 1
  • 39
  • 59
  • When certificate is sent, `tbsCertificate` is sent without any ecryption. It is sent in original form? – Wafeeq Sep 04 '17 at 09:54
5

When someone says that a particular digital certificate (like an SSL cert) has been "signed with a key", what does that imply?

It implies that the entity owning that key has vouched for the accuracy of the information in the certificate and has attached information to the certificate that permits that vouching to be verified.

Does that mean the certificate simply includes a key that should be used for further message exchanges?

No. Certificates only prove identity.

Does that mean that the cert itself is encrypted and can only be decrypted with that key?

No. There's no reason to encrypt certificates, they only contain public information.

Does it imply something else?

It implies that the owner of that key has vouched for the information in the certificate. For a typical SSL certificate, the information in the certificate is a binding between a public key and a common name.

For example, when you point your browser at https://www.amazon.com/ Amazon's server will send you a certificate. This certificate binds a particular public key to the name www.amazon.com. Your browser confirms three things to know it is talking to the real Amazon:

  1. The server presented a certificate that was valid and signed by a key it trusts.

  2. The certificate binds the identity "www.amazon.com".

  3. The server proves it possesses the private key corresponding to the certificate.

So the purpose of the certificate signature is to put the signing agent's credibility behind the information in the certificate which is fundamentally "this guy owns this key".

David Schwartz
  • 4,203
  • 24
  • 21