A certificate is basically a binding between an identity and a public key, but there are details:
- The notion of "identity" which is most adequate for your situation is not necessarily the same as the notion of identity for a SSL server certificate (i.e. a server DNS name...).
- The lifecycle of the private key matters: who generates it, where it is stored, whether there are backups...
- The certificate contents may activate or deactivate some usages, and you may want some control over that.
If you want to produce your own certificate, then you want to operate your own Certification Authority. There is nice opensource software for that (e.g. EJBCA). However, this course of action entails two main cost areas:
You have to operate the CA. PKI is 5% technology, 95% procedures; having the software is fine, but running it, managing physical access, renewals, audit... will be what costs the most, by far.
Certificates from your CA will be accepted by your machines only if the public key of your CA is installed in these machines as a root CA, or if your CA has been issued by another CA which is installed in your machines as a root.
Using certificates from a "commercial CA" solves the second point, but at a heavy cost. In particular, if you want to have your own CA, then it must be marked as a "CA certificate" (that's written in the Basic Constraints certificate extension). A commercial CA may accept to issue to you a CA certificate, signed by their own, but it will be expensive (think thousands of dollars, at least); and they will require that you operate your own CA within strict rules (including insurance, publication of a detailed and legally binding Certification Practice Statement, and so on).
If you just want to produce certificates for your own usages, on systems that you control, then it makes relatively little sense to rely on a commercial CA: it is much easier to simply have your own root, and install it in all relevant machines.
It is also quite possible that your problem at hand does not actually call for true "certificates". Certificates are a solution to a key distribution problem: the point of certificates is that a given system can gain knowledge a public key, and confidence in the identity of the key owner, dynamically, by virtue of seeing and validating a certificate. If, in your system, there are 8 keys altogether and you have control over all client and server, then chances are that you do not really need certificates; you just want asymmetric key pairs. Public keys are published a priori (pushed through configuration or hardcoded in relevant software).
For easy and cheap compatibility with existing protocols (e.g. SSL), it may be convenient to encode the public keys as something which looks like "certificates"; traditionally, these certificates will be "self-signed" because there is a non-optional field for a signature in the certificate format.
There is nothing intrinsically wrong with self-signed certificates if they map to your problem at hand. There is no need to invoke a PKI if your situation does not have a key distribution issue.