Domain ordering not respected, unexpected certificate subject

Help
21

If this helps, the specific platform my hosting provider requires that the common name be set to the domain name with the "www" in front, due to this platform being created before common name was deprecated. I've alerted their engineers to this impending change. The CSR workaround is allowing me to install the certs again, though it's causing a lot of manual labor for me as this specific platform requires CSRs to be generated through a web UI. Yes, I am looking at moving hosting platforms, but I've got around 1800 websites with certificates to migrate, so it's not a small project.

I had come to rely on this behavior since there is advice from community leaders in this forum (albeit, several years old) saying that the common name is set to the first domain name specified here, and the official docs didn't really say anything that I could find. Here's the comment: How can I easily make the Base Name and Common Name the same? - #2 by Patches

Is there any general sense of when Let's Encrypt intends to remove Common Name altogether as mentioned here by @jsha : Domain ordering not respected, unexpected certificate subject - #6 by jsha ? Weeks, months, years?

The entire removal of the Common Name is the worst-case scenario here for me since my hosting provider would stop accepting all Let's Encrypt certificates if they aren't able to make the change before then or if I can't migrate away in time.

Since there is a Common Name being chosen by Let's Encrypt now, a new command line parameter to choose the Common Name seems like it would have very little downside, especially if it issued a deprecation warning. This would still allow issues to be raised in situations like mine that require updates to follow the new standards while allowing for a longer time frame for this migration. It may not an easy or quick change for everyone (it's not for me).

Thank you for your consideration.

1 Like
22

Worth adding: The Subject CN has been deprecated for verification since 2000 by RFC and the CA/B Forum supports that. Within the industry, the existing usage of Subject CN is considered to be legacy support only, and I think the only non-deprecated usage is for UX. Several browsers and projects completely ignore the field.

5 Likes
23

Update: We've decided to go back to the old behavior: issuance requests with no Subject CN in the CSR will have the first SAN copied into the Subject CN of the issued certificate. This requires a code change and a deploy cycle. We're planning to follow our usual deploy process for this, so assuming everything goes smoothly with next week's deploy, the old behavior should be live again by approximately next Thursday. If you have certificates expiring before then, please use the workaround discussed about (generating a custom CSR with the Subject CN you want to appear in the Subject CN of the issued certificate).

And in general, if you're reading the issue because you have a system that relies on a specific Subject CN in certificates, please post your use case so we can get an idea of what breakage to expect as we migrate to no-CN-in-Subject certificates.

I'm hesistant to commit to a specific timeline since we haven't decided on what exactly our timeline will be, but approximately months. And we're likely to have some way to request a fallback for a certain amount of time, TBD.

This is true, though in fairness it took a while for browsers to actually start enforcing that deprecation by ignoring the field. And lots of CAs (including us, so far!) always include CN. So it's no surprise that there are various systems that expect it to be present; hopefully we can find such systems and help get them fixed without too much overall pain.

6 Likes
24

Greatly indebted to those who made this decision - thank you.

Is there a link to any additional technical details I can provide my hosting provider about what the certificates will be like after the removal of the Common Name? Your earlier post mentioned putting nothing in Common Name, but if there's more to it than that, it might help them out. I will also point them to this thread.

Thank you again!

3 Likes
25

A couple of useful references:

https://www.rfc-editor.org/rfc/rfc2818#page-5

https://unmitigatedrisk.com/?p=381

6 Likes
26

hello,
in last days i try to re-organise my certs, regrouping domains and assign certain certs to certain services. Since, i post 'here' right now, you already know what my problem is, ....
Domain ordering not respected.

So, today i uninstall debian's certbot version 1.12.0-2, i install latest github's

certbot --version
certbot 2.5.0

and hoping, according to this https://eff-certbot.readthedocs.io/en/stable/using.html#certbot-command-line-options, and what the -d flag is used for, my problem would be gone.

-d DOMAIN, --domains DOMAIN, --domain DOMAIN
Domain names to include. For multiple domains you can
use multiple -d flags or enter a comma separated list
of domains as a parameter. All domains will be
included as Subject Alternative Names on the
certificate. The first domain will be used as the
certificate name, unless otherwise specified or if you
already have a certificate with the same name...

^ But that isn't the case.

  • So, the not repecting command line domain ordering, is not a certbot problem, but what let'sencrypt has decide it's servers works like.
  • Also, what good about CN.
    Let's say we dont build program's/apps for machines, but for humans, and more for common humans. What is trustable to them when visit their page at example.com ?

So,

  • If company wants to lead it's decision about deprecation of common name, why not omitted complete ? That is a solid, responsible decision !
  • But i think you all know the mess if that happen right now.
  • so, while keep the cn field, respect it as the client ask, also is what certbot falsy claims.

So, in my opinion it's very unfair, also bad, let's encrypt put user's infront, for it's own decision about the cn thing. There could millions of cases that an implementation needs a cn, while is just one that let's encrypt dont.

You have your councils, make the job there, aks for votes, do what you believe in a nice and good way while so many years now. Don't break the net, don't lead less tech people believe that there is no way to try for safety, epecially these times, that many wish net was broken or look like this.

It's good to keep things simple for the machines, but most important to keep things simpler for people too. That's how all started, right ?

27

You may have missed this from Jacob's post:

Regular humans never look at certificate details, hence they would never see that it has a funky cn.

Also again, cns shouldn't have been in use since the year 2000:

2 Likes
28

If so, yes i missed it, but to be honest read a lot of post since 2016, thought it was already aranged. Personaly, i'm glad for this.

I'm not gonna be long, just say 2 more things,

  • like implementations could be millions, so make no sense ask someone why want this,
    the same come with regular users also. while can exist millions cases of users, can also exist million shades of regular users.
  • In my case, no problem just wanted to see, what i declare, cause was easier for me to check things by just a look and not to search ...
  • if in future cn be ommitted, why alter names must be sorted. View and Order is part of developing, and make things easier.
  • While developers have the tools to make their life easier, users may not. While is ok for me to test my cert with certbot certificates and focus my view in cert-name, for the user's side a thing like cert-name not exist. For example see that out put
echo \
  |openssl s_client -showcerts -connect google.com:443 2>/dev/null \
  |openssl x509 -inform pem -noout -text \
  |egrep "Not\ (After|Before)|DNS\:"|tr -s ' '

how easy, is for someone user to locate what search for.

  • Even regular users don't check things, we must try to alter this and give easy ways user check things, cause internet is quiet different like was 20y before and many bad things are based in our don't or won't.
  • Also if the tech deprecated the cn, and of course this make not less security, why not deprecate and the user agent header also? ... just and idea, it's useless by tech side, but usefull for many implementations around.

Ok, already said more than i had to, read posts, also linked gits, so there also people see things both sides. Just wanted to say my opinion and give feedback to let's encrypt service.
Is so important what you offer here ..., so important !

2 Likes
29

This week's release went out and restored the previous behavior: For now, a Certificate Signing Request (CSR) with no Subject CN will result in a certificate that does have a Subject CN, and that Subject CN will be copied from the first Subject Alternative Name (SAN) in the CSR.

Repeating what I mentioned earlier in the thread: we hope to have a proposal soon for migrating entirely away from hostnames in the Subject CN. We'll post more details when we have the proposal ready. Thanks for using Let's Encrypt, and thanks for the feedback on this.

9 Likes
30

I'm here because some of my automated certificate deployments expired and I had service disruption. It was quite confusing, but at least I've found the cause.

The common name was the one arbitrary but consistent bit of information between renewals of certificates that I could use as the basis of naming the configuration objects that use the certificates.

I need an arbitrary and consistent way to identify certificates to match with named configuration objects in the systems I deploy the certs to. The SANs may need to change over time and so a function of the existing SANs is not appropriate.

The cert-name in Certbot isn't available as an argument to deploy_cert. Should I infer it from the cert_path? Should I load up the inspect module and walk back the python stack until I find an object with it?

Neither is explicitly stable but seems to be consistent, but the same was true of the SAN order until it wasn't. At least I have the opportunity to test new versions of certbot before I use them in production.

1 Like
31

@matthubb Please open a new thread for your situation in the #help section. There you're presented with a questionnaire which is mandatory to fill in.

5 Likes
32

Sorry for adding to the noise here with my previous message. I had felt it was possibly worth highlighting that this decision to sort the SANs did have a real user impact and was not straight forward to diagnose.

Now that you've reverted the behaviour on the CA, when someone recreates a certificate with a specific SAN order, they will acquire it as requested. They will still be perplexed as to why some of their certs mysteriously changed their SAN order and CN.

1 Like
34

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.