Custom certificate verification using thumbprint

Question

I'm trying to confirm if the approach I'm thinking of taking towards verifying a self signed certificate is sound, or if I'm going about it the wrong way. I'm no security expert, so bear with me please if I make any wrong assumptions.

Following is a summary of the situation I have:

• Self hosted Windows Service that can be running on any machine in the LAN. The service is implemented using .NET gRPC.
• The service will only be accessed from the LAN using a desktop client. No access from a web browser or external client is involved.
• The client uses the IP address of the host where the service is running to access it.

From a security PoV, I want to ensure that the data sent between the client and service is encrypted. To achieve this, .NET gRPC allows the use of certificates so that the client can talk to the service using HTTPS.

However, I don't want to buy or use a CA certificate, therefore I plan to create a self signed certificate and configure the gRPC service with it.

Given that clients need to access the service through the IP address, I would need to install the certificate on every client machine. However, I don't wish to do that. Instead I plan to leverage .NET ServerCertificateCustomValidationCallback and implement custom verification.

To verify, I am thinking of storing the certificate thumbprint/hash in the client's code, and when the callback is invoked, verify that the received certificate thumbprint/hash matches the one in the client's code.

Is this verification method reliable? Can a man in the middle attack occur with this method?

My initial thinking is that because it's only the certificate hash an attacker can get hold of from the client, it won't be possible to create a fake certificate and make the client trust it. However, I am not 100% sure.

Answer 1

It is perfectly fine to use a cryptographic hash ("fingerprint") of the certificate for comparison instead of the certificate itself. And this is actually often done when implementing certificate pinning.

A man in the middle would not be able to generate a certificate and matching private key where the certificate has exactly the same fingerprint as your self-signed one as long as the hash algorithm used for the fingerprint is strong enough. Given that SHA-256 is considered sufficient as signature algorithm in a certificate you can also consider it sufficient for this fingerprint.

Of course, whenever this self-signed certificate might be compromised you need to change your application, but as long as this is in your control this should not be a problem.