From what I have read, using a wildcard SSL/TLS certificate is not advisable, how do you do certifcate issuing & management in your SAAS application(linux) where each client has a user selected subdomain?
There is nothing wrong with "wildcard certificates". A wildcard certificate is equivalent to a certificate containing a lot of possible server names. If this maps well to your problem (e.g. you have a server with a lot of frontends who advertise distinct names, but all these names are in the same domain and you control that domain), then wildcard certificates are certainly a possibility. The main issues with wildcard certificates are:
In your situation, as I understand it, you have a hosting server, who runs a SSL server for several sites; the sites have names which follow the pattern
The wildcard certificate still seems the simplest and most robust method.
Using wildcard certificate isn't really an issue if you understand the implications.
However, if you do not want (or cannot) use a wildcard cert, then in your case you have little choice but issue a new, separate certificate for each subdomain.
In theory, you could also use SAN certificate but unless you know in advance the complete list of domains you're going to have to secure, it's going to be a solution that grows even more poorly than having a new certificate for each sub-domain.
Now, if you're not willing to use a wildcard certificate, why exactly are you unwilling to have a new cert issued for each new customer ?
Edit: you are concerned about losing the whole system in case your key is compromised. however, there is little practical reason why splitting the encryption using multiple keys will improve security: the only party that will be required to have access the to the private key are the server SSL endpoints so, assuming you have little control about what happen on the end server (and you fear that customer action will cause their own server to be compromized, perhaps because you let them run their own code, then the solution is to deploy a reverse proxy in front of your servers that will handle the public crypto and hold your key secure (you can even setup an internal SSL connections between the proxy and the servers if you want to encrypt communication inside your network).
Such a system will be simpler to manage and secure than having each server use their own certificate (plus, it'll be cheaper and can be implemented with off the shelf solutions).