This is a follow up to this question I asked before.

While I am happy to custom verify the certificate from the client side using the thumbprint approach, there is one additional scenario I wish to cover.

The scenario I'm thinking of is if a malicious user gets hold of the self signed certificate (i.e. PFX file installed on machine running the Windows Service). I believe in this scenario this user can load the certificate in an application that's not the intended Windows Service, and the client will trust it because it will have the same thumbprint.

Is there a way to bind the self signed certificate to a specific application (the Windows Service in my scenario, which itself is a signed exe), so that it cannot be used/loaded by other applications? This means if the certificate is compromised, it is useless to the attacker as they can't use it in their "fake" service.

I thought of password protecting the PFX file, however that means I need to securely distribute the password, which brings me back to square one.

  • Are you asking how you can put the private key on someone else's computer so that your program can use it, but the computer's owner can't? Commented Feb 17, 2020 at 4:43
  • @JosephSible-ReinstateMonica Sort of. I'm asking if I can use a private key on a server app that gets installed on users' machines, and ensure that private key can only be used by that specific app, so that if the private key gets exposed, an attacker cannot use it from a custom built server app and get the client to trust his/her server, rather than the one I install.
    – Kakalokia
    Commented Feb 17, 2020 at 7:56
  • You're asking how to build something equivalent to effective DRM. If that were possible, Hollywood would use it and there would be no such thing as piracy. Commented Feb 17, 2020 at 12:00

2 Answers 2


If attacker gets access to a private key material of the server certificate, your security is compromised. What you can do is to add security to key storage and store the key in HSM (Hardware Security Module).

  • Would you be able to elaborate a bit further please? How would my service be configured to use the certificate, and how is an attacker prevented from using the same certificate if they get a hold of it? Any tutorials related to self signed certificates would be appreciated too. Thanks.
    – Kakalokia
    Commented Feb 15, 2020 at 14:03
  • 1
    the only option you have is to store key on HSM. HSM makes it extremely difficult to extract the key from device.
    – Crypt32
    Commented Feb 15, 2020 at 14:11
  • Unfortunately this won't be possible given the deployment model (service gets deployed to each user machine). The next best thing is protecting the certificate with a password, however can't think of a secure method to store the password.
    – Kakalokia
    Commented Feb 15, 2020 at 14:36
  • 1
    Then you are out of options. You have to either, change deployment model or accept the risks associated with the current model.
    – Crypt32
    Commented Feb 15, 2020 at 14:40

The ideal solution would be to use a custom Extended Key Usage (EKU) and to mark the Extended Key Usage as critical. Your application (the TLS client) then needs to validate the Extended Key Usage and make sure that it contains the custom OID you have defined.

TLS clients that do not know or understand your custom EKU OID (e.g. a web browser) will reject the certificate, because you have set the critical flag on the EKU which forces the client to drop the connection if it doesn't understand all the values in the field marked critical.

This way, you bind the certificate to your application by making it unusable for other applications that do not use your custom OID.

The only caveat is that you need to have some level of control over your TLS client library. If the TLS client you are using only offers very high level APIs you may not be able to use the custom EKU OID and the TLS library will reject your certificate, because it does not know your custom EKU OID.

  • Thanks for the answer. To clarify, are you saying that I specify an EKU on the self signed server certificate, and from the client side check that this EKU exists? If yes, how is that different from checking against the thumbprint? An attacker with access to the self signed certificate can still use it in their app? Or am I misunderstanding?
    – Kakalokia
    Commented Feb 16, 2020 at 21:55
  • You are right, I misread your question. An EKU will only prevent the attacker from using your certificate and key pair in different applications (e.g. a web browser, mail server, database server). However, an attacker can still spawn a malicious version of your application and attack the client with it. I think it is very hard to solve your specific problem, but you can take a look at Trusted Execution Environments and Intel SGX as it might be a good technology for a problem like this.
    – jnsp
    Commented Feb 16, 2020 at 22:06
  • Thanks for the pointers. I'll have a look.
    – Kakalokia
    Commented Feb 16, 2020 at 22:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .