What signature and certificate signing is all about

Question

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?

Answer 1

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.