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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

X509CertificateClaimSet should validate based on SAN instead of the Subject Name #321

Closed
iamjasonp opened this Issue Sep 8, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@iamjasonp
Copy link
Member

iamjasonp commented Sep 8, 2015

For versions of .NET Framework > 4.6 on Desktop, we will no longer be checking certificate Subject Names for CN=host anymore; rather, we will test based on Subject Alternative Name.

Currently, we are adopting the old behaviour checking against the Subject Name (CN=host) as our test certs are not generated with SANs present (see #320).

In the wild, most certs issued should already contain SANs for the names that the server can be. We should therefore make a change in WCF for .NET Core to check certificates for SANs once #320 is resolved.

@zhenlan

This comment has been minimized.

Copy link
Member

zhenlan commented Sep 8, 2015

@iamjasonp if we need to do this on .NET Framework 4.6.x as well, please open a work item there too.

@iamjasonp

This comment has been minimized.

Copy link
Member Author

iamjasonp commented Oct 7, 2015

No work needed in Desktop .NET Framework - it already acts as described above. The question is whether WCF for .NET Core wants to follow Desktop 4.6+ behaviour or <= 4.5 behaviour

Removing "not yet supported" label as this is (and has been) supportable in code, just that we lacked a way to test this functionality.

@iamjasonp

This comment has been minimized.

Copy link
Member Author

iamjasonp commented Oct 13, 2015

Depending on the behaviour we want here, we need to make appropriate changes on the Bridge or BridgeClient sides.

We need to change the certificates that are generated depending on this design.

I think we should follow .NET 4.6 and up behaviour. To be clear, code currently checked into 4.6 is quirked to behave differently between <=4.5.x and >=4.6.

@zhenlan zhenlan added the bug label Oct 14, 2015

@zhenlan zhenlan added this to the 2015.10 milestone Oct 14, 2015

iamjasonp added a commit to iamjasonp/wcf that referenced this issue Oct 14, 2015

Validate X509CertificateClaims by SAN instead of by CN
X509CertificateClaimSet should validate based on Subject Alternative Name
instead of the Canonical Name to be consistent with Desktop .NET >= 4.6

Today, We are checking against the Subject (e.g. CN=host) on the certificate,
to determine whether or not the cert was issued for a particular server, as this
was the behaviour in <= 4.5. However, this is inflexible as the host could be
serving the same cert but bound to multiple endpoints.

In the old case, for example, foo-bar.test.com != foo-bar, and a generated cert
can only be valid for exactly one of these. In the new case, a certificate can
have a Subject with a particular CN, but multiple Subject Alt Names for which the
cert is also valid.

In the wild, most certs issued already contain SANs for the names that the
server can be, so we should be consistent with current behaviour and ditch the
legacy way of checking certs against servers.

Fixes dotnet#321

@zhenlan zhenlan modified the milestones: 2015.11, 2015.10 Nov 3, 2015

iamjasonp added a commit to iamjasonp/wcf that referenced this issue Dec 2, 2015

Validate X509CertificateClaims by SAN instead of by CN
X509CertificateClaimSet should validate based on Subject Alternative Name
instead of the Canonical Name to be consistent with Desktop .NET >= 4.6

Today, We are checking against the Subject (e.g. CN=host) on the certificate,
to determine whether or not the cert was issued for a particular server, as this
was the behaviour in <= 4.5. However, this is inflexible as the host could be
serving the same cert but bound to multiple endpoints.

In the old case, for example, foo-bar.test.com != foo-bar, and a generated cert
can only be valid for exactly one of these. In the new case, a certificate can
have a Subject with a particular CN, but multiple Subject Alt Names for which the
cert is also valid.

In the wild, most certs issued already contain SANs for the names that the
server can be, so we should be consistent with current behaviour and ditch the
legacy way of checking certs against servers.

Fixes dotnet#321
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment