Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

UpdateDnsNameList forX509Certificate2 to useX509SubjectAlternativeNameExtension.EnumerateDnsNames Method#24714

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation

ArmaanMcleod
Copy link
Contributor

@ArmaanMcleodArmaanMcleod commentedDec 28, 2024
edited
Loading

PR Summary

UpdatedDnsNameList forX509Certificate2 to useX509SubjectAlternativeNameExtension.EnumerateDnsNames method. This replaces theDNS Name= prefix + OID 2.5.29.17 checking code which is error prone when using different language clients.

Using thepublic X509SubjectAlternativeNameExtension (byte[] rawData, bool critical = false) constructor withcert.RawData did not work and resulted inCryptographicException exceptions. Instead, what was much more robust was just casting the extension toX509SubjectAlternativeNameExtension and then using theEnumerateDnsNames() method.

Also testing previous code with different culture/locale I could not get DNS name prefix to output in a different language, so that case is a bit difficult to reproduce. Although it seems like this is supposed to just work moving to the .NETEnumerateDnsNames() method. I am not even sure switching cultures is good enough to expose this problem and how it can even be validated in the tests.

PR Context

Fixes#24594

PR Checklist

mklement0 and Mobility-Inc-Marq reacted with thumbs up emoji
@ArmaanMcleodArmaanMcleod marked this pull request as ready for reviewDecember 28, 2024 07:31
@iSazonoviSazonov added the CL-GeneralIndicates that a PR should be marked as a general cmdlet change in the Change Log labelDec 28, 2024
@ArmaanMcleod
Copy link
ContributorAuthor

ArmaanMcleod commentedDec 28, 2024
edited
Loading

@MaurizioFocareta Did you want to test these changes using a non-english locale to see if using .NET runtime approach fixes your problem?

I'll keep looking to see if we can get the tests to verify it but for now we can probably do a manual test off this branch to see if it works for you 🙂.

Mobility-Inc-Marq reacted with rocket emoji

Comment on lines +3351 to +3352
string parsedSubjectDistinguishedDnsName = cert.Subject.Substring(distinguishedNamePrefix.Length);
DnsNameRepresentation dnsName = GetDnsNameRepresentation(parsedSubjectDistinguishedDnsName);
Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Copy link
ContributorAuthor

@ArmaanMcleodArmaanMcleodDec 29, 2024
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Actually will park this, just realised this will include all distinguished names outside ofCN=. dotnet runtime probably needs to expose something for just common name without too much extra work. Right now you'd need to still check the OID during enumeration which is not ideal and probably leads to more complex code in its current state.

dotnet/runtime#33914

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I think it would end up being something like:

privateconststringCommonNameOid="2.5.4.3";// Extract DNS name from Subject distinguished nameforeach(X500RelativeDistinguishedNamedistinguishedNameincert.SubjectName.EnumerateRelativeDistinguishedNames()){if(!distinguishedName.HasMultipleElements&&distinguishedName.GetSingleElementType().Value.Equals(CommonNameOid,StringComparison.OrdinalIgnoreCase)){DnsNameRepresentationdnsName=GetDnsNameRepresentation(distinguishedName.GetSingleElementValue());_dnsList.Add(dnsName);}}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

The change is not related the PR. Please revert.
If you think original code has an issue, please open new issue to discuss.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Yeah so this was just referring to how distinguished names are handled. I have reverted that change and will open a new issue to discuss. This is resolved for this PR.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I don't see new commit.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I force pushed and removed the changes.

@ArmaanMcleodArmaanMcleodforce-pushed thex509Certificate2-enumerate-dns-names-fix branch from442149a to18a73cdCompareDecember 29, 2024 01:38
@iSazonoviSazonov merged commit10d1785 intoPowerShell:masterDec 29, 2024
38 checks passed
@ArmaanMcleodArmaanMcleod deleted the x509Certificate2-enumerate-dns-names-fix branchDecember 29, 2024 10:25
@KalleOlaviNiemitalo

Using the public X509SubjectAlternativeNameExtension (byte[] rawData, bool critical = false) constructor with cert.RawData did not work and resulted in CryptographicException exceptions.

That makes sense; X509Certificate2.RawData is the entire certificate including all extensions, but the byte[] rawData parameter of the X509SubjectAlternativeNameExtension constructor must be only the single extension.

Also testing previous code with different culture/locale I could not get DNS name prefix to output in a different language, so that case is a bit difficult to reproduce.

Because the prefix was added by unmanaged code in Windows, I expect it respectsSetThreadPreferredUILanguages rather thanCultureInfo.CurrentUICulture. The corresponding language pack for Windows might also have to be installed.

ArmaanMcleod reacted with thumbs up emoji

@ArmaanMcleod
Copy link
ContributorAuthor

Using the public X509SubjectAlternativeNameExtension (byte[] rawData, bool critical = false) constructor with cert.RawData did not work and resulted in CryptographicException exceptions.

That makes sense; X509Certificate2.RawData is the entire certificate including all extensions, but the byte[] rawData parameter of the X509SubjectAlternativeNameExtension constructor must be only the single extension.

Also testing previous code with different culture/locale I could not get DNS name prefix to output in a different language, so that case is a bit difficult to reproduce.

Because the prefix was added by unmanaged code in Windows, I expect it respectsSetThreadPreferredUILanguages rather thanCultureInfo.CurrentUICulture. The corresponding language pack for Windows might also have to be installed.

Thanks@KalleOlaviNiemitalo. That makes a lot of sense.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@iSazonoviSazonoviSazonov approved these changes

Assignees
No one assigned
Labels
CL-GeneralIndicates that a PR should be marked as a general cmdlet change in the Change Log
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

X509Certificate2 DNSNameList is not language independent, don't work on non-english clients
3 participants
@ArmaanMcleod@KalleOlaviNiemitalo@iSazonov

[8]ページ先頭

©2009-2025 Movatter.jp