Freigeben über

Generieren von selbstsignierten Zertifikaten mit .NET CLI

Es gibt verschiedene Möglichkeiten zum Erstellen und Verwenden von selbstsignierten Zertifikaten für Entwicklungs- und Testszenarien. In diesem Artikel wird die Verwendung von selbstsignierten Zertifikaten mit dotnet dev-certs und anderen Optionen wie PowerShell und OpenSSL behandelt.

Anschließend können Sie überprüfen, ob das Zertifikat mit einem Beispiel wie einer ASP.NET Core-App geladen wird, die in einem Container gehostet wird.

Voraussetzungen

Stellen Sie für dotnet dev-certs sicher, dass Sie die richtige Version von .NET installiert haben:

Für dieses Beispiel benötigen Sie den Docker-ClientDocker 17.06 oder höher.

Vorbereiten einer Beispiel-App

Für diesen Leitfaden verwenden Sie eine Beispiel-App und nehmen gegebenenfalls Änderungen vor.

Überprüfen Sie, ob die Dockerfile-Beispiel-App .NET 8 verwendet.

Je nach Hostbetriebssystem müssen Sie möglicherweise die ASP.NET Laufzeit aktualisieren. Wenn Sie z. B. auf die entsprechende Windows-Runtime abzielen möchten, ändern Sie mcr.microsoft.com/dotnet/aspnet:8.0-nanoservercore-2009 AS runtime zu mcr.microsoft.com/dotnet/aspnet:8.0-windowsservercore-ltsc2022 AS runtime in der Dockerfile.

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 die vorhandene Dockerfile-Datei verwenden.

Stellen Sie sicher, dass aspnetapp.csproj das entsprechende Zielframework enthält:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <!--Other Properties-->
  </PropertyGroup>

</Project>

Hinweis

Wenn Sie dotnet publish Parameter verwenden möchten, um die Bereitstellung zu optimieren, stellen Sie sicher, dass die entsprechenden Abhängigkeiten für die Unterstützung von SSL-Zertifikaten enthalten sind. Aktualisieren Sie die Datei dotnet-docker\samples\aspnetapp\aspnetapp.csproj , um sicherzustellen, dass die entsprechenden Assemblys im Container enthalten sind. 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 für lokale Tests.

docker build -t aspnetapp:my-sample -f Dockerfile .

Erstellen eines selbstsignierten Zertifikats

Sie können ein selbstsigniertes Zertifikat erstellen:

Mit dotnet dev-certs

Sie können zum Arbeiten mit selbstsignierten Zertifikaten verwenden dotnet dev-certs .

dotnet dev-certs https -ep $env:USERPROFILE\.aspnet\https\aspnetapp.pfx -p crypticpassword
dotnet dev-certs https --trust

Hinweis

Der Zertifikatname muss in diesem Fall aspnetapp.pfx mit dem Projektassemblynamen übereinstimmen. crypticpassword wird als Platzhalter für ein eigenes Kennwort verwendet. Wenn die Konsole "Ein gültiges HTTPS-Zertifikat ist bereits vorhanden" zurückgibt, ist bereits ein vertrauenswürdiges Zertifikat in Ihrem Speicher vorhanden. Sie kann mithilfe der MMC-Konsole exportiert werden.

Konfigurieren Sie 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 mit dem kennwort übereinstimmen, 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

Nachdem die Anwendung gestartet wurde, navigieren Sie in Ihrem Webbrowser zu https://localhost:8001.

Aufräumen

Wenn die Geheimnisse und Zertifikate nicht verwendet werden, stellen Sie sicher, dass sie 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. Der PKI-Client kann verwendet werden, um ein selbstsigniertes Zertifikat zu generieren.

$cert = New-SelfSignedCertificate -DnsName @("contoso.com", "www.contoso.com") -CertStoreLocation "cert:\LocalMachine\My"

Das Zertifikat wird generiert, sollte jedoch zum Testen in einem Zertifikatspeicher zum Testen in einem Browser platziert werden.

$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)

Zu diesem Zeitpunkt sollten die Zertifikate durch ein MMC-Snap-In angezeigt werden können.

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. In WSL könnten Sie beispielsweise /c/certs durch /mnt/c/certs ersetzen.

Wenn Sie den zuvor für Windows erstellten Container verwenden, würde der Ausführungsbefehl wie folgt aussehen:

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

Nachdem die Anwendung eingerichtet ist, navigieren Sie zu contoso.com:8001 in einem Browser.

Stellen Sie sicher, dass die Hosteinträge so aktualisiert werden, dass contoso.com auf die entsprechende IP-Adresse antworten kann (z. B. 127.0.0.1). Wenn das Zertifikat nicht erkannt wird, stellen Sie sicher, dass das Zertifikat, das mit dem Container geladen wird, auch auf dem Host als vertrauenswürdig gilt und dass es entsprechende SAN-/DNS-Einträge für contoso.com gibt.

Aufräumen

$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 eine 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

Verwenden Sie zum Abrufen einer .pfx-Datei 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 verwenden.

Je nach Hostbetriebssystem muss das Zertifikat vertrauenswürdig sein. Auf einem Linux-Host unterscheidet sich das "Vertrauen" in das Zertifikat und ist distributionsabhängig.

Im Folgenden finden Sie ein Beispiel in Windows mit PowerShell:

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 sich der Pfad für die Einbindung des Volumens je nach Konfiguration ändern.

Führen Sie den folgenden Befehl in PowerShell 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

Nachdem die Anwendung eingerichtet ist, navigieren Sie zu contoso.com:8001 in einem Browser.

Stellen Sie sicher, dass die Hosteinträge so aktualisiert werden, dass contoso.com auf die entsprechende IP-Adresse antworten kann (z. B. 127.0.0.1). Wenn das Zertifikat nicht erkannt wird, stellen Sie sicher, dass das Zertifikat, das mit dem Container geladen wird, auch auf dem Host als vertrauenswürdig gilt und dass es entsprechende SAN-/DNS-Einträge für contoso.com gibt.

Aufräumen

Achten Sie darauf, die selbstsignierten Zertifikate nach Abschluss des Tests zu bereinigen.

Get-ChildItem $certKeyPath | Remove-Item

Siehe auch