Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
3  
"embedded (securely) into the program". Do you mind sharing how you plan to achieve that feat? –  Bruno Rohée Aug 30 '11 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 Aug 30 '11 at 18:39
    
Good enough for what? –  this.josh Aug 30 '11 at 22:23
    
Good enough for me to generate my own keys at build time and sign. –  Ants Aug 31 '11 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 Sep 1 '11 at 17:28

1 Answer 1

up vote 5 down vote accepted

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".

share|improve this answer
    
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 Apr 16 '13 at 18:09

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.