PSPKI
PSPKI copied to clipboard
PKISolutions
Custom SAN is not trusted by Chrome
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
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.
Unfortunately it does not work. Neither with common domain nor with localhost.
Can you provide sample certificate that doesn’t work?
BTW, does first name in SAN list work?
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?
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
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.
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.
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.