Simplified view on How Certificate Signing works

Published: July 21, 2020

Tags:

The Subscriber (the person asking a CA to issue them a certificate) sends a Certificate Signing Request (CSR) to the CA which contains all of their details like name, domain name etc.
The CA will then take a blank certificate and begins to fill in the details of the Subscriber, validating ownership of the domain along the way, until they have completed all of the fields in the certificate.
At this stage we have what we call the Pre-Certificate, it’s basically a finished certificate ready to issue but the only thing that’s missing is the CAs signature on the bottom of the certificate to make it official

CA takes Pre-Certificate and running it through a hash function, currently SHA256, to obtain the digest.
The second step is the CA then taking that digest and encrypting it with their private key.
This encrypted digest is the signature and once appended to the end of the file we now have a signed certificate that can be issued to the Subscriber.

Rules public key encryption

For every private key, there is only one corresponding public key.
Also Data encrypted with the public key can only be decrypted with it’s corresponding private key, and data encrypted with the private key can only be decrypted with it’s corresponding public key.
More rules and info at: https://www.cloudflare.com/learning/ssl/how-does-public-key-encryption-work/

Q: How does adding the encrypted digest i.e. signature makes it signed certificate ?

A: It can better be explained by putting browser in picture and looking at what it does while requesting https website.

During tls handshake with https endpoint, it fetches associate intermediate certificate and root certificate.
- We need to upload intermediate certificate(public key of CA) and root certificate while uploading ssl certificate.
Browser now decrypts the digest using intermediate certificates, if it is able to decrypt using intermediate key, it means that above certificate is signed by private-key of CA(data encrypted with the private key can only be decrypted with it’s corresponding public key)
Browser itself also calculate hash of pre-certificate to compare with hash it got in step 2 after decrypting digest.
If both are correct means,
- The signature definitely came from the CA. (Authenticity) - Step 2
- The certificate has not been tampered with. (Integrity) - Step 3

Above is over-simplified explanation of what happens, above all is taken from 1st half of post at : https://scotthelme.co.uk/cross-signing-alternate-trust-paths-how-they-work/