# Will this service supply UCC certificates?

**URL:** <https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105>\
**Category:** Issuance Policy\
**Created:** [August 13, 2015, 9:14pm UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105 "2015-08-13T21:14:30Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![jrivett](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jrivett/32/63_2.png) [@jrivett](https://community.letsencrypt.org/u/jrivett)\
**Post date:** [August 13, 2015, 9:14pm UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/1 "2015-08-13T21:14:30Z")

</div>

Will LE ever provide Unified Communications Certificates? See [http://info.ssl.com/article.aspx?id=12157](http://info.ssl.com/article.aspx?id=12157)

---

<div class="post-metadata">

**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\
**Post date:** [August 13, 2015, 9:29pm UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/2 "2015-08-13T21:29:22Z")

</div>

UCC is an unfamiliar acronym to me, but from reading that article it sounds like it means a certificate with multiple DNS names in the subjectAlternativeNames field. In other words, a certificate that can serve multiple domains without relying on Server Name Indication.

LE will support such certificates from day 1. All you have to do is ask the Let’s Encrypt client to authorize multiple domain names.

---

<div class="post-metadata">

**Author:** ![jrivett](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jrivett/32/63_2.png) [@jrivett](https://community.letsencrypt.org/u/jrivett)\
**Post date:** [August 14, 2015, 1:42am UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/3 "2015-08-14T01:42:08Z")

</div>

Excellent! Thanks for the response.

---

<div class="post-metadata">

**Author:** ![Jeroen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jeroen/32/270_2.png) [@Jeroen](https://community.letsencrypt.org/u/Jeroen)\
**Post date:** [August 23, 2015, 12:10am UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/4 "2015-08-23T00:10:34Z")

</div>

This could be useful for me, I have 11 certificates for one domain.

---

<div class="post-metadata">

**Author:** ![jrivett](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jrivett/32/63_2.png) [@jrivett](https://community.letsencrypt.org/u/jrivett)\
**Post date:** [August 23, 2015, 3:49am UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/5 "2015-08-23T03:49:55Z")

</div>

Okay, I’ll bite. Why do you have eleven certificates for a single domain?

---

<div class="post-metadata">

**Author:** ![Jeroen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jeroen/32/270_2.png) [@Jeroen](https://community.letsencrypt.org/u/Jeroen)\
**Post date:** [August 23, 2015, 3:34pm UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/6 "2015-08-23T15:34:33Z")

</div>

Well, it starts with (www).example.com, then you get uniqueservername., then you get git., then you get mirror., and after a while it all just stacks up to about 11 certificates.

---

<div class="post-metadata">

**Author:** ![NOYB](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/noyb/32/247_2.png) [@NOYB](https://community.letsencrypt.org/u/NOYB)\
**Post date:** [August 23, 2015, 8:04pm UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/7 "2015-08-23T20:04:25Z")

</div>

Those are not all one domain. They are each their own domain. So you have 11 domains and a cert for each of them. Not 1 domain and 11 certs.

Domain Name: [https://en.wikipedia.org/wiki/Domain\_name](https://en.wikipedia.org/wiki/Domain_name)

---

<div class="post-metadata">

**Author:** ![Jeroen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jeroen/32/270_2.png) [@Jeroen](https://community.letsencrypt.org/u/Jeroen)\
**Post date:** [August 23, 2015, 8:32pm UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/8 "2015-08-23T20:32:07Z")

</div>

No, it is all one domain.  
You could argue though that they are all under different subdomains/hostnames, and I would agree with you on that.

I have 11 subdomains/hostnames that require a separate cert each, 11 domains would be a bit too expensive for me.

---

<div class="post-metadata">

**Author:** ![NOYB](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/noyb/32/247_2.png) [@NOYB](https://community.letsencrypt.org/u/NOYB)\
**Post date:** [August 23, 2015, 9:01pm UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/9 "2015-08-23T21:01:46Z")

</div>

[example.com](http://example.com)  
[www.example.com](http://www.example.com)  
[git.example.com](http://git.example.com)  
[mirror.example.com](http://mirror.example.com)  
are each a different domain (4 domains). Not one domain.

---

<div class="post-metadata">

**Author:** ![ac000](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ac000/32/71_2.png) [@ac000](https://community.letsencrypt.org/u/ac000)\
**Post date:** [August 24, 2015, 1:58am UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/10 "2015-08-24T01:58:13Z")

</div>

@NOYB Not really.

In this case [example.com](http://example.com) is the domain, www, git & mirror are hosts. Normally in this situation you’d use a wild card certificate on \*.example.com

---

<div class="post-metadata">

**Author:** ![NOYB](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/noyb/32/247_2.png) [@NOYB](https://community.letsencrypt.org/u/NOYB)\
**Post date:** [August 24, 2015, 2:55am UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/11 "2015-08-24T02:55:52Z")

</div>

They are FQDN’s. In that form a hostname is a domain name.

Hostname: [https://en.wikipedia.org/wiki/Hostname](https://en.wikipedia.org/wiki/Hostname)

---

<div class="post-metadata">

**Author:** ![ac000](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ac000/32/71_2.png) [@ac000](https://community.letsencrypt.org/u/ac000)\
**Post date:** [August 24, 2015, 10:52am UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/12 "2015-08-24T10:52:34Z")

</div>

@NOYB Now your talking semantics. Bottom line is, they are all the _same_ domain.

While you’re on Wikipedia, perhaps you should also read

> **[Fully qualified domain name](https://en.wikipedia.org/wiki/Fully_qualified_domain_name)**
>
> A fully qualified domain name (FQDN), sometimes also referred to as an absolute domain name, is a domain name that specifies its exact location in the tree hierarchy of the Domain Name System (DNS). It specifies all domain levels, including the top-level domain and the root zone. A fully qualified domain name is distinguished by its lack of ambiguity: it can be interpreted only in one way. It usually consists of a host name and at least one higher-level domain (label) separated by the symbo The D...

In your world, you would have have actually _registered_ a domain called [git.example.com](http://git.example.com)? I don’t think so…

---

<div class="post-metadata">

**Author:** ![NOYB](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/noyb/32/247_2.png) [@NOYB](https://community.letsencrypt.org/u/NOYB)\
**Post date:** [August 24, 2015, 11:33am UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/13 "2015-08-24T11:33:51Z")

</div>

> [@ac000](#):
>
> In your world, you would have have actually registered a domain called [git.example.com](http://git.example.com)? I don't think so...

No. Not being "registered" has nothing to do with whether or not it is a domain name. And [x.example.com](http://x.example.com) is not the same domain as [y.example.com](http://y.example.com) . It is not semantics.

---

<div class="post-metadata">

**Author:** ![ac000](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ac000/32/71_2.png) [@ac000](https://community.letsencrypt.org/u/ac000)\
**Post date:** [August 24, 2015, 12:09pm UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/14 "2015-08-24T12:09:08Z")

</div>

Err, you have to register a domain name in order to get one!

Given a FQDN it’s often useful to know what the _registered_ domain is, in fact there is code to do just that

> **[usrflo/registered-domain-libs](https://github.com/usrflo/registered-domain-libs)**
>
> Detect the registered domain for a given domain name in C, Perl and PHP, based on Mozillas effective TLD listing - usrflo/registered-domain-libs

So given, [git.example.com](http://git.example.com), it would return [example.com](http://example.com)

You could have however many _name_.example.com’s and they are all under under the single domain [example.com](http://example.com)

---

<div class="post-metadata">

**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\
**Post date:** [August 24, 2015, 7:30pm UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/15 "2015-08-24T19:30:50Z")

</div>

I think this disagreement is just about different informal uses of terminology.

From the current Let’s Encrypt CA’s point of view, we will separately check whether each full-qualified domain name (not just top-level domain) exists and is under the control of the requesting party before agreeing to include that name in the certificate. We do not currently take advantage of knowledge about relationships between one name and another, so [foo.example.com](http://foo.example.com) would need to be validated totally independently of [bar.example.com](http://bar.example.com). For our purposes, we thus distinguish between full-qualified domain names (which are created in the DNS) and top-level domain names (which are registered with a domain registrar) and the former are the names that we validate for our issuance purposes.

I don’t think there’s a need to argue about which kind of name can be referred to as a “domain name” in which context. I think everyone understands that top-level domains are registered with registrars and then subdomains are created under them using the domain name system, and that there are various possible ways of referring to these practices informally, which hopefully everyone will understand from context. I hope the validation practices of our CA will be clear to everyone who’s thinking of requesting certs for a particular configuration.

---

<div class="post-metadata">

**Author:** ![ac000](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/ac000/32/71_2.png) [@ac000](https://community.letsencrypt.org/u/ac000)\
**Post date:** [August 24, 2015, 7:42pm UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/16 "2015-08-24T19:42:09Z")

</div>

@schoen

So what’s the problem with doing wild card certificates?

If you _control_ [www.example.com](http://www.example.com), then it’s hard to imagine you don’t _control_ [git.example.com](http://git.example.com) seeing as at the DNS level you’d be controlling [example.com](http://example.com)

(Yes I know you can delegate subdomains, but we’re not talking about that here)

---

<div class="post-metadata">

**Author:** ![NOYB](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/noyb/32/247_2.png) [@NOYB](https://community.letsencrypt.org/u/NOYB)\
**Post date:** [August 24, 2015, 10:41pm UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/17 "2015-08-24T22:41:26Z")

</div>

> [@ac000](#):
>
> You could have however many [name.example.com](http://name.example.com)'s and they are all under under the single domain [example.com](http://example.com)

Each of the _name_.example.com's are a different domain. Not a single domain. Being under another domain ([example.com](http://example.com)) does not preclude them from being a domain nor make them a single domain. Having a cert for each of them is not multiple certs for a single domain. The single domain would be [example.com](http://example.com). Each of the subdomain certs is a cert for a specific and unique domain.

---

<div class="post-metadata">

**Author:** ![RussMichaels](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/russmichaels/32/15970_2.png) [@RussMichaels](https://community.letsencrypt.org/u/RussMichaels)\
**Post date:** [August 29, 2017, 10:21pm UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/18 "2017-08-29T22:21:14Z")

</div>

the example you have given  
[example.com](http://example.com)  
[www.example.com](http://www.example.com)  
[git.example.com](http://git.example.com)  
[mirror.example.com](http://mirror.example.com)

are sub-domains not separate domains.  
[example.com](http://example.com) is the domain name  
[anything.example.com](http://anything.example.com) is a sub-domain

For this you would use a wildcard SSL.

different domain names would be  
[acme.com](http://acme.com)  
[sport.com](http://sport.com)  
[laugh.com](http://laugh.com)

For this you would need a UCC cert

---

<div class="post-metadata">

**Author:** ![schoen](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/schoen/32/79_2.png) [@schoen](https://community.letsencrypt.org/u/schoen)\
**Post date:** [August 29, 2017, 10:42pm UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/19 "2017-08-29T22:42:04Z")

</div>

Currently Let's Encrypt does not make this distinction or use this terminology this way, but we're happy to issue such certificates and do so every day.

Looking at the Certificate Transparency logs, an example that we issued recently is

> **[crt.sh | 201259093](https://crt.sh/?id=201259093)**
>
> Free CT Log Certificate Search Tool from Sectigo (formerly Comodo CA)

```nohighlight
            X509v3 Subject Alternative Name: 
                DNS:thescholarreport.com
                DNS:tls.automattic.com
                DNS:wrappedpr.co.uk
                DNS:www.thescholarreport.com
                DNS:www.wrappedpr.co.uk

```

This was issued using our normal procedures, policies, and technology and nobody had to do anything out-of-the-ordinary to request this certificate. Overall, I'd casually guess that about 10% of our certificates are UCC certificates under this definition, though I haven't investigated this carefully and the correct number could be quite a bit higher or lower.

Let's Encrypt currently doesn't issue wildcard certificates at all, but is planning to do so starting in January:

> **[Wildcard Certificates Coming January 2018 - Let's Encrypt](https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-jan-2018.html)**
>
> Update, March 13, 2018
> Wildcard certificate support is live.
> Let’s Encrypt will begin issuing wildcard certificates in January of 2018. Wildcard certificates are a commonly requested feature and we understand that there are some use cases where they...

I'd still agree with what I said a year ago:

> [@schoen](#):
>
> I don't think there's a need to argue about which kind of name can be referred to as a "domain name" in which context.

---

<div class="post-metadata">

**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\
**Post date:** [August 29, 2017, 10:44pm UTC](https://community.letsencrypt.org/t/will-this-service-supply-ucc-certificates/105/20 "2017-08-29T22:44:10Z")

</div>


