Support DCP dev cert TLS files#17449
Conversation
Extend the opt-in DCP developer certificate path to macOS and Linux by exporting certificate and key files for DCP TLS while preserving the existing Windows thumbprint behavior. Add startup profiling telemetry and tests for the active code path. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17449Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17449" |
|
Re-running the failed jobs in the CI workflow for this pull request because 1 job was identified as retry-safe transient failures in the CI run attempt.
|
Make the existing DCP developer certificate setting default to enabled while preserving the environment variable as an opt-out. Update tests to cover the default-on path and explicit opt-out. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
|
||
| if (!string.IsNullOrWhiteSpace(_dcpTlsCertFile) && !string.IsNullOrWhiteSpace(_dcpTlsKeyFile)) | ||
| { | ||
| arguments += $" --tls-cert-file \"{_dcpTlsCertFile}\" --tls-key-file \"{_dcpTlsKeyFile}\""; |
There was a problem hiding this comment.
Not for this PR but we should update this to use arguments list in the future. I added that to process spec.
Set FileOptions.Asynchronous when writing DCP TLS certificate and key files so async writes use the intended FileStream mode. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| return dcpProcessSpec; | ||
| } | ||
|
|
||
| private static async Task WriteFileWithUserOnlyPermissionsAsync(string path, ReadOnlyMemory<byte> contents, CancellationToken cancellationToken) |
There was a problem hiding this comment.
Is there a single place we write the dev cert so that its accessible by multiple consumers?
There was a problem hiding this comment.
There is, and I'm folding this into it (DeveloperCertificateService).
|
Re-running the failed jobs in the CI workflow for this pull request because 1 job was identified as retry-safe transient failures in the CI run attempt.
|
Have DCP use DeveloperCertificateService-owned cached certificate and key files instead of writing its own TLS file copies. Keep async FileStream options in the cache writer. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Re-running the failed jobs in the CI workflow for this pull request because 1 job was identified as retry-safe transient failures in the CI run attempt.
|
Extract EnsureCachedKeyMaterial as the single owner of the dev-cert cache lookup/write cycle, shared between GetKeyMaterialAsync and the new GetCachedCertificateFilePathsAsync. WriteCacheFiles now also writes the public .crt PEM, so DCP can consume the cached cert/key file paths on macOS/Linux without a separate writer. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
❓ CLI E2E Tests unknown — 96 passed, 0 failed, 5 unknown (commit View all recordings
📹 Recordings uploaded automatically from CI run #26377094449 |
PR Testing ReportPR Information
CLI Version Verification
Changes AnalyzedFiles Changed
Change Categories
The PR changes DCP TLS preparation so the ASP.NET Core developer certificate is enabled by default. On non-Windows it caches developer certificate Test Scenarios ExecutedScenario 1: Non-interactive starter template creationObjective: Verify Steps:
Evidence:
Observations:
Scenario 2: Starter app build/start smokeObjective: Start a fresh generated Steps:
Evidence:
Error: Analysis:
Scenario 3: Empty AppHost default DCP TLS behaviorObjective: Verify the PR DCP binary starts on macOS with developer-certificate TLS files when developer certificate support is left at its default. Steps:
Evidence:
Observations:
Scenario 4: Explicit DCP developer certificate opt-outObjective: Verify the opt-out path remains safe when Steps:
Expected Unhappy-Path Outcome: AppHost starts successfully and DCP does not receive developer certificate TLS arguments. Evidence:
Observations:
Summary
Overall Result✅ TARGETED PR BEHAVIOR VERIFIED The DCP TLS file behavior introduced by this PR was verified on macOS with an empty AppHost, including the explicit opt-out path. The generated Recommendations
|
There was a problem hiding this comment.
Pull request overview
This PR updates Aspire’s DCP hosting integration to use the existing ASP.NET Core developer certificate by default for DCP TLS, including cross-platform support by supplying certificate/key file paths on macOS/Linux (while keeping Windows’ thumbprint flow). It also adds dedicated startup profiling telemetry around TLS certificate preparation and updates tests to validate the new behavior.
Changes:
- Default DCP TLS to use the ASP.NET Core developer certificate (opt-out via
ASPIRE_DCP_USE_DEVELOPER_CERTIFICATE=false). - On macOS/Linux, prepare and pass
--tls-cert-file/--tls-key-file(plus thumbprint) using cached developer cert material. - Add profiling activity/tags for DCP TLS certificate preparation and update unit tests accordingly.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
src/Aspire.Hosting/Dcp/DcpHost.cs |
Prepares DCP TLS arguments using dev cert by default; adds file-based TLS args for non-Windows and emits new profiling activity/tags. |
src/Aspire.Hosting/DeveloperCertificateService.cs |
Extends dev-cert caching to include a public cert .crt and adds an API to retrieve cached cert/key file paths for DCP. |
src/Aspire.Hosting/Diagnostics/ProfilingTelemetry.cs |
Introduces a dedicated profiling activity plus tags/values for DCP TLS certificate preparation. |
tests/Aspire.Hosting.Tests/Dcp/DcpHostNotificationTests.cs |
Updates process-spec tests to validate default dev-cert TLS behavior across Windows vs macOS/Linux and asserts new profiling tags. |
|
Pull request created: #1069
|
|
📝 Documentation has been drafted in microsoft/aspire.dev#1069 targeting Documentation updates for
Triggered signals: Note This draft PR needs human review before merging. |
Description
DCP recently added support for TLS certificate files, which lets Aspire use the existing ASP.NET Core developer certificate beyond the current Windows-only thumbprint path. This change makes that developer-certificate path the default for DCP TLS, while preserving
ASPIRE_DCP_USE_DEVELOPER_CERTIFICATE=falseas an opt-out for users who need DCP's default ephemeral certificate behavior.By default, Aspire now keeps the Windows behavior of passing
--tls-cert-thumbprint. On macOS and Linux, Aspire asks the existing developer certificate service for cached certificate and key file paths, then starts DCP with--tls-cert-file,--tls-key-file, and--tls-cert-thumbprintso DCP can verify the loaded certificate.Startup profiling also records a dedicated
aspire.hosting.dcp.prepare_tls_certificateactivity when this code path is active. The span tags capture whether the developer certificate path was enabled, the preparation result, whether a certificate was prepared, and the certificate mode (thumbprintorfiles) so we can measure the performance impact of this path.User-facing usage
This behavior is enabled by default. Users can opt out with the existing environment variable:
Security considerations
This change uses the existing developer certificate cache for exported certificate and private key material on macOS and Linux. The cache is under the user's profile and the cached files are written with user-only Unix permissions. Security review should confirm the file location and permissions are appropriate for the default developer certificate scenario and explicit opt-out behavior.
Validation:
Fixes # (issue)
Checklist
<remarks />and<code />elements on your triple slash comments?