3

I know that X.509 certificate signing process includes creating a CSR (certificate signing request) and then the following happens:

  1. Some data's from the certificate to be signed hash is computed using a hash-algorithm, i.e. SHA-256.
  2. The hash result is signed with the issuer's private key.
  3. The signature gets embedded to a client certificate.

However, it's still unclear to me what "some data's from the certificate to be signed" and "the signature" are.

With my very basic knowledge of public-key cryptography, I'm aware that the public key is used for encryption and the private one for decryption. But in what regard is this related to creating a signature and verifying one?

For example, I can write the following code and get no exception:

usrCer.verify(issuerCert.getPublicKey());

I understand that the signature from the usrCer and the public key of issuerCert are involved in the process, but could anyone please clue me in on what exactly happens in more detail?

My questions are:

  1. What is "some data's from the certificate to be signed" exactly? I found the following question on SA Which parts of the certificate are signed? but I would like to dig even deeper and take the 'parts' of certificate and sign them myself. (or at least check the hash)
  2. What does the signature consist of? Is it just the public key of the signature creator and the encrypted data? Is the signature all about returning true/false for a given public key and the signature itself?
John Kugelman
  • 139
  • 1
  • 8
Joe D
  • 143
  • 5
  • For a very detailed example, see https://security.stackexchange.com/questions/127095/manually-walking-through-the-signature-validation-of-a-certificate (disclosure: I wrote part of the answer, although 'Community' has now displaced me, oh the shame) -- and note that determining whether a certificate is _valid_ and can be trusted requires _much_ more than merely verifying it was signed by the CA, but you didn't ask about that. – dave_thompson_085 Jan 31 '22 at 23:51

1 Answers1

5

it's still unclear to me what some data's from the certificate to be signed

The certificate is a complex object with various fields. Generally, signed cryptographic object consist of three parts:

  1. TBS (to be signed) data
  2. signature algorithm
  3. signature value

Certificate structure is defined in RFC 5280, specifically, in ASN.1 module:

TBSCertificate  ::=  SEQUENCE  {
  version         [0]  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]  Extensions OPTIONAL
                       -- If present, version MUST be v3 --  }

TBS data includes version, serial number, validity period, subject, issuer, public key and extensions.

But in what regard is this related to creating a signature and verifying one?

opposite process: private key for encryption and public key for decryption. This is the property of asymmetric cryptography: one key used for encryption another for decryption. Which one is public and which one is private -- it is only logical decision, it works in both ways.

could anyone please clue me in on what exactly happens in more detail?

issuer calculates a one-way hash over TBS data and encrypts with its private key and produces the signature. During validation, you get issuer's public key and decrypt the hash stored in signature. Then you calculate same hash value over TBS data and compare this hash with the one you decrypted from signature. If they match, then the data in TBS wasn't modified since the signature was produced by issuer. If not, the data in TBS data was modified after signature was produced by issuer.

Crypt32
  • 5,750
  • 12
  • 24
  • 1
    Thanks a million for the answer! So, basically, the hash of TBS is just encrypted with the private key of the issuer and that's the signature? Later on the signature can be decrypted using the issuer's public key and if the hashes match then the signature is valid? – Joe D Jan 31 '22 at 16:41
  • 1
    `So, basically, the hash of TBS is just encrypted with the private key of the issuer and that's the signature?` -- yes. `on the signature can be decrypted using the issuer's public key and if the hashes match then the signature is valid?` -- yes, it is explained in my response's last paragraph. – Crypt32 Jan 31 '22 at 16:45
  • I apologise in advance but if you have some programming knowledge, please take a look https://stackoverflow.com/questions/70929367/decryption-with-public-key-returns-incorrect-value I'm trying to prove the statement of encyption/decryption programmatically – Joe D Jan 31 '22 at 17:04
  • 2
    [Signing is not encryption nor verifying decryption although years ago they were miscalled that](https://security.stackexchange.com/questions/159282/#159289) and you can _recover_ the hash only for RSA signatures, which OP didn't state but does appear to have used without saying so; for other algorithms including DSA ECDSA EdDSA you use the hash to verify but you can't and don't compare hashes. – dave_thompson_085 Jan 31 '22 at 23:57
  • I'm using RSA and hoping to get the hash that was signed by the issuer... – Joe D Feb 01 '22 at 09:38