-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
macOS 11: System.Security.Cryptography.X509Certificates.Tests.CertificateCreation.CertificateRequestUsageTests.AlwaysVersion3 failure #40939
Comments
Do we need any change here in the Sept servicing? That is about to be code complete (well it was last Friday). I'm guessing that the Sept patch may be the latest available whan macOS 11 releases. |
I can look at this soon since I have Big Sur available and was looking in to #39603. |
Many thanks @vcsjones ! It's a busy day for us today with the 6.0 branching. |
I can repro it; which is good. This is new, this wasn't failing in beta 2. Sigh. |
@bartonjs okay, so the issue is that Big Sur rejects X509 certificates that have an For example:
That certificate will fail on Big Sur:
Emphasis mine. I think then, we should change the We can't really do a fix-up when loading certificates to allow the old behavior because we'll invalidate the signature on the cert. Thoughts? |
Actually, it looks like this was considered and the current behavior is intentional: Lines 661 to 663 in 3b824aa
I feel like there is a puzzle piece that I am missing. |
I think the comment is really just saying "we have a slightly weird behavior", the tests seem to be exercising that, just to prove they know what's what: Lines 363 to 382 in 7918347
Probably the ToArray() needs to be guarded by extensionAsns being non-empty: Lines 680 to 681 in 3b824aa
and that comment deleted. |
(It was probably a semi-bug that was kept as an "interesting test condition", and now is a "doesn't work on macOS") The 2012 version of X.509 (the ITU spec) didn't contain the one-or-more clause for certificate extensions (it did for CRL extensions). I don't see that being fixed in any of the addenda/errata, but the 2016 version does state it (in section 7.2):
|
Makes sense. This seemed like it could have been one of those "we're trying to emulate the behavior of Certificate Services from Windows Server 2000" or something. Your compat concerns are starting to rub off on me. |
Mono and CoreCLR both fail near-identically on this test on Helix.
CoreCLR https://helix.dot.net/api/2019-06-17/jobs/4f122c80-6e43-48c3-9793-d5c72dc59bbd/workitems/System.Security.Cryptography.X509Certificates.Tests/console
Mono https://helix.dot.net/api/2019-06-17/jobs/6648e68b-974b-4787-9345-e0223c696d09/workitems/System.Security.Cryptography.X509Certificates.Tests/console
Unknown format in import
- has the export format from macOS changed?The text was updated successfully, but these errors were encountered: