SAN Ordering Issue w/Outlook 2010

[i3laze]

I’m having an issue with ordering of SAN-records:
Seems, fully patched Windows XP would prefer CN to be the first in SAN’s order.

Currently, Let’s Encrypt Boulder server alphabetize all SAN records. Actually, that makes the list more viewable)
Could any flag to be introduced to place CN in the first place?

My setup is Windows XP / Outlook 2010 / Exchange 2013.
More about this issue:
https://social.technet.microsoft.com/Forums/exchange/en-US/9f448d07-df55-48e7-939b-cdf18e70594b/outlook-anywhere-on-windows-xp-clients-running-outlook-2010-continually-getting-password-prompt?forum=exchange2010

Issue: Allow CN as First SAN entry for Windows XP compatibility

[_az]

Have you considered breaking that domain out onto its own independent certificate (so SAN.length == 1 && CN == SAN[0])?

[rg305]

You might want to test with --cert-name parameter.
It might force that name to be the one listed in the CN (and placed first in the SAN).

[schoen]

@rg305

You might want to test with --cert-name parameter.
It might force that name to be the one listed in the CN (and placed first in the SAN).

The --cert-name can be arbitrary and independent of the domain names (for example, you could use --cert-name garfield or --cert-name snoopy), so it will not affect the resulting certificate's contents.

[rg305]

Even if the name matches?

If not, then, is there any way to pick which name goes first in the SAN and which gets placed in the CN?

[mnordhoff]

@rg305

If not, then, is there any way to pick which name goes first in the SAN and which gets placed in the CN?

The first "-d" argument is used for the CN.

Let's Encrypt doesn't currently allow the SAN ordering to be controlled: No matter what order the client uses in the CSR, Boulder sorts it.

[schoen]

@rg305

Even if the name matches?

Yes. If the cert name is specified by the user, then it's used; otherwise, it's chosen from the first non-wildcard name in the list.

https://github.com/certbot/certbot/blob/master/certbot/client.py#L400

[rg305]

This may cause a problem.
I don’t recall where, but I remem hearing a complaint about the CN not matching the first name in the SAN…
Could have been with Exchange or Lync.

[schoen]

@rg305

I don’t recall where, but I remem hearing a complaint about the CN not matching the first name in the SAN…
Could have been with Exchange or Lync.

This may be possible, but I think users who want to support clients that have this behavior will need to issue individual certificates per subject name, or use a different CA. According to Internet standards, TLS clients have been told to completely ignore the CN contents if any SAN is present since 2000.

RFC 2818: HTTP Over TLS

(Do you know how the affected clients behave if there is no CN field present? Does that improve compatibility in this case?)

[i3laze]

As I mentioned, Boulder issues certificate with SAN list in alphabetical order.

This behavior only affects Windows XP in Outlook Anywhere mode. That comes from Lync/Exchange ass-painful world.
I’ll try internal CA with correct order to verify it actually would fix such legacy issue.

[rg305]

Time to sell it on "Let Go!"

“But I’ve had this XP since Y2K!”
Dude, it’s XP… just “Let Go!”

-LOL

[schoen]

We might in the future be able to issue a certificate with no CN field at all if that would help.

[Patches]

Is there any reason you cannot use the workaround described in the TechNet thread?

You can apparently set the name the certificate should match to in PowerShell on the server-side:

Set-OutlookProvider EXPR -CertPrincipalName "msstd:your-first-san.example.com"

EDIT: the post in the thread you linked to did have a couple typos

[_az]

Ah yes, sounds like a good way to bring all the homebrew not-to-spec x.509 verifying functions out of the woodwork LOL

[rg305]

You have to crack some eggs to make an omelet…

[i3laze]

As CN is placed anyway into SAN list, why wouldn’t it be in the first place (then alternates in alphabetical)?
As alphabetical method ease visualization, new approach may be easier to view.
BTW, why actually CN is duplicated into SAN list?

I’m not looking for a specific solution - just raising a discussion.

[mnordhoff]

@i3laze

BTW, why actually CN is duplicated into SAN list?

On one level, CAs duplicate it because they are flatly required to by regulation.

On another level, it's one step in the interminably slow effort to phase out the Common Name field entirely. Modern clients can completely ignore the CN and only scan the SAN list when validating a certificate. If the CN wasn't duplicated, they would have to check both.

(Unfortunately, outside of the regulated web PKI, private corporate CAs and so forth don't necessarily adhere to the Baseline Requirements, so it has been difficult for implementations to actually remove CN support.)