Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.

Conversation

@vcsjones
Copy link
Member

@vcsjones vcsjones commented Feb 25, 2020

This is a cherry-pick of dotnet/runtime@b12c901 to port the fix from dotnet/runtime#32558 in to the 3.1 release branch.

/cc @bartonjs @danmosemsft

Description

X500DistinguishedName values that do not follow the specified sort order decode as the empty string on .NET Core 3.0+ on Linux, but work on Windows. This change makes the Linux build match the Windows behavior.

The fix is to simply skip a specific data conformance validation check, which only has a visible impact on non-conforming values now being accepted.

Customer Impact

Reported by Pivotal. Customers that encounter X.509 certificates with a subject name, or issuer name, that contains a segment that is not canonically encoded will see that subject name (or issuer name) as the empty string on .NET Core 3.1 on Linux.

This problem only applies to X500DistinguishedName values that use a "multi-RDN" value, which is not very common (the CA/Browser forum Baseline Recommendations do not explicitly say to not use this encoding, but their description of distinguished name values uses "single-value" terminology).

Regression

Yes, from 2.1. The underlying data reader was replaced during 3.0, with the new reader validating by default and the old reader not validating.

Testing

Added a unit test to verify that non-conforming data decodes the same on all platforms.

Risk

Low. The change merely bypasses a conformance check, explicitly choosing to accept non-conforming data. The unit tests confirms that the same answer is given for Windows and Linux.

@vcsjones
Copy link
Member Author

/azp run corefx-ci

@azure-pipelines
Copy link

Commenter does not have sufficient privileges for PR 42873 in repo dotnet/corefx

@vcsjones
Copy link
Member Author

vcsjones commented Feb 25, 2020

Le sigh.

macOS failure appears unrelated:

Process terminated. Assertion failed.
X509ChainGetStatusAtIndex returned unexpected error 2

Musl failure looks like a timeout downloading a package.

@danmoseley
Copy link
Member

Please label servicing-consider when ready

@bartonjs bartonjs added the Servicing-consider Issue for next servicing release review label Feb 27, 2020
@leecow leecow added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Mar 3, 2020
@leecow leecow added this to the 3.1.4 milestone Mar 3, 2020
@Anipik Anipik merged commit 806f5e5 into dotnet:release/3.1 Mar 25, 2020
@vcsjones vcsjones deleted the 32558-for-3.1 branch March 25, 2020 21:56
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

area-System.Security Servicing-approved Approved for servicing release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants