Retain order of domains

[zenhack]

Issue by zx2c4
Sunday Feb 28, 2016 at 02:19 GMT
Originally opened as kuba/simp_le#80

---

This ensures that the first domain specified on the command line will be the domain that winds up in the CN field. Otherwise, users have no way of controlling this.

This also supports Python 2.6, which is an improvement over the prior pull request. It also correctly tames pylint for an extremely widespread conditional import pattern.

It should pass all tests on Travis.

Fixes: kuba/simp_le#72
Signed-off-by: Jason A. Donenfeld Jason@zx2c4.com

---

zx2c4 included the following code: https://github.com/kuba/simp_le/pull/80/commits

[zenhack]

Comment by kuba
Sunday Feb 28, 2016 at 15:59 GMT

---

This is missing any kind of tests.

[zenhack]

Comment by zx2c4
Sunday Feb 28, 2016 at 16:57 GMT

---

Okay, now it locally disables for the linter. Good thinking.

I just took a look at how you're implementing the test suite. I can struggle and grunt to add the tests to the test suite here, and in the end I'm sure it won't fit your criteria for inclusion. Would you rather we do some iterations of me struggling, or could you just add this in five minutes yourself?

[zenhack]

Comment by kuba
Sunday Feb 28, 2016 at 17:21 GMT

---

I could try to write tests, but not in foreseeable future - unfortunately I'm extremely busy atm. If you're fine with waiting a couple of weeks before this get merged, then OK...

[buchdag]

I was unable to reproduce what this and #19 aimed to fix : I did a few tests with multiple (up to four) domains on the CLI in different orders and I couldn't get the CN field to be anything else than the first domain specified.

The SAN DNS names in the certificate don't retain the order from the CLI but I don't think that was the issue here (or an issue at all).

[buchdag]

@cpu > If I understand correctly, boulder currently derive the Subject CN from the SAN if no CN was provided in the Certificate Signing Request. How does that work exactly ? Does boulder just pick the first domain in the SAN and populate the CN with it ?

[cpu]

If I understand correctly, boulder currently derive the Subject CN from the SAN if no CN was provided in the Certificate Signing Request.

@buchdag That's correct. We currently promote a SAN to the CN if there isn't a CN specified in the CSR.

How does that work exactly ? Does boulder just pick the first domain in the SAN and populate the CN with it ?

That's correct. Boulder picks the first SAN entry and makes it the CN as well. Presently that's controlled by a flag that is always set to true in staging/production. In the future after a baseline requirements update we'll likely support issuing certificates without a CN and only SANs and this flag will change.

Hope that helps!

[buchdag]

That helps a ton. The ongoing work at boulder / certbot / LE is really invaluable. As is your info on boulder/le inner working.

If I'm still correct, as per RCF5280, having a (the) FQDN as Subject CN has been deprecated for ... well a while, and Boulder is going to deprecate it too in the near future, right ?

[cpu]

If I'm still correct, as per RCF5280, having a (the) FQDN as Subject CN has been deprecated for ... well a while, and Boulder is going to deprecate it too in the near future, right ?

@buchdag Yup, exactly! That's why there's the flag to control the behaviour. I believe allowing issuance of certs with only SANs and no subject CN is blocked on a baseline requirements ballot. I can't recall offhand what the problem was but remember that we're waiting on a CA/Browser forum update to go ahead.

[buchdag]

Okay, so in my opinion there isn't anything to fix here.

[zenhack]

Works for me, closing.