[release/13.0] Use DateTimeOffset.Now for checking certificate validity#12715
Merged
joperezr merged 1 commit intodotnet:release/13.0from Nov 6, 2025
Merged
Conversation
* Use DateTimeOffset.Now for checking certificate validity * Avoid loading all system certificates until we can validate them via DCP * Ensure comment covers usage of DateTimeOffset.Now as well
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 12715Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 12715" |
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR makes two changes to improve certificate handling and Python resource configuration:
- Updates
DeveloperCertificateServiceto useDateTimeOffset.Nowinstead ofDateTime.UtcNowfor consistency with ASP.NET Core's certificate selection logic - Modifies Python resource configuration to remove the default
CertificateTrustScope.Systemsetting and downgrades a warning to informational logging
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/Aspire.Hosting/DeveloperCertificateService.cs | Changes time comparison from DateTime.UtcNow to DateTimeOffset.Now and repositions related comments to align with ASP.NET Core's certificate selection behavior |
| src/Aspire.Hosting.Python/PythonAppResourceBuilderExtensions.cs | Removes automatic CertificateTrustScope.System configuration and changes log level from warning to informational for unsupported Append mode |
joperezr
reviewed
Nov 5, 2025
| // Python defaults to using System scope to allow combining custom CAs with system CAs as there's no clean | ||
| // way to simply append additional certificates to default Python trust stores such as certifi. | ||
| // Configure required environment variables for custom certificate trust when running as an executable. | ||
| // TODO: Make CertificateTrustScope.System the default once we're able to validate that certificates are valid for OpenSSL. Otherwise we potentially add invalid certificates to the bundle which causes OpenSSL to error. |
Member
There was a problem hiding this comment.
Do we have an issue tracking this?
Member
|
Customer reported, important for our polyglot story, fixes a correctness issue. Approved. |
JamesNK
approved these changes
Nov 5, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #12680 to release/13.0
Customer Impact
This fixes a time zone bug checking for dev cert validity and makes Python apps default to only trusting the dev cert for OTEL (instead of trusting the dev cert for all http clients) to avoid a potential issue with the Windows cert store being more permissive with certificates than OpenSSL is.
Testing
Manual testing with users in different time zones generating dev certs as well as a user with a problematic certificate validating that the python certificate set change unblocked them.
Risk
Low. We're matching the behavior of ASP.NET for developer certificate validation and limiting the default certificate set for Python to the dev cert for OTEL only.
Regression?
No