Ndtyjky

Does my understanding on SSL certificate flow is correct(CA/Self Sign) in below use cases.
Generally when we generate a SSL certificate it has the following contents
:

• Details like owner, domain, validity..etc.


• Public Key of the Web Server(Used for Asymmetric key pair SSL handshake)


• Digital Signature signed by either CAs Private Key or In case of Self sign, it will be Web Server own Private Key(Hope this understanding is correct?(Q1))

First Web browser gets SSL certificate with its own Public Key.
Certificate Validation when CA provider certificate exists:

1. Browser will have all Public keys of CAs and hence can validate the
   Digital signature.


2. Later Public key provided by Web server is used to intiate the symmetric secret key encryption.

But blogs also talk about browsers have already Trusted root certificates and it validates. Does it mean many a times browser only check certificate content without Digital signature validation(Q2)?

Now in case of Self-signed, web server would use its own Private key to sign in the Certificate(Istead of CA private Key). During first browser interaction, it will send its Certificate along with web servers public Key. So in this scenario, we have the same Public/Private Key pair used both during certificate signing and also to share the symmetric key for data encryption(Q3)??

Now, blogs say we can import the Certificate manually on browser. Certificate import would have imported the Public key as well to validate signature correct(Q4)?
Blogs say if certificate exists in Trusted Root certificates, it is considered valid. Does it mean browser dont do Signature validation(Q5)?

Does anyone help me in understanding Q1 to Q5. Am I missing anything?

Digital Signature signed by either CAs Private Key or In case of Self sign, it will be Web Server own Private Key(Hope this understanding is correct?(Q1))

Correct. The server's certificate will be signed by a CA certificate (either a root CA or more commonly an intermediate CA). In case of a self-signed certificate the server's certificate and the CA are the same certificate.

2. Later Public key provided by Web server is used to initiate the symmetric secret key encryption.

This is only kind true for the RSA key exchange. With RSA Kx the pre-master secret is created by the client, encrypted with the public key of the server and send to the server. Both client and server then derive all symmetric keys from this pre-master secret.

RSA key exchange is deprecated though and removed with TLS 1.3. Instead Diffie Hellman key exchange should be used. With DH Kx the servers certificate and the public key inside are only used to authenticate the server in order to protect against man-in-the-middle attacks but are not involved in the key exchange.

But blogs also talk about browsers have already Trusted root certificates and it validates. Does it mean many a times browser only check certificate content without Digital signature validation(Q2)?

The server sends the server (leaf) certificate and possible intermediate certificates and the browser then creates the trust chain from the leaf certificate leading to a local root certificate (trust anchor). If no such trust chain can be created the certificate is not trusted. Which CA certificates are used as trust anchor depends on the client: browsers like Firefox come with its own trust store, other browsers use the systems trust store, other clients use yet another trust store (i.e. Java comes with its own). See SSL Certificate framework 101: How does the browser actually verify the validity of a given server certificate? for more details.

Now in case of Self-signed, .... So in this scenario, we have the same Public/Private Key pair used both during certificate signing and also to share the symmetric key for data encryption(Q3)??

With self-signed certificate the issuer and of the certificate is the certificate itself, i.e. the private key used to sign the certificate matches the public key inside the certificate. In case of RSA key exchange this key is also involved in creating the symmetric keys (see above).

Certificate import would have imported the Public key as well to validate signature correct(Q4)?

The public key is part of the certificate (but the private key not). Thus a certificate import will implicitly import the public key too.

Blogs say if certificate exists in Trusted Root certificates, it is considered valid. Does it mean browser dont do Signature validation(Q5)?

A root certificate is considered trusted because it is in the local trust store, not because it is signed by something. That's why signature validation is not really relevant for root certificates. To properly work as a trust anchor SSL/TLS libraries still often require the root certificate to be a properly (self-)signed certificate.

Your post is hard to follow, but I'll try.

Certificates are validated against the issuing Certification Authority (CA), if the CA's root cert is installed in the browser.

For a self-signed certificate, you are the CA.

If you create the cert and import the cert for your CA, the certificates you create with it will be trusted. If you don't import your CA's cert, your certificate won't be trusted.

But blogs also talk about browsers have already Trusted root certificates and it validates.

The initial set of root certificates for CAs that your browser trusts are installed by the browser's publisher. This means that for example, a fresh install of Chrome will trust your bank's SSL certificate that was issued by Verisign, but not your self-signed certificate.

Once you install the root cert from your own CA, your browser will trust your certificates the same as it trusts Verisign's.

As for the question in your title, the browser must validate the signature. If it doesn't it's broken and this would be a huge security flaw.