Generowanie certyfikatów z podpisem własnym przy użyciu interfejsu wiersza polecenia platformy .NET
Istnieją różne sposoby tworzenia i używania certyfikatów z podpisem własnym na potrzeby scenariuszy tworzenia i testowania. W tym artykule opisano używanie certyfikatów z podpisem własnym z opcjami dotnet dev-certs
i innymi opcjami, takimi jak PowerShell
i OpenSSL
.
Następnie możesz sprawdzić, czy certyfikat zostanie załadowany przy użyciu przykładu , takiego jak aplikacja ASP.NET Core hostowana w kontenerze.
Wymagania wstępne
W przypadku dotnet dev-certs
programu upewnij się, że zainstalowano odpowiednią wersję platformy .NET:
- Instalowanie platformy .NET w systemie Windows
- Instalowanie platformy .NET w systemie Linux
- Instalowanie platformy .NET w systemie macOS
Ten przykład wymaga platformy Docker 17.06 lub nowszej klienta platformy Docker.
Przygotowywanie przykładowej aplikacji
W tym przewodniku użyjesz przykładowej aplikacji i w razie potrzeby wprowadzisz zmiany.
Sprawdź, czy przykładowa aplikacja Dockerfile korzysta z platformy .NET 8.
W zależności od systemu operacyjnego hosta może być konieczne zaktualizowanie środowiska uruchomieniowego ASP.NET. Aby na przykład kierować do odpowiedniego środowiska uruchomieniowego systemu Windows, zmień wartość mcr.microsoft.com/dotnet/aspnet:8.0-nanoservercore-2009 AS runtime
na mcr.microsoft.com/dotnet/aspnet:8.0-windowsservercore-ltsc2022 AS runtime
w pliku Dockerfile.
Na przykład pomoże to przetestować certyfikaty w systemie 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"]
Jeśli testujesz certyfikaty w systemie Linux, możesz użyć istniejącego pliku Dockerfile.
Upewnij się, że element aspnetapp.csproj
zawiera odpowiednią strukturę docelową:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<!--Other Properties-->
</PropertyGroup>
</Project>
Uwaga
Jeśli chcesz użyć dotnet publish
parametrów do przycinania wdrożenia, upewnij się, że odpowiednie zależności są dołączone do obsługi certyfikatów SSL.
Zaktualizuj plik dotnet-docker\samples\aspnetapp\aspnetapp.csproj, aby upewnić się, że odpowiednie zestawy znajdują się w kontenerze. Aby zapoznać się z dokumentacją, sprawdź, jak zaktualizować plik csproj w celu obsługi certyfikatów SSL podczas używania przycinania dla wdrożeń samodzielnie zawartych.
Upewnij się, że wskazujesz przykładową aplikację.
cd .\dotnet-docker\samples\aspnetapp
Skompiluj kontener do testowania lokalnego.
docker build -t aspnetapp:my-sample -f Dockerfile .
Tworzenie certyfikatu z podpisem własnym
Możesz utworzyć certyfikat z podpisem własnym:
Z dotnet dev-certs
Możesz użyć dotnet dev-certs
polecenia , aby pracować z certyfikatami z podpisem własnym.
dotnet dev-certs https -ep $env:USERPROFILE\.aspnet\https\aspnetapp.pfx -p crypticpassword
dotnet dev-certs https --trust
Uwaga
Nazwa certyfikatu, w tym przypadku aspnetapp.pfx musi być zgodna z nazwą zestawu projektu. crypticpassword
jest używany jako stand-in dla hasła własnego wyboru. Jeśli konsola zwróci komunikat "Prawidłowy certyfikat HTTPS jest już obecny"., zaufany certyfikat już istnieje w twoim magazynie. Można go wyeksportować przy użyciu konsoli MMC.
Skonfiguruj wpisy tajne aplikacji dla certyfikatu:
dotnet user-secrets -p aspnetapp\aspnetapp.csproj init
dotnet user-secrets -p aspnetapp\aspnetapp.csproj set "Kestrel:Certificates:Development:Password" "crypticpassword"
Uwaga
Uwaga: hasło musi być zgodne z hasłem używanym dla certyfikatu.
Uruchom obraz kontenera przy użyciu ASP.NET Core skonfigurowanego dla protokołu HTTPS:
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
Po uruchomieniu aplikacji przejdź do https://localhost:8001
witryny w przeglądarce internetowej.
Czyszczenie
Jeśli wpisy tajne i certyfikaty nie są używane, pamiętaj, aby je wyczyścić.
dotnet user-secrets remove "Kestrel:Certificates:Development:Password" -p aspnetapp\aspnetapp.csproj
dotnet dev-certs https --clean
Przy użyciu programu PowerShell
Program PowerShell umożliwia generowanie certyfikatów z podpisem własnym. Klient PKI może służyć do generowania certyfikatu z podpisem własnym.
$cert = New-SelfSignedCertificate -DnsName @("contoso.com", "www.contoso.com") -CertStoreLocation "cert:\LocalMachine\My"
Certyfikat zostanie wygenerowany, ale na potrzeby testowania powinien zostać umieszczony w magazynie certyfikatów na potrzeby testowania w przeglądarce.
$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)
W tym momencie certyfikaty powinny być widoczne z przystawki MMC.
Przykładowy kontener można uruchomić w Podsystem Windows dla systemu Linux (WSL):
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
Uwaga
Należy pamiętać, że w przypadku instalacji woluminu ścieżka pliku może być obsługiwana inaczej na podstawie hosta. Na przykład w programie WSL można zastąpić /c/certs ciągiem /mnt/c/certs.
Jeśli używasz kontenera utworzonego wcześniej dla systemu Windows, polecenie run będzie wyglądać następująco:
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
Po uruchomieniu aplikacji przejdź do contoso.com:8001 w przeglądarce.
Upewnij się, że wpisy hosta są aktualizowane, contoso.com
aby odpowiedzieć na odpowiedni adres IP (na przykład 127.0.0.1). Jeśli certyfikat nie jest rozpoznawany, upewnij się, że certyfikat załadowany z kontenerem jest również zaufany na hoście i że istnieją odpowiednie wpisy SAN/DNS dla programu contoso.com
.
Czyszczenie
$cert | Remove-Item
Get-ChildItem $certKeyPath | Remove-Item
$rootCert | Remove-item
Za pomocą protokołu OpenSSL
Możesz użyć protokołu OpenSSL , aby utworzyć certyfikaty z podpisem własnym. W tym przykładzie użyto powłoki WSL/Ubuntu i powłoki bash z programem OpenSSL
.
To polecenie generuje plik crt i .key.
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
Aby uzyskać plik PFX, użyj następującego polecenia:
openssl pkcs12 -export -out $PARENT.pfx -inkey $PARENT.key -in $PARENT.crt
Uwaga
Począwszy od platformy .NET 5, narzędzie Kestrel może przyjmować pliki .key zakodowane w formacie Crt i PEM oprócz plików pfx z hasłem.
W zależności od systemu operacyjnego hosta certyfikat musi być zaufany. Na hoście z systemem Linux "ufanie" certyfikatowi różni się i zależy od dystrybucji.
Na potrzeby tego przewodnika przedstawiono przykład w systemie Windows przy użyciu programu PowerShell:
Import-Certificate -FilePath $certKeyPath -CertStoreLocation 'Cert:\LocalMachine\Root'
Uruchom przykład przy użyciu następującego polecenia w programie WSL:
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
Uwaga
W programie WSL ścieżka instalacji woluminu może ulec zmianie w zależności od konfiguracji.
Uruchom następujące polecenie w programie PowerShell:
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
Po uruchomieniu aplikacji przejdź do contoso.com:8001 w przeglądarce.
Upewnij się, że wpisy hosta są aktualizowane, contoso.com
aby odpowiedzieć na odpowiedni adres IP (na przykład 127.0.0.1). Jeśli certyfikat nie jest rozpoznawany, upewnij się, że certyfikat załadowany z kontenerem jest również zaufany na hoście i że istnieją odpowiednie wpisy SAN/DNS dla programu contoso.com
.
Czyszczenie
Pamiętaj, aby wyczyścić certyfikaty z podpisem własnym po zakończeniu testowania.
Get-ChildItem $certKeyPath | Remove-Item