[GauntletWizard]

You are putting the private key on the server, it just happens to be encoded as data in the binary. It would not take an attacker long, looking at your executable in a sandbox, to figure out where it is - not matter how it is that you've obfuscated it.

From a threat modeling perspective, nothing you do will prevent an attacker that is able to run as your application user (or root) on your server. That's fine; The level of obfuscation you've put into place will (possibly) keep some of the script-kiddies who aren't targeting you directly from realizing they've stolen your key.

The attack you should be concerned about is on your distribution side: You can't copy that binary anywhere else without revealing your key. You can't put it in a docker image repository or a java package repository or even a s3 bucket - Because those become places that your key can be revealed. And you want to do those things. You want a copy of precisely the binary you deployed.

[herdcall]

The key will be encrypted, not obfuscated - it won't be possible to retrieve it even if they have the binary without my password. This is what you also suggested, right? I just agreed with you above. Perhaps you missed the part about using the password? I'm confused.

[GauntletWizard]

There's two objections that remain: It's impossible to rotate the key without recompiling the binary (and every recompile is an opportunity to add bugs, though a good compile environment minimizes it), and that it's easy to mess up the encryption - Are you using a PKCS12 file format with DES? That's trivially crackable (to the point that most modern libraries recommend using a builtin password). And even if you've got the encryption part right, you're left with the password distribution problem, which is exactly the same problem; You've got a small (12 characters or 4k, not a lot by modern standards) bit of sensitive data that needs to be distributed to the app at startup.