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.