At build time for a program, I would like to generate a new key pair, and create a certificate that will be embedded (securely) into the program. The purpose of the key pair is to digitally sign an XML document. I would like the to have the chain associated with the key pair go all the way up to my certificate that I have on my build machine, and then up to the CA that signed the cert that went on the build machine.

Is a SSL certificate good enough? Or a code signing certificate? Or is there a specific kind of certificate that I need to request from the CA that I'll be getting my certificate from?

  • 3
    "embedded (securely) into the program". Do you mind sharing how you plan to achieve that feat? Commented Aug 30, 2011 at 15:40
  • I should have said "embedded (relatively securely) into the program". I was looking as some white-box solutions, and if I didn't find anything down that route, having the key encrypted in a custom action DLL in the MSI. The custom action would decrypt the keys and insert them in the machine key store at install time.
    – Ants
    Commented Aug 30, 2011 at 18:39
  • Good enough for what?
    – this.josh
    Commented Aug 30, 2011 at 22:23
  • Good enough for me to generate my own keys at build time and sign.
    – Ants
    Commented Aug 31, 2011 at 0:50
  • Technically you don't need a commercial CA to create your own digital signing certificates. In fact, you can set up your own CA and self sign everything. The drawback is that when your certificate is checked on a user's machine they will not have your root CA in their certificate store and they will get an error or a warning message.
    – this.josh
    Commented Sep 1, 2011 at 17:28

1 Answer 1


A certificate "must" have exactly the characteristics that verifiers will look for. A "verifier" is any system which will look at your signature and the certificate, and try to decide whether the signature is acceptable.

Most verifiers handling X.509 certificates apply the rules mandated by the X.509 standard and the Internet X.509 profile. There are many such rules; the most important are:

  • A verifier will need to build a path (or chain) coming for a public key it knows a priori (the trust anchor) down to the end-entity certificate, which is the certificate containing the public key associated with the private key you used to sign the XML document.
  • Within the path, each certificate (except the last) is used to verify the signature on the next certificate. Each such certificate must have the Basic Constraint extension with the "CA" bit set, marking the certificate as being a CA, i.e. suitable for verifying a signature on the next certificate in the path. Commercial CA normally refuse to issue certificates with the CA bit set, or do so at a hefty price, so chances are that your "certificate on your build machine" is not a CA certificate.
  • Any certificate may have a Key Usage extension, which spells out the allowed usages for the public key in the certificate. To properly interoperate with common verifiers, an EE certificate used to sign XML document should have a Key Usage extension with the digitalSignature and nonRepudiation flags set (or no Key Usage extension at all). Whether a certificate is "a SSL certificate" or a "code signing certificate" or any other such name, is mostly a matter of what flags are set in its Key Usage extension.
  • And, of course, the EE certificate should host a public key suitable for signing things, i.e. RSA, DSA, ECDSA... but not Diffie-Hellman.

The important point is that chaining your "embedded certificate" to your "build machine certificate" makes sense only if you want your XML signatures to be verifiable by generic verifiers, who will not know of your specific application, and use a generic set of trust anchors (including the one which sold you your "build machine certificate"). Chances are that it will not work, because it is improbable that your "build machine certificate" has the "CA" bit set. To check the contents of a certificate, use OpenSSL: the command-line tool (already included in MacOS X, any good Linux or *BSD, and available for Windows tool) can be used thus:

openssl x509 -text -noout -in cert.pem
openssl x509 -text -noout -inform DER -in cert.crt

(Use the first if the certificate is in PEM format, the second if it is in DER; or just try both.)

If you control the verifiers (i.e. in your application, the system which will verify the signature on the XML document will be some software that you also provide), then plugging into the build machine certificate up to the commercial CA is useless; you'd be better off creating your own CA and making certificates. OpenSSL can do that, or you could go for a more graphical solution like EJBCA.

I deliberately make no assertion whatsoever on the soundness of your concept of "secure embedding of a certificate".

  • Is this still the case? "Commercial CA normally refuse to issue certificates with the CA bit set, or do so at a hefty price..."
    – yzorg
    Commented Apr 16, 2013 at 18:09

You must log in to answer this question.

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