Generieren von selbstsignierten Zertifikaten mit der .NET-CLI
Es gibt verschiedene Möglichkeiten, selbstsignierte Zertifikate für Entwicklungs- und Testszenarien zu erstellen und zu verwenden. Dieser Artikel behandelt die Verwendung von selbstsignierten Zertifikaten mit dotnet dev-certs
und anderen Optionen wie PowerShell
und OpenSSL
.
Sie können dann mithilfe eines Beispiels überprüfen, ob das Zertifikat geladen wird, z. B. mit einer ASP.NET Core-App, die in einem Container gehostet wird.
Voraussetzungen
Stellen Sie für dotnet dev-certs
sicher, dass Sie die richtige Version von .NET installiert haben:
- Installieren von .NET unter Windows
- Installieren von .NET unter Linux
- Installieren von .NET unter macOS
Für dieses Beispiel benötigen Sie den Docker-ClientDocker 17.06 oder höher.
Vorbereiten der Beispiel-App
Verwenden Sie für diese Anleitung eine Beispiel-App, und nehmen Sie wenn nötig Anpassungen vor.
Überprüfen Sie, ob das Dockerfile für die Beispiel-App .NET 8 verwendet.
Je nach Hostbetriebssystem müssen Sie die ASP.NET-Runtime gegebenenfalls aktualisieren. Wenn Sie beispielsweise auf die entsprechende Windows-Runtime abzielen möchten, ändern Sie mcr.microsoft.com/dotnet/aspnet:8.0-nanoservercore-2009 AS runtime
in dem Dockerfile in mcr.microsoft.com/dotnet/aspnet:8.0-windowsservercore-ltsc2022 AS runtime
.
Dies hilft beispielsweise beim Testen der Zertifikate unter Windows:
# https://hub.docker.com/_/microsoft-dotnet
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /source
# copy csproj and restore as distinct layers
COPY *.sln .
COPY aspnetapp/*.csproj ./aspnetapp/
RUN dotnet restore -r win-x64
# copy everything else and build app
COPY aspnetapp/. ./aspnetapp/
WORKDIR /source/aspnetapp
RUN dotnet publish -c release -o /app -r win-x64 --self-contained false --no-restore
# final stage/image
FROM mcr.microsoft.com/dotnet/aspnet:8.0-windowsservercore-ltsc2022 AS runtime
WORKDIR /app
COPY --from=build /app ./
ENTRYPOINT ["aspnetapp"]
Wenn Sie die Zertifikate unter Linux testen, können Sie das vorhandene Dockerfile verwenden.
Stellen Sie sicher, dass die Datei aspnetapp.csproj
ein passendes Zielframework enthält:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<!--Other Properties-->
</PropertyGroup>
</Project>
Hinweis
Wenn Sie dotnet publish
-Parameter zum Trimmen der Bereitstellung verwenden möchten, sollten Sie sicherstellen, dass die passenden Abhängigkeiten zur Unterstützung von SSL-Zertifikaten hinzugefügt werden.
Aktualisieren Sie die Datei dotnet-docker\samples\aspnetapp\aspnetapp.csproj, um sicherzustellen, dass die richtigen Assemblys zum Container hinzugefügt werden. Informieren Sie sich in diesem Zusammenhang darüber, wie Sie die CSPROJ-Datei so aktualisieren können, dass SSL-Zertifikate unterstützt werden, wenn Sie Trimming für eigenständige Bereitstellungen einsetzen.
Stellen Sie sicher, dass Sie auf die Beispiel-App verweisen.
cd .\dotnet-docker\samples\aspnetapp
Erstellen Sie den Container zum Testen auf lokaler Ebene.
docker build -t aspnetapp:my-sample -f Dockerfile .
Erstellen eines selbstsignierten Zertifikats
Sie können mithilfe der folgenden Tools ein selbstsigniertes Zertifikat erstellen:
Mit dotnet dev-certs
Sie können dotnet dev-certs
verwenden, um mit selbstsignierten Zertifikaten zu arbeiten.
dotnet dev-certs https -ep $env:USERPROFILE\.aspnet\https\aspnetapp.pfx -p crypticpassword
dotnet dev-certs https --trust
Hinweis
Der Zertifikatsname, in diesem Fall aspnettapp.pfx, muss mit dem Projektassemblynamen identisch sein. crypticpassword
wird als Ersatz für ein Kennwort Ihrer Wahl verwendet. Wenn die Konsole die Meldung "A valid HTTPS certificate is already present" (Es gibt bereit ein gültiges HTTPS-Zertifikat) zurückgibt, gibt es bereits ein vertrauenswürdiges Zertifikat in Ihrem Speicher. Dieses können Sie mithilfe der MMC-Konsole exportieren.
Konfigurieren Sie die Anwendungsgeheimnisse für das Zertifikat:
dotnet user-secrets -p aspnetapp\aspnetapp.csproj init
dotnet user-secrets -p aspnetapp\aspnetapp.csproj set "Kestrel:Certificates:Development:Password" "crypticpassword"
Hinweis
Hinweis: Das Kennwort muss dem Kennwort entsprechen, das für das Zertifikat verwendet wird.
Führen Sie das Containerimage mit einer für HTTPS konfigurierten ASP.NET Core-Instanz aus:
docker run --rm -it -p 8000:80 -p 8001:443 -e ASPNETCORE_URLS="https://+;http://+" -e ASPNETCORE_HTTPS_PORT=8001 -e ASPNETCORE_ENVIRONMENT=Development -v $env:APPDATA\microsoft\UserSecrets\:C:\Users\ContainerUser\AppData\Roaming\microsoft\UserSecrets -v $env:USERPROFILE\.aspnet\https:C:\Users\ContainerUser\AppData\Roaming\ASP.NET\Https mcr.microsoft.com/dotnet/samples:aspnetapp
Sobald die Anwendung gestartet wurde, navigieren Sie in Ihrem Webbrowser zu https://localhost:8001
.
Bereinigung
Wenn die Geheimnisse und Zertifikate nicht verwendet werden, sollten sie unbedingt bereinigt werden.
dotnet user-secrets remove "Kestrel:Certificates:Development:Password" -p aspnetapp\aspnetapp.csproj
dotnet dev-certs https --clean
Mit PowerShell
Sie können PowerShell verwenden, um selbstsignierte Zertifikate zu generieren. Dabei hilft Ihnen der PKI-Client.
$cert = New-SelfSignedCertificate -DnsName @("contoso.com", "www.contoso.com") -CertStoreLocation "cert:\LocalMachine\My"
Wenn das Zertifikat generiert wird, sollte es in einem Zertifikatspeicher gespeichert werden, um Tests im Browser durchzuführen.
$certKeyPath = "c:\certs\contoso.com.pfx"
$password = ConvertTo-SecureString 'password' -AsPlainText -Force
$cert | Export-PfxCertificate -FilePath $certKeyPath -Password $password
$rootCert = $(Import-PfxCertificate -FilePath $certKeyPath -CertStoreLocation 'Cert:\LocalMachine\Root' -Password $password)
An dieser Stellen sollten die Zertifikate über ein MMC-Snap-In abrufbar sein.
Sie können den Beispielcontainer im Windows-Subsystem für Linux (WSL) ausführen:
docker run --rm -it -p 8000:80 -p 8001:443 -e ASPNETCORE_URLS="https://+;http://+" -e ASPNETCORE_HTTPS_PORT=8001 -e ASPNETCORE_ENVIRONMENT=Development -e ASPNETCORE_Kestrel__Certificates__Default__Password="password" -e ASPNETCORE_Kestrel__Certificates__Default__Path=/https/contoso.com.pfx -v /c/certs:/https/ mcr.microsoft.com/dotnet/samples:aspnetapp
Hinweis
Mit der Volumebereitstellung kann der Dateipfad je nach Host anders aufgebaut sein. Beispielsweise können Sie in WSL /c/certs durch /mnt/c/certs ersetzen.
Wenn Sie den Container verwenden, der zuvor für Windows erstellt wurde, sieht der Ausführungsbefehl wie folgt aus:
docker run --rm -it -p 8000:80 -p 8001:443 -e ASPNETCORE_URLS="https://+;http://+" -e ASPNETCORE_HTTPS_PORT=8001 -e ASPNETCORE_ENVIRONMENT=Development -e ASPNETCORE_Kestrel__Certificates__Default__Password="password" -e ASPNETCORE_Kestrel__Certificates__Default__Path=c:\https\contoso.com.pfx -v c:\certs:C:\https aspnetapp:my-sample
Navigieren Sie in einem Browser zu „contoso.com:8001“, sobald die Anwendung ausgeführt wird.
Stellen Sie sicher, dass die Hosteinträge aktualisiert werden, damit contoso.com
an einer geeigneten IP-Adresse (z. B. 127.0.0.1) antwortet. Wenn das Zertifikat nicht erkannt wird, sollten Sie sich vergewissern, dass das Zertifikat, das mit dem Container geladen wird, ebenfalls vom Host als vertrauenswürdig eingestuft wird, und dass es passende SAN-/DNS-Einträge für contoso.com
gibt.
Bereinigung
$cert | Remove-Item
Get-ChildItem $certKeyPath | Remove-Item
$rootCert | Remove-item
Mit OpenSSL
Sie können OpenSSL verwenden, um selbstsignierte Zertifikate zu erstellen. In diesem Beispiel werden WSL/Ubuntu und eine Bash-Shell mit OpenSSL
verwendet.
Dieser Befehl generiert eine .crt- und eine .key-Datei.
PARENT="contoso.com"
openssl req \
-x509 \
-newkey rsa:4096 \
-sha256 \
-days 365 \
-nodes \
-keyout $PARENT.key \
-out $PARENT.crt \
-subj "/CN=${PARENT}" \
-extensions v3_ca \
-extensions v3_req \
-config <( \
echo '[req]'; \
echo 'default_bits= 4096'; \
echo 'distinguished_name=req'; \
echo 'x509_extension = v3_ca'; \
echo 'req_extensions = v3_req'; \
echo '[v3_req]'; \
echo 'basicConstraints = CA:FALSE'; \
echo 'keyUsage = nonRepudiation, digitalSignature, keyEncipherment'; \
echo 'subjectAltName = @alt_names'; \
echo '[ alt_names ]'; \
echo "DNS.1 = www.${PARENT}"; \
echo "DNS.2 = ${PARENT}"; \
echo '[ v3_ca ]'; \
echo 'subjectKeyIdentifier=hash'; \
echo 'authorityKeyIdentifier=keyid:always,issuer'; \
echo 'basicConstraints = critical, CA:TRUE, pathlen:0'; \
echo 'keyUsage = critical, cRLSign, keyCertSign'; \
echo 'extendedKeyUsage = serverAuth, clientAuth')
openssl x509 -noout -text -in $PARENT.crt
Wenn Sie eine PFX-Datei erstellen möchten, verwenden Sie den folgenden Befehl:
openssl pkcs12 -export -out $PARENT.pfx -inkey $PARENT.key -in $PARENT.crt
Hinweis
Ab .NET 5 kann Kestrel .crt- und PEM-codierte .key-Dateien zusätzlich zu PFX-Dateien mit einem Kennwort verarbeiten.
Je nach Hostbetriebssystem muss das Zertifikat als vertrauenswürdig eingestuft werden. Auf einem Linux-Host werden Zertifikate auf andere Weise und in Abhängigkeit mit der Distribution als vertrauenswürdig eingestuft.
Für diesen Leitfaden stellen wir das folgende Beispiel für Windows unter Verwendung von PowerShell bereit:
Import-Certificate -FilePath $certKeyPath -CertStoreLocation 'Cert:\LocalMachine\Root'
Führen Sie das Beispiel mit dem folgenden Befehl in WSL aus:
docker run --rm -it -p 8000:80 -p 8001:443 -e ASPNETCORE_URLS="https://+;http://+" -e ASPNETCORE_HTTPS_PORT=8001 -e ASPNETCORE_ENVIRONMENT=Development -e ASPNETCORE_Kestrel__Certificates__Default__Path=/https/contoso.com.crt -e ASPNETCORE_Kestrel__Certificates__Default__KeyPath=/https/contoso.com.key -v /c/path/to/certs:/https/ mcr.microsoft.com/dotnet/samples:aspnetapp
Hinweis
In WSL kann der Pfad der Volumeeinbindung je nach Konfiguration abweichen.
Führen Sie in PowerShell den folgenden Befehl aus:
docker run --rm -it -p 8000:80 -p 8001:443 -e ASPNETCORE_URLS="https://+;http://+" -e ASPNETCORE_HTTPS_PORT=8001 -e ASPNETCORE_ENVIRONMENT=Development -e ASPNETCORE_Kestrel__Certificates__Default__Path=c:\https\contoso.com.crt -e ASPNETCORE_Kestrel__Certificates__Default__KeyPath=c:\https\contoso.com.key -v c:\certs:C:\https aspnetapp:my-sample
Navigieren Sie in einem Browser zu „contoso.com:8001“, sobald die Anwendung ausgeführt wird.
Stellen Sie sicher, dass die Hosteinträge aktualisiert werden, damit contoso.com
an einer geeigneten IP-Adresse (z. B. 127.0.0.1) antwortet. Wenn das Zertifikat nicht erkannt wird, sollten Sie sich vergewissern, dass das Zertifikat, das mit dem Container geladen wird, ebenfalls vom Host als vertrauenswürdig eingestuft wird, und dass es passende SAN-/DNS-Einträge für contoso.com
gibt.
Bereinigung
Stellen Sie sicher, dass Sie die selbstsignierten Zertifikate nach Abschluss der Tests löschen.
Get-ChildItem $certKeyPath | Remove-Item