Will LE ever provide Unified Communications Certificates? See http://info.ssl.com/article.aspx?id=12157
1 Like
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.
2 Likes
Excellent! Thanks for the response.
This could be useful for me, I have 11 certificates for one domain.
Okay, I’ll bite. Why do you have eleven certificates for a single domain?
2 Likes
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.
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
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.
example.com
www.example.com
git.example.com
mirror.example.com
are each a different domain (4 domains). Not one domain.
@NOYB Not really.
In this case example.com is the domain, www, git & mirror are hosts. Normally in this situation you’d use a wild card certificate on *.example.com
They are FQDN’s. In that form a hostname is a domain name.
Hostname: https://en.wikipedia.org/wiki/Hostname
@NOYB Now your talking semantics. Bottom line is, they are all the same domain.
While you’re on Wikipedia, perhaps you should also read
In your world, you would have have actually registered a domain called 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 is not the same domain as y.example.com . It is not semantics.
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
So given, git.example.com, it would return example.com
You could have however many name.example.com’s and they are all under under the single domain example.com
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 would need to be validated totally independently of 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.
3 Likes
So what’s the problem with doing wild card certificates?
If you control www.example.com, then it’s hard to imagine you don’t control git.example.com seeing as at the DNS level you’d be controlling example.com
(Yes I know you can delegate subdomains, but we’re not talking about that here)
Each of the name.example.com's are a different domain. Not a single domain. Being under another domain (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. Each of the subdomain certs is a cert for a specific and unique domain.
the example you have given
example.com
www.example.com
git.example.com
mirror.example.com
are sub-domains not separate domains.
example.com is the domain name
anything.example.com is a sub-domain
For this you would use a wildcard SSL.
different domain names would be
acme.com
sport.com
laugh.com
For this you would need a UCC cert
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
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:
I'd still agree with what I said a year ago: