Which FQDN hostname to use for SSL certificate signing request- when using a CNAME record

I think you can do this, but not the way you're trying to do it.

An SSL certificate is a statement binding a public encryption key to an X.500 structure which includes a CN, or Common Name, element; a signed certificate is one such where the binding is verifiably certified by a third-party certification authority, using the a public key already known to end-users (that stack of Certification Authority (CA) certificates living inside your browser).

When you visit an SSL-secured web site with a browser, the signed CN is made known to the browser. What the browser chooses to do with it is up to the browser. The browsers I'm aware of compare it to the host name requested, and error if it's different (or if that certified binding doesn't stand up to analysis, eg the signing certificate is not known to the browser or the binding is out-of-date, but that's a different issue). There's nothing that in principle stops you from getting a publicly-signed certificate where the CN is an IP address not a FQDN (fully-qualified domain name) [1], but that won't magically make the browser compare the CN with the IP address, instead of with the requested hostname.

I suspect the simplest way to solve your problem is to start your own CA, which is easy to do, and there are many public tutorials about; one is here. Once your end-users import your CA into their browsers, all certificates you mint will be accepted as authoritative.

You may then have a second problem in that you want to run a lot of NameVirtualHost sites on a single IP address. This has historically been insuperable, since (unlike TLS) SSL negotiation happens before anything else on a connection; that is, the CN embedded in your certificate is made known to, and used by, the client before the client is able to say what host they're trying to connect to.

Recently, a protocol extension called SNI (Server Name Indication) seems to have been introduced, which allows client and server to indicate that they'd like to do some host name stuff before the SSL certificate is presented, allowing the right one of a set of certificates to be given by the server. Apparently this requires apache 2.2.10, a sufficiently recent version of OpenSSL, and (importantly) client-side support.

So if I had to do what you're trying to do, I'd be looking at minting my own CA certificate, telling my end-users that they have to use browsers that support SNI and import my CA root certificate, and cutting and signing my own SSL certificates for each bugtrack site.

[1] OK, you may not have found anyone who'll do it, but that's an implementation detail. What I'm trying to show here is that even if you did, it wouldn't solve your problem.

No. It is not necessary to generate the CSR on the machine that you want to host the resulting certificate on. The CSR does need to be generated either using the existing private key that the certificate will be eventually paired with or its matching private key is generated as part of the CSR creation process.

What's important is not so much the originating host but that the private key and resulting public key are a matching pair.