Solution 1:

To my knowledge, there is no difference between wildcard and normal certificates. So long as you have full control over domain.com's DNS, then there's no reason not to use a wildcard. In fact, I would recommend it in your case. What are your specific concerns with them?

(IMO, Redirects such as the one you suggest are always a bit of a fudge when they're visible to the end user.)

Solution 2:

From a technical aspect it would be just as secure. You would still be using the same encryption you would with a non-wildcard cert. What is it that they are saying is less secure?

Solution 3:

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 *.example.com.

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 legitimate.example.com.

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.