When a certificate is issued, it is digitally signed with a signature by the Certificate Authority (CA) you have chosen as your certificate provider (for example Sectigo, DigiCert, etc). This signature provides cryptographic proof that the CA signed the SSL certificate and that the certificate has not been modified or reproduced. More importantly, it an authentic signature is cryptographic proof that the information contained in the certificate has been verified by a trusted third party.

Read more at:
https://www.thesslstore.com/blog/difference-sha-1-sha-2-sha-256-hash-algorithms/
https://www.differencebetween.com/difference-between-digital-signature-and-vs-digital-certificate/

1 Principle

As a public key can be used to encrypt data for the entity that holds the private key, a private key can be used to prove ownership of a public key (RSA). Instead of the sender encrypting the data with the public key, the asserting party (the one with the private key) encrypts the original data to be signed with the private key, and sends both that original data and the encrypted data itself. As it turns out, public-key cryptography works in such a way that you can use the public key to decrypt the data. If the decrypted data matches the data in the clear, then you can be assured that it was generated by the holder of the private key. Such the original data/encrypted data pair is called a digital signature.

One practical problem with this approach is that the encrypted data would end up being very long (as long as the original data), so a cryptographically secure hash such as MD5 or SHA-1[2] which was generated uniquely from the original data is typically used instead, to shorten the length of signature data.

Reference:
http://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art012

2 How a signature works

When the browser receive a certificate, it computes the secure hash of the whole certificate using the identified signature algorithm such as "SHA-1". Then it takes the signature and decrypt it with the issuer's public key. It compares the decrypted signature with the hash that it computed — if they match, the certificate is valid.

Reference:
http://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art012

3 Hashing

SHA-1 and SHA-2 Now that we have laid the foundation, we can get on to the star of the show. As I said earlier, SHA stands for Secure Hashing Algorithm. SHA-1 and SHA-2 are two different versions of that algorithm. They differ in both construction (how the resulting hash is created from the original data) and in the bit-length of the signature. You should think of SHA-2 as the successor to SHA-1, as it is an overall improvement. Primarily, people focus on the bit-length as the important distinction. SHA-1 is a 160-bit hash. SHA-2 is actually a “family” of hashes and comes in a variety of lengths, the most popular being 256-bit. The variety of SHA-2 hashes can lead to a bit of confusion, as websites and authors express them differently. If you see “SHA-2,” “SHA-256” or “SHA-256 bit,” those names are referring to the same thing. If you see “SHA-224,” “SHA-384,” or “SHA-512,” those are referring to the alternate bit-lengths of SHA-2. You may also see some sites being more explicit and writing out both the algorithm and bit-length, such as “SHA-2 384.” But that’s obnoxious like making people include your middle initial when you say your name.

Read more at: https://www.thesslstore.com/blog/difference-sha-1-sha-2-sha-256-hash-algorithms/