TL;DR: "Using a public key as a secret key is not a good idea. – MechMK1"
I think you're mis-understanding how certificates work.
which will be deployed with private / public key on all workstations. So all the stations have the same certificate and therefore the same public and private key.
It's not really "private" if every employee in your company has a copy of it. Non-exportable helps, but you should really be issuing a unique certificate to each device; imagine the mess you'll be in if one of your devices is stolen / hacked and you need to revoke the certificate!
Is it possible, correct and secure to use the raw public key of the certificate (as a string) as the HMAC-SHA256 password?
Remember that public keys are intended to be public. Even if you are intending to treat them as a super-secret value, there is no guarantee that all of the software that touches them will. Two examples:
- When a publicly-trusted CA issues a cert, they log it to public Certificate Transparency servers. For example, here is the CT logs for all
*.stackexchange.com
certificates, notice how many dev.
, qa.
and test.
certs there are in that list? By clicking into any of those, you can get the public key. If your certs came from a public CA, then I'll bet you can find them on https://crt.sh as well. This is not considered a problem because publicly-trusted certs are intended to be public in all aspects except the private key.
- When establishing a TLS 1.2 connection, the certificate (and public key within it) is sent un-encrypted over the internet (@dave_thompson_085 pointed out that in TLS 1.3 the certificate is encrypted).
Never assume that your certificates will be a secret.
So your question "Is it ok to use a public value as a password?" is a bit like "Is it ok to use my name as my banking password?; no, no it's not.
Sounds like you need to figure out a different way of (securely) distributing an HMAC key to your apps.