-
Notifications
You must be signed in to change notification settings - Fork 10.2k
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
Add support for loading certificate chains from configuration. #24935
Conversation
src/Servers/Kestrel/Core/src/Internal/Certificates/CertificateConfigLoader.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good aside from the one confusing line
/// <summary> | ||
/// Specifies the intermediate certificates in the chain. | ||
/// </summary> | ||
public X509Certificate2Collection ServerCertificateIntermediates { get; set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The weird thing about this property is that it should really be set with the ServerCertificate
in an atomic manner. If the cert is set, then the intermediates should be set as well (null is valid)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. The combined type should probably be defined in the runtime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add a SslStreamCertificateContext
property instead of this X509Certificate2Collection
?
X509Certificate2Collection coll = new X509Certificate2Collection();
coll.Import(pfxPath, pfxPwd, flags); If there's exactly one cert that returns true for HasPrivateKey, you can hold its reference as the target cert and remove it from the collection (removing it isn't strictly required, I guess...). |
} | ||
|
||
var cert = new X509Certificate2(); | ||
var cert = TestResources.GetTestCertificate(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This gets called a lot. Maybe we should store this certificate in a static/fixture. We do that in some other test classes that need a lot of valid X509Certificate2s.
@@ -346,6 +346,8 @@ internal class SniConfig | |||
|
|||
// "CertificateName": { | |||
// "Path": "testCert.pfx", | |||
// "KeyPath": "", | |||
// "ChainPath": "", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Use fake .pem
files to show the expected file type for KeyPath/ChainPath.
// This might be do blocking IO but it'll resolve the certificate chain up front before any connections are | ||
// made to the server | ||
sslOptions.ServerCertificate = serverCert; | ||
sslOptions.ServerCertificateContext = SslStreamCertificateContext.Create(serverCert, intermediates); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be more straightforward to just have developers call this themselves by putting a SslStreamCertificateContext on HttpsConnectionAdapterOptions and preferring it to ServerCertificate similar to the way we treat ServerCertificateSelector.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wherever we load the cert, we're going to be using the context. The callback happens to late. It needs to happen at startup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
HttpsConnectionAdapterOptions.ServerCertificateContext or whatever-we-call-it would be set at startup though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does that have to do with the SNI selector? Kestrel should always resolve this at startup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just a comparison to point out that even though having both SslStreamCertificateContext and ServerCertificate on HttpsConnectionAdapterOptions would be redundant, ServerCertificateSelector and ServerCertificate are already redundant, so this isn't a new problem if we decide to add SslStreamCertificateContext.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what this has to do with SNI. Exposing SslStreamCertificateContext
on HttpsConnectionAdapterOptions
is fine and I have no pushback but it has nothing to do with this code path...
src/Servers/Kestrel/Core/src/Internal/Certificates/ICertificateConfigLoader.cs
Show resolved
Hide resolved
Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:
|
3e874e6
to
cec7d75
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good!
There's missing tests and stuff, but other than that the changes are fine I think!
cec7d75
to
e00b3e3
Compare
👀 |
e00b3e3
to
f098e95
Compare
@davidfowl this PR is blocking me deleting the old release/5.0-rc2 branch. Could you please close it❔ |
As long as you don't delete it |
If you need the branch, probably safest to rebase it before I burn the release/5.0-rc2 branch. I don't think GitHub removes branches when left dangling after a PR is closed but the PR does protect the branch a bit. |
🆗 @davidfowl I'll do the |
Yep |
- Adds a ServerCertificateIntermediates property to HttpsConnectionAdapterOptions - Adds a Chain property to configuration. This only supports PEM certificates. - Import intermediates if chain path specified
567dee9
to
124b365
Compare
Done |
TODO: Add tests
Fixes #21513
Contributes to #21512