@KalleOlaviNiemitalo WouldEnumerateRelativeDistinguishedNames be the best way to extract common name CN instead of string parsing? Just checking since I was going to try and replace all the prefix string parsing in this part of the code 😄.

@iSazonov@KalleOlaviNiemitalo Thanks for your help. I have added support for multi-value RDN incbf4c2a.

Seems to work fine when we useAsnReader. Let me know if you have any concerns here or more edge cases we should support.

@ArmaanMcleod Please look CI errors.

@iSazonov This one is very tricky. Locally tests pass for windows but fail in CI. For LinuxDnsNameList is set tonull.

Perhaps we limit this feature to Windows? I don't remember it being this strange but results seem to vary quite a bit between OS.

Before you added the experimental feature the tests passed, yes?

Before you added the experimental feature the tests passed, yes?

@iSazonov Even before tests which worked locally did not work in CI.

I think this experimental feature is not worth it, too unstable and I can't even test it properly. I had to make tests only work in CI and they would fail locally. I am not sure if there is differences with how these APIs behave across Operating systems. It seems even drastic differences exist between Windows and Linux.

I will move on and close this PR.

📣 Hey@ArmaanMcleod, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗https://aka.ms/PSRepoFeedback

Microsoft Forms

@ArmaanMcleod If the tests work on Windows locally and in CIs I guess openssl works different on Unix. I suggest to create test certificate, put it in assert forlder and run tests with the same certificate on all CIs. If tests pass, we will know root of the issue.

@iSazonov Yep I believe it is because ofopenssl versions on different OS. I have moved the certificates toTestData/Certificates path to see if CI behaves better with certificates without generating them usingopenssl.

Right now on Windows vs Ubuntu 20.04:

Windows

> [ExperimentalFeature]::IsEnabled('PSDnsNameSubjectNameCertificateParser')True>$certPath="./test/powershell/Modules/Microsoft.PowerShell.Security/TestData/Certificates/certificate5.pfx">$cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2((Resolve-Path$certPath))>$cert.DnsNameListPunycode        Unicode---------------longexample.comlongexample.com

Ubuntu 20.04

PS/home/armaan/PowerShell> [ExperimentalFeature]::IsEnabled('PSDnsNameSubjectNameCertificateParser')TruePS/home/armaan/PowerShell>$certPath="./test/powershell/Modules/Microsoft.PowerShell.Security/TestData/Certificates/certificate5.pfx"PS/home/armaan/PowerShell>$cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certPath)PS/home/armaan/PowerShell>$cert.DnsNameListPS/home/armaan/PowerShell>

So there is something really strange going on between the OS's. Can never get Linux to work properly. Although@iSazonov maybe best to kick off CI to see if somehow it works. We can at least drill down if it isopenssl problem or .NET API problem.

Do other certificate values read correctly on Linux? If so, I can only suggest looking in the debugger to rule out that the error is in our code.

CIs fail on Unix-s. Weird! We have two paths. Leave the old code as it is or find the truth.

Do other certificate values read correctly on Linux? If so, I can only suggest looking in the debugger to rule out that the error is in our code.

I will try to see in debugger why this is so strange on Unix. If not and it goes nowhere it might be best to leave code as is and close PR. I'll try my best though as this is very interesting problem 😄.

The other option as well is we enable this experimental feature for Windows. I guess we have to make a call if this is even worth including. I am not convinced anymore with how unpredictable the tests are 😄.

I'll try my best though as this is very interesting problem

You have an option to create simple repro code and report the issue to .Net repo.

I'll try my best though as this is very interesting problem

You have an option to create simple repro code and report the issue to .Net repo.

I would be able to but when trying to debug with WSL I get segmentation fault:

bash: line 1: 37357 Segmentation fault (core dumped) ''/home/armaan/.vscode-server/extensions/ms-dotnettools.csharp-2.69.22-linux-x64/.debugger/vsdbg --interpreter=vscode --connection=/tmp/CoreFxPipe_vsdbg-ui-664483ba64104302836de1684d455c93

Very strange. This is when trying to do anything with X509Certificate2 objects in Xterm.

@iSazonov I will put this one in draft and figure out how to get debugger working with Linux to see what is going on. Probably not worth keeping this PR open until the behaviour is confirmed.

Will let you know how it goes if I get a decent resolution or way forward. Appreciate the reviews and help so far 🙂.

You can try to create simple C# app to read the certificate on Linux. If you get null for the property you can report to .Net repo.

📣 Hey@ArmaanMcleod, how did we do? We would love to hear your feedback with the link below! 🗣️

🔗https://aka.ms/PSRepoFeedback

Microsoft Forms