4

A typical SSL cert is based on a common name for the domain (domain.com) sometimes (www.domain.com) as well.

I understand what a wildcard cert is used for (*.domain.com) and it would/should validate all subdomains for that domain.

If I want to have a single subdomain covered with an SSL certificate (mail.domain.com), is a wildcard certificate the only option? Or is it possible to use a standard SSL cert issued for that single subdomain?

I'm not asking for best practices, or a reason why one 'should really just use a wildcard cert'. I am asking from a technical standpoint of it being possible to secure a single subdomain with an SSL domain validated certificate that is NOT a wildcard.

PenguinCoder
  • 499
  • 2
  • 6
  • 17

4 Answers4

7

You can use SSL cert issued just for mail.domain.com without any problem. The biggest advantage of wildcard certs is there is only "one cert to rule them all" - you don't need to manage dozens of certs.

Ondra Sniper Flidr
  • 2,623
  • 11
  • 18
  • 3
    A point for using a separate certificate: If you have separate servers with separate keys, revoking just one of them in case of a failure might harm your operations less than revoking a key used for both (and an attacker can do less with it until you revoke it). – Paŭlo Ebermann Nov 19 '15 at 17:50
  • @PaŭloEbermann I entirely agree with your point, but would also point out for completeness that the private key can be independent of the certificate. Some higher-tier wildcard SSL vendors will sign multiple CSRs, provided they are all for the same *.domain.com pattern. This allows you to use a wildcard certificate while retaining separate private keys on each server. Of those providers, there are a select few which don't charge you more for each re-sign, either! – Cosmic Ossifrage Nov 19 '15 at 19:11
  • 2
    Keep in mind that while a cert for `*.domain.com` will validate for `subdomain.domain.com`, but it will NOT validate for `a.subdomain.domain.com`. It only works for one level. – Bradley Uffner Nov 19 '15 at 19:15
  • @CosmicOssifrage But if an attacker breaks into the mail server and recovers the private key, with a wildcard certificate he could use it to pretend to be your web server, too (until you get to revoke it). – Paŭlo Ebermann Nov 19 '15 at 19:29
  • (And yes, this is moot if you have two certificates for two domains using the same key.) – Paŭlo Ebermann Nov 19 '15 at 19:30
  • @PaŭloEbermann Indeed. This solution is not suitable for shared-many situations if the machines involved span different security classes or administrative domains. There's a very sound reason that major players will typically decrypt their SSL traffic in a set of highly-secured front-end reverse proxies, and re-encrypt with internal-only keys to communicate with back-end (less trusted, or operated by other groups) web and app servers. – Cosmic Ossifrage Nov 19 '15 at 20:14
1

If you own "domain.com" you can also request a certificate for "mail.domain.com". You will just need to prove your ownership of the root domain.

dtoubelis
  • 4,579
  • 1
  • 28
  • 31
0

Yes you can have a certificate that just covers a particular subdomain. You can also have a certificate that covers more than one subdomain without being a wildcard.

Be aware that SSL/TLS traditionally only allowed one certificate per IP/port combination. There is an extension called SNI that fixes that but there are still some older clients out there that don't support it (most notablly internet explorer on windows XP).

Peter Green
  • 4,056
  • 10
  • 29
0

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:

  1. The wildcard / non-wildcard choice
  2. How the name on the certificate relates to what you can present
  3. 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 someguy@mail.domain.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 wildcard certificate.

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:

172.16.254.1 mail.domain.org

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)

Community
  • 1
Bruno
  • 281
  • 1
  • 10