SSL Certificates Multi vs. Singles

If you want to use a certificate in for multiple sites or systems, you need either a wildcard certificate like "*.mydomain.com" or a SAN certificate that has a each FQDN listed in the certificate. In terms of the answer to your question, we use a wildcard cert on most of our systems. There are a few applications that do not support it, but otherwise this is the process we use. 

1. Yes if you update the existing certificate (assuming it has life left) With a Subject Alternative Name (SAN) of vpn.your-domain.com for example.

2. a Yes you can see all the SAN entries on a certificate.
2. b Yes but they are hostnames not subdomains.

3. As Rodney has pointed out, a wildcard cert is probably best for your requirements.

Certificates

</P>

Dear all thank you for participating to my question.

It is good to hear that with a Wildcard Certificate the SANs cannot be seen, on the other hand as per @Deman recommendation a renewal of a Wildcard generated with errors would cause a big headache and trouble.

Its more clear now of what each type of SSL can offer, but on the other hand I am confused.

Wildcard is easier to maintain but vulnerable in case of misconfiguration, separate certificates are the opposite.

As commented above by Deman it is better to have Wildcard certificates for other servers and use mutidomain cert for Exchange as using wildcard on exchange server will throw up some errors/warnings.

I'd suggest it's actually more secure to use separate certs for different platforms/servers where possible. If the wildcard certificate's private key is exposed (and even when you use a SAN cert), you'd have to change the certificate on all of the servers that use it. With individual certificates, only the one certificate would need to be changed.

We actually use a wildcard cert on our Exchange server and have not experienced any issues. In fact, we just finished updating our certs over the past week. I see above where some mention problems, but we not not experienced any of these issues. 

Q1) Is it possible to use the existing Certificate of Exchange Server by adding the subdomain assigned to the VPN?

If you mean modify a cert, then no.

You can always generate a new cert, covering whatever hosts/domains you like.

Q2) If yes, and a user who is accessing the Exchange OWA opens the browsers SSL padlock will he be able to see all the subdomains assigned to this SSL Certificate? Since, in that case, it will help a possible hacker to see the available subdomains.

See #1.

This depends on how you generate the cert.

For example if you look at CloudFlare certs, when CloudFlare HTTPS is working, you'll see sometimes 100s or more sites covered.

This seems like a huge security flaw to me, as any cert cracked, then gives access to all site HTTPS conversations.

I'd avoid this like the plague.

Q3) Security wise, is it recommended to have one Certificate with various subdomains to cover various applications and Services or is it better to issue different SSL Certificates for each platform/service?

a) Use https://LetsEncrypt.org for free certs that are recognized by all client software now + are rock solid.

b) https://www.experts-exchange.com/questions/29178012/Exporting-a-UCC-SSL-to-a-Windows-Apache-Web-Server-and-Configuring-Apache-to-use.html provides good coverage of initial cert generation + setting up hands-free, auto-renewals, forever.

c) For me I only create either a simple cert covering the bare domain + www, or a simple cert covering a single host (members, dev, whatever) or if 60+ hosts require coverage on a single domain use a wildcard cert.

The 60+ hosts coverage wildcard cert is a LetsEncrypt requirement, as 61+ hosts will be rejected for cert generation.

Thank you all for your Feedback!!

To be fair, I have marked DEMAN-BARCELO (MVP) Thierry as the one who has provided the solution since he was the first covering the biggest part of my questions.

Another consideration not mentioned before, too many SAN's in a certificate might easily get rejected due to it's size.
Some browsers/ssl stacks have limits on the size a complete certificate can be when transmitted in the call setup.
(The whole certificate is part of the SSL exchange during setup, so short certificates have their benefits.