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