Custom SAN is not trusted by Chrome

[honzabfu]

Certificate issued with SAN modified by "$Request | Set-CertificateExtension -Extension $SAN" is trusted by Edge and IE, but is not trusted by Chrome.
Error is "NET::ERR_CERT_COMMON_NAME_INVALID".
Same error for version 3.4.1.0 and 3.2.7.0

[Crypt32]

There is a bug in ICertAdmin2 COM interface binary string marshalling when encoded input string contains odd number of characters and I can't fix this, because the issue is at Microsoft's end. I can suggest only workaround: add fake or non-usable alternative name at the end of SAN list. For example, you have two domains: abc.com and adc.cz. Add another alternative name (say abc.x) as last element in the SAN list. There are 50% chances that last name will work, so make last name fake to make all other names valid.

[honzabfu]

Unfortunately it does not work. Neither with common domain nor with localhost.

[Crypt32]

Can you provide sample certificate that doesn’t work?

BTW, does first name in SAN list work?

[honzabfu]

First SAN does not work in Chrome as well.

abc.fi.crt.txt

[Crypt32]

Ok, can you send me certificates from first example, where you had 1 and 2 names (as in initial screenshots)? Also, can you paste code you used to create $SAN variable?

[honzabfu]

Files attached (there is single certificate with CN and two SANs on the 1st screensthot).
BTW thanks for your effort!

SanGen.ps1.txt
abc.com.crt.txt

[honzabfu]

So is there any other workaround we could use in short term? Or there is no chance to modify SANs for now at all? Thx. in advance.

[Crypt32]

Sorry, I was extremely busy last week. I will get back to you soon.

[Crypt32]

I made a quick check and my initial suspect was correct. The idea is that when $SAN.RawData.Length is even number and length is less than 128 bytes, extension is added correctly.

The extension is malformed when length of SAN extension is odd number. In this case, you need to add a fake name with odd length (considering that overal length won't exceed 127 bytes). This will fix the extension. The workaround you tried didn't work, because the name length is even number, thus total SAN extension value is still odd.

That is, if you create SAN extension (any extension is affected), check its length. Say,

if ($san.RawData.Length % 2) {"add odd-length name"} else {"leave it as is, it is ok"}

this will work. I tried to contact Microsoft on this long-time bug, but no progress and unlikely will be fixed.

[honzabfu]

This workaround seems to work, thank you!

[Crypt32]

Although, this one is old, but I eventually found a way to work around ICertAdmin::SetCertificateProperty data marshalling issue. Thus, removing wontfix label and hoping to eventually fix this in native way.

[Crypt32]

Fixed in v4.0.0