Is it possible to issue multiple certificates with a same common name?

[noyle]

Well, I read the document about Cerbot for manually signing for certificates. For example, let’s call it Command A:
certbot .... -d example.com -d example.net -d example.org
will issue a certificate with common name example.com and example.com, example.net, and example.org as DNS names in SAN.

And then, re-running the above command to still use example.com as the first -d parameter but with some other different domain names (let’s call it Command B) would result in renewing the certificate just issued.

So, it seems that it’s not possible to issue multiple certs with a same common name at this moment. But what if I run Command B, either:

1. in the same OS but with a different Let’s Encrypt account;
2. in a different OS* with the same Let’s Encrypt account as what I ran Command A;
3. in a different OS* with a different Let’s Encrypt account;
4. Or even I run Command A in a different OS*;
5. or other circumstances when I could sign for multiple certificates with a same common name.

* a different OS could mean a different machine or a different system in the same machine.

Could I successfully have these certificates issued?

An example for this scenario:
Cloudflare used to issue certificates with sni123456.cloudflaressl.com as the common name and different DNS names in SAN.
But nowadays, it just issues certificates with sni.cloudflaressl.com as the common name but for different sites, it’ll have different SANs, e.g., *.example.com and example.com as DNS names in SAN for site example.com, *.example.net and example.net as DNS names in SAN for site example.net.

[mnordhoff]

If you run "certbot -d example.com -d example.net", it will issue a certificate for those two names, with example.com as the common name, and save it in /etc/letsencrypt/live/example.com/ (assuming there isn't already a different certificate there).

If you then run "certbot -d example.com -d example.org", it will issue a certificate for those two names, with example.com as the common name, and save it in /etc/letsencrypt/live/example.com-0001/ (assuming there isn't already a different certificate there).

@noyle

And then, re-running the above command to still use example.com as the first -d parameter but with some other different domain names (let’s call it Command B) would result in renewing the certificate just issued.

So, it seems that it’s not possible to issue multiple certs with a same common name at this moment.

That's not correct -- Certbot will only offer to renew the previous certificate if the set of names is the same.

It's absolutely possible to issue multiple certificates with the same common name (or same names in the SANs).

@noyle

But what if I run Command B, either:

1. in the same OS but with a different Let’s Encrypt account;
2. in a different OS* with the same Let’s Encrypt account as what I ran Command A;
3. in a different OS* with a different Let’s Encrypt account;
4. or other circumstances when I could sign for multiple certificates with a same common name.

* a different OS could mean a different machine or a different system in the same machine.

Could I successfully have these certificates issued?

All of that is also possible.

One thing is, your ACME client has to be able to validate all of the names in a certificate. So to put the same name in different certificates issued on different computers, they all have to be able to validate that name. DNS validation is good for this.

The rate limits are another factor. In particular, the Certificates per Registered Domain rate limit would quickly prevent Cloudflare from issuing millions of certificates for cloudflaressl.com without a rate limit increase.

---

As an example, I have several Let's Encrypt certificates with *.mattnordhoff.net as the common name, including:

• crt.sh | 2108437121
• crt.sh | 2094889967

(I use DNS validation.)

(I don't actually endorse using wildcards when you can avoid it.)

---

The Common Name is not actually technically important. Despite browsers persistently giving it a prominent location in their certificate info screens, modern TLS clients use the list of names in the Subject Alternative Names extension. They may even completely ignore the Common Name. Unless you're concerned about support for obsolete clients, there isn't much technical reason to concern yourself with which name is in the Common Name field.

[Osiris]

Can’t you use --cert-name to trick certbot in getting a new certificate even when everything else is the same? For example, consider these three commands:

certbot --cert-name dotcom -d example.com -d example.org -d example.net
certbot --cert-name dotorg -d example.org -d example.net -d example.com
certbot --cert-name dotnet -d example.net -d example.com -d example.org

As far as I know, certbot uses the first hostname as the common name. By rotating the sequence of -d options and using --cert-name to generate separate certificates, you should be getting the result you’d want. I haven’t tested this though, so YMMV.

That said, I agree with @mnordhoff: the common name is an obsolete and deprecated element. Not really any reason to pay special attention to it.

[mnordhoff]

--duplicate would probably work.

[noyle]

@mnordhoff

If you run "certbot -d example.com -d example.net", it will issue a certificate for those two names, with example.com as the common name, and save it in /etc/letsencrypt/live/example.com/ (assuming there isn't already a different certificate there).

If you then run "certbot -d example.com -d example.org", it will issue a certificate for those two names, with example.com as the common name, and save it in /etc/letsencrypt/live/example.com-0001/ (assuming there isn't already a different certificate there).

Thanks for the explanation and example. It's really behind the scene with what Certbot has been doing.

@mnordhoff

That's not correct -- Certbot will only offer to renew the previous certificate if the set of names is the same.

@Osiris

Can't you use --cert-name to trick certbot in getting a new certificate even when everything else is the same? For example, consider these three commands:
(...)

Ya, I just have forgotten the --cert-name parameter.. Thanks for reminding me of this usage, @Osiris.

@Osiris

That said, I agree with @mnordhoff: the common name is an obsolete and deprecated element. Not really any reason to pay special attention to it.

Makes sense and I've read some threads here about removing the common name field or replacing it with some serial like strings. I thought the common name should be unique across the whole Internet which was contradicted with what I saw from Cloudflare. So I've gone here for help.

Thanks very much for @mnordhoff's sharing of the example of using a wildcard certificate as the common name, and I definitely need to review the rate limit issue and gonna to check --duplicate's usage.

I think I should mark all the replies as solution!

Edited to add: ahh.. only one solution can be checked..