I was a little confused about the question at first, since certificates are generally thought of as providing for only one subject in the typical case. Isn't securing a single dns record(/subdomain, see section 3) with an SSL domain validated certificate that is NOT a wildcard the standard case for a website?
Put simply, you can and should secure the subdomain mail.domain.com with a single non-wildcard certificate if it is a connection string for a resource of its own accord, but you shouldn't expect records in this subdomain to be covered by the same certificate as well.
The current accepted answer gives a good and concise answer to the general case, but could present unexpected caveats when recommending a wildcard certificate. So just to prevent a potentially dangerous misunderstanding about what end-entity certificates of various types can and can't do, I'd like to go into a little more depth, breaking down across three sections:
- The wildcard / non-wildcard choice
- How the name on the certificate relates to what you can present
- What a subdomain means in the context of the question.
Section 1: Wildcard vs. Non-Wildcard
- Pricing: This is the first one I want to mention. Commercial CA's charge ~3-5 times as much for a wildcard certificate versus a standard certificate. For example, at the time of writing, the cost for a 1-year standard secure site certificate from Symantec (was VeriSign) is $399. The cost for a 1-year wildcard certificate is $1,999 (~x5 standard). Symantec secure-site certificates (the cheaper option) can be used with Subject Alternative Names (SANs), which means that as long as you know the publicly-facing DNS names you're using and are going to be using for the next year, you don't need a wildcard certificate even for multiple websites or secure connection points.
Scope of potential exposure: As mentioned in a comment above, there are different levels of exposure if the private key leaks. With a certificate for a single web server, the attacker can impersonate that server only. For a single website, only the servers that website name resolves too (see section 2 - subject name matching). Using my all-publicly-facing-names on one SAN cert idea above, they can impersonate all your publicly-facing websites. With a wildcard certificate, they can impersonate anything and claim it comes from your domain. Security arguments against wildcard certificates have been presented in RFC's.
Name Matching: A non-Wildcard certificate matches only the precise subject name (specifically the Common Name or CN component of the subject name for most certificates). So any certificate resolution tied to mail.domain.com will work, even if it involves CNAMES or resolution to multiple IP addresses, but eg. smtp.mail.domain.com (or in a more typical usage email@example.com) will both NOT work unless they are configured as SANs. In this case a wildcard certificate *.mail.domain.com would work for smtp.mail.domain.com (and with our secure mail example assuming both id-pkix 3 4 and you manually configure wildcard S/MIME).
Future Proofing: This is where most of the recommendations to go wildcard-only come from. With a wildcard cert for your primary DNS domain 'domain.com', you can host any number of web sites below domain.com, even ones you didn't know you needed when you requested the certificate. You never need to worry about checking that the certificate presented matches the website name, because it will always match.
Planning: Re the points on future proofing, note that with a multi-SAN cert, ease of management is the same so long as you included all your current and planned future websites. You've got dozens of names to work with, so you can even add DNS names you're not planning to use but that you think the organisation might possibly use. Even if you wind up needing a name you didn't plan for halfway through the year, buying another multi-SAN cert has still left you spending, most likely, less than half of what a wildcard cert costs.
Wildcard limitations: Given the size of the price difference, I'm not sure the small
management overhead for going non-wildcard is worth the cost of a wildcard cert unless you are a large organisation with dozens to hundreds of publicly-facing DNS names to secure. Also keep
in mind the wildcard matches only one level in the DNS heirarchy
below domain.com. So if you want www.*.domain.com, you'll need a new
certificate specifically for www.[specificsubdomain].domain.com or
a SAN on the wildcard cert for *.*.domain.com or www.*.domain.com.
Note that CA's are often reluctant / will refuse to add SANs to a
Section 2: Subject Name Matching
One thing to keep to in mind is validation is based on the subject string on the client matching what is claimed in the certificate. For a web browser, this is the data entered into the address bar to reach the page. For an email client, the represented source email address, and so on for various client types and certificate usages.
So for a web server certificate, if I have this in DNS:
www.otherdomain.org A 172.16.254.1
But this in the hosts file on a specific machine:
That specific machine will have a subject name match with a server presenting a certificate for mail.domain.org on server 172.16.254.1, but clients reaching 172.16.254.1 via a DNS lookup to www.otherdomain.org will have a subject name mismatch for the same certificate. If I then add this CNAME in DNS:
mail.domain.org CNAME www.otherdomain.org
And ask all of my clients to go to mail.domain.org in their browser instead of www.otherdomain.org, the certificate will now stop presenting a certificate name mismatch to these clients. This is because the DNS resolution is opaque to the browser.
Section 3: DNS terminology
I want to point out as well that this terminology can be a little confusing, when you mention 'subdomain' my conclusion is a full-on zone, beneath your parent zone/domain where your primary name servers sit, this subdomain may have its own name servers and subordinate records below that.
(Although of course in the DNS hierarchy technically everything except root is a subdomain, there is a soft tendency to view records with no subordinates in the hierarchy as 'not subdomains', because conceptually they satisfy 'sub', but not necessarily all the aspects of a proper 'domain'. For instance you wouldn't generally view an A record as having administrative autonomy, even though you could later add a name server record and populate lookups below it. I'm aware this tendency doesn't necessarily match the technical reality.)
For a record resolving to a single 'resource' (website, server, workstation) I would normally either use just 'website/server/workstation', the generic 'DNS record', 'host(A) record', or to cover the possibility of a CNAME, F5 wizardry etc., at least a '[website/server/non-subdomain resource type] Fully Qualified Domain Name' (FQDN)