Self Signed SSL Certificate - How to verify it correctly on the client side?

Question

For our current implementation we are using a self signed root certificate, which then is used to sign ssl certificates for our secure http connection.

My question relates to the verification logic on the client, which unfortunately, won't have access to the root certificate in trusted root certificate authority.

Is it enough to store the thumbprint of the SSL certificate on the client in a secret vault and then check for compliance in the callback function during the https handshake? Cosidering that it might be possible that someone creates their own SSL certificate and just uses this thumbprint value (which of course is publicly available)? Am I wrong or is it that a standard x.509 certificate can't guarante me that the data hasn't been tampered with?

Wouldn't it be safer to store the public key of the root certificate and use this to check the thumbprint for yourself?

Does this justify the additional overhead for each initial request?

Answer 1

My question relates to the verification logic on the client, which unfortunately, won't have access to the root certificate in trusted root certificate authority.

In this case you cannot validate against the root CA but must trust each certificate by its own.

... might be possible that someone creates their own SSL certificate and just uses this thumbprint value (which of course is publicly available)?

The thumbprint or fingerprint of a certificate or public key is a cryptographic hash over the certificate containing the public key or the public key alone. Since the secret private key must match the public key in the certificate and an attacker has hopefully no access to this private key (wouldn't be private anymore then) it is practically impossible for an attacker to create a certificate with the same fingerprint AND have the private key for this.

Since ownership of the private key of the certificate is checked during the TLS handshake this means it is sufficient to check the servers certificate against a stored fingerprint - provided that this fingerprint was created using a secure hash like SHA-256 and not an insecure one like MD5. But of course the application could also store the full expected certificate or public key and compare it.

Does this justify the additional overhead for each initial request?

I don't think that there is any noticeable difference between comparing the fingerprint or comparing the full certificate. If there is any difference at all then comparing the full certificate is probably the fastest since there is no need to create the fingerprint from the certificate in order to compare it.