3
$\begingroup$

Original thread: Why hash the message before signing it with RSA?

Please correct the diagram below so I can better understand how certificates are created and signed by a third party CA:

https://i.stack.imgur.com/wUT1S.jpg

The CSR (which contains the RSA public key, Subject Name (CN), etc) is hashed+padded then encrypted by the third party CA. Then the same original CSR (or just "certificate") is then combined together with the certificate signature to produce the digitally signed SSL certificate?

Added comment 2018-05-26:

Thanks for the response, I appreciate you taking the time to discuss this.

"The signature of the CSR - which is also signed - is by the private key that is part of the key pair of which the public key is within the CSR. This signature value is verified and disposed." How does the CSR signing work? Does it use SHA to hash the CSR contents and then encrypt the hash using a temporary private key that was created by the web server during the CSR generation?

How does the CSR signature verification work? Does the CA decrypt the encrypted hash value of the CSR and then verify that the hash values are identical, at which point the CSR signature is verified and disposed of?

"It is not possible to encrypt with a private key because anybody can "decrypt" with the public key; the private key is used for RSA modular exponentiation though."

When does RSA modular exponentiation occur (when calculating the padding)?

Here is a revised diagram for your review:

enter image description here

Improve this question
$\endgroup$

1 Answer 1

Reset to default
1
$\begingroup$

The certificates are generated in full by the CA, combining the data from the CSR (e.g. CN) with data from the CA (e.g. serial number, issue date etc.).

The signature of the CSR - which is also signed - is by the private key that is part of the key pair of which the public key is within the CSR. This signature value is verified and disposed.

The CSR, which is mostly kept in a key store together with the private key gets replaced by the returned certificate, which is signed by the CA, which is identified as the issuer in the certificate.

Notes / discrepancies:

  • The hashing and padding is specific and internal to the PKCS#1 v1.5 RSA signature generation (some libraries also accept hash values or hash functions though).

  • It is not possible to encrypt with a private key because anybody can "decrypt" with the public key; the private key is used for RSA modular exponentiation though.

  • The certificate signature value is the value after modular exponentiation, it is of course not just the hash value.

  • The CSR is a certificate signing request which is/was defined in PKCS#10, it is not a certificate by itself even if it has a lot in common with a certificate.

  • As mentioned, the CSR is signed.

  • SHA-256 has an output size of 256 bits, not 160 bits (are you kidding me?)

  • Using SHA-512 and PSS signature generation would increase security, but not as much as increasing the key size: a 2048 bit key pair is relatively small nowadays.

All and all, the general idea and the components of the TBS Certificate part of the certificate are correct but all the details are wrong in that picture.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Of course the most tricky part is verifying that the entity sending the certificate request does indeed have the rights to the CN which contains the DNS name(s) in the CSR / certificate. $\endgroup$
    – Maarten Bodewes ♦
    May 26, 2018 at 2:44
  • $\begingroup$ I updated my original post to include additional questions (not sure how thread alerting works, so I'm adding this comment just in case). $\endgroup$
    – user3253260
    May 26, 2018 at 18:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.