Take this scenario as an example: An organization has a few build servers that periodically check out source from a repository and builds everything. When a build finishes the binaries are code signed and archived and sometimes posted to the public along with the signatures and public certificate.

Assuming that:

  • The private EV cert is stored on a hardware token connected to the signing server, presumably in a physically secure environment (code signing environment).
  • the server would likely be Linux based.

What precautions are appropriate for such a signing server, HSM or otherwise.

  • Should the signing environment be located behind a locked door accessible only with an id badge.
  • Could denying simple physical accessibility be enough (place the signing environment in a ventilated and physically secure box?
  • What are the considerations for how physically secure the environment should be?
  • Would a locked server room sufficiently secure?
  • When is it unsound to have a code signing server connected to the company network? (To provide access to build servers)
  • Is key based ssh sessions enough to secure communications between build servers and the signing server over the company network?


  • 2
    That's many questions in one. Commented Nov 16, 2015 at 14:55
  • When you say "hardware token" do you mean a USB drive? Or an actual hardware security token, that never discloses the private key to the server?
    – paj28
    Commented Nov 16, 2015 at 15:34
  • Most certificate vendors say they deliver private keys on "encrypted token containing the private key." So, the later.
    – Whome
    Commented Nov 16, 2015 at 15:50
  • 1
    The required level of security depends on your requirements for security. You need to perform a proper risk analysis to find out which security precations can be justified and which can't.
    – Philipp
    Commented Nov 16, 2015 at 17:03

1 Answer 1


The major principle to consider is this: the private key should never move.

In no way should the code signing environment be accessible to the build/test environment. If the build environment can fulfill code signing requests directly it means compromising the build/test environment (a space with an enormous attack surface) would compromise your code signing.

The code to be signed must be relocated to the signing environment, the key cannot be moved to the build environment.

One solution I can think of for this is for the build system to publish qualified build artifacts and for a key custodian (an actual person) to get those build artifacts, sign them in the signing environment, and then publish the signed artifacts to an artifact repository.

Preferably the signing environment would be physically isolated, but for business reasons the level of protection you place on it needs to not exceed the risk of key exposure multiplied by the cost of key exposure. The signing environment in a very low risk scenario (you only have code signing for deployment convenience and accept the risk of reputational damage and legal liability if maliciously used) could be the key custodian's own workstation if it is sufficiently secured.

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