CODEWITHSUNDEEP
c#sslssl-certificate
g.pickardou
g.pickardou

Reputation: 35822

How can I implement trust only one specific certificate (my own) using code, in ServerCertificateValidationCallback

Context

The client code have to connect to a remote web api. SSL is mandatory because of sensitive information exchanged on the wire. We have our self issued certificate a In the project there is no currently what is properly configured in the remote IIS, and everything tested OK, except the certificate is not trusted.

I know I can install the certificate on the local machine and trust in it. However for some reasons (for example, there are Xamarin Android clients too) it is not a suitable solutions.

Current workaround is to simply ignore the certificate error in code, which is working both on desktop both on Android Xamarin:

ServicePointManager.ServerCertificateValidationCallback =
(s, certificate, chain, sslPolicyErrors) =>
{
    // Here I would like to check against that the certificate
    // is the specific one I issued, and only that case return with true

    // if (what is the most suitable to write here?) 
    return true;
};

Question

Note: this is development/testing phase. In production there will be a certificate installed created by a trusted certificate authority.

Now I have bad feeling about accepting anything, so I would like to narrow it. How to check against that the certificate is the specific one I issued, and only that case return with true. Is that a working idea to run the code, place a breakpoint, and get the certificate.Thumbprint, then write an if to check against it?

(edit) ...or better... get the PublicKeyString and checking against it?

Upvotes: 1

Views: 200

Answers (1)

pepo
pepo

Reputation: 8867

Checking against thumbprint is IMHO an OK option. With thumbprint you can narrow the trust to exactly one certificate.

Checking against public key or Subject Key Identifier is also OK but you will expand the trust to the same key pair. There can be several certificates issued on the same public key (with or without the same Distinguished Name).

As @bartonjs stated another option is to check raw data. This approach has the same power as checking against thumbprint. The benefit of this would IMO be that when you look at the code a year from now you will still know what certificate you trust :)

Anyway when checking against the exact certificate keep in mind that the certificate will expire someday (i.e. let's encrypt issues a 3 month certificate if I remember correctly) and your application will have to be redeployed with a new certificate check. You would have to keep track of expiration date of the certificate.

Upvotes: 2

Related Questions