I agree with the other answers, that wildcard certificates are not inherently insecure.
However it is possible to introduce a security problem by using wildcard certificates incorrectly. The following security problem would not happen if your certificates are valid for only one domain each.
Imagine that you initially have a single server hosting all the subdomains. The adversary signs up for your service and gets assigned the domain
evil.example.com. This like all your other customers is covered by the certificate for
The adversary arranges for
evil.example.com to receive lots of traffic, so eventually that domain gets allocated a dedicated server. Now you have two physical servers with identical certificate.
At this point the adversary starts performing MITM attacks (whether that happens through DNS poisoning or malicious APs is not important). The adversary directs users of
legitimate.example.com to the IP address of
evil.example.com. Since the certificate says
*.example.com it is valid.
However the dedicated server for
evil.example.com doesn't know the domain name
legitimate.example.com, so it responds with the content from the default vhost, which is going to be
evil.example.com because this dedicated server doesn't have any other domains.
This attack scenario can be avoided if every server holding the certificate can respond to requests for all the subdomains. It is perfectly acceptable, if this sometimes means proxying the request from one server to another. As long as the proxying itself is secured against MITM attacks.
In a proper configuration the dedicated server for
evil.example.com would only start receiving requests for
legitimate.example.com once the adversary attempts to perform a MITM attack on users. It won't be able to server the content and instead proxies the request to the real server hosting
If the adversary is given sufficient control over the dedicated server hosting
evil.example.com to disable that proxying, then you do have a real security problem.