Condividi tramite


Generare certificati autofirmati con l'interfaccia della riga di comando di .NET

Esistono diversi modi per creare e usare certificati autofirmati in scenari di sviluppo e test. Questo articolo illustra l'uso di certificati autofirmati con dotnet dev-certs e altre opzioni come PowerShell e OpenSSL.

È quindi possibile verificare che il certificato venga caricato usando un esempio come un'app ASP.NET Core ospitata in un contenitore.

Prerequisiti

Per dotnet dev-certs, assicurarsi che sia installata la versione appropriata di .NET:

Questo esempio richiede Docker 17.06 o versioni successive del client Docker.

Preparare l'app di esempio

In questa guida, si userà un'app di esempio e si apporteranno modifiche se necessario.

Controllare che il Dockerfile dell'app di esempio usi .NET 8.

A seconda del sistema operativo dell'host, potrebbe essere necessario aggiornare il runtime ASP.NET. Ad esempio, per specificare come destinazione il runtime di Windows appropriato, cambiare mcr.microsoft.com/dotnet/aspnet:8.0-nanoservercore-2009 AS runtime in mcr.microsoft.com/dotnet/aspnet:8.0-windowsservercore-ltsc2022 AS runtime nel Dockerfile.

Ad esempio, ciò consentirà di testare i certificati in 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"]

Se si testano i certificati in Linux, è possibile usare il Dockerfile esistente.

Assicurarsi che aspnetapp.csproj includa il framework di destinazione appropriato:

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

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

</Project>

Nota

Se si desidera usare i parametri dotnet publish per ridurre la distribuzione, assicurarsi che le dipendenze appropriate siano incluse per il supporto dei certificati SSL. Aggiornare il file dotnet-docker\samples\aspnetapp\aspnetapp.csproj per assicurarsi che gli assembly appropriati siano inclusi nel contenitore. Per riferimento, controllare come aggiornare il file con estensione csproj per supportare certificati SSL quando si riducono le distribuzioni autonome.

Assicurarsi di puntare all'app di esempio.

cd .\dotnet-docker\samples\aspnetapp

Compilare il contenitore per il test in locale.

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

Creare un certificato autofirmato

È possibile creare un certificato autofirmato:

Con dotnet dev-certs

È possibile usare dotnet dev-certs lavorare con i certificati autofirmati.

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

Nota

Il nome del certificato, in questo caso aspnetapp.pfx, deve corrispondere al nome dell'assembly del progetto. crypticpassword viene usato come stand-in per una password di propria scelta. Se la console restituisce il messaggio "Un certificato HTTPS valido è già presente", esiste già un certificato attendibile nell'archivio. Può essere esportato tramite la console MMC.

Configurare i segreti dell'applicazione per il certificato:

dotnet user-secrets -p aspnetapp\aspnetapp.csproj init
dotnet user-secrets -p aspnetapp\aspnetapp.csproj set "Kestrel:Certificates:Development:Password" "crypticpassword"

Nota

Nota: la password deve corrispondere alla password usata per il certificato.

Eseguire l'immagine del contenitore con ASP.NET Core configurato per 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

Dopo l'avvio dell'applicazione, visitare passare a https://localhost:8001 nel Web browser.

Eseguire la pulizia

Se i segreti e i certificati non sono in uso, assicurarsi di pulirli.

dotnet user-secrets remove "Kestrel:Certificates:Development:Password" -p aspnetapp\aspnetapp.csproj
dotnet dev-certs https --clean

Con PowerShell

È possibile usare PowerShell per generare certificati autofirmati. Il client PKI può essere usato per generare un certificato autofirmato.

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

Il certificato verrà generato, ma ai fini del test deve essere inserito in un archivio certificati per il test in un browser.

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

A questo punto, i certificati devono essere visualizzabili da uno snap-in MMC.

È possibile eseguire il contenitore di esempio in sottosistema Windows per 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

Nota

Si noti che con il volume del montaggio, il percorso del file può essere gestito in modo diverso in base all'host. Ad esempio, in WSL si potrebbe sostituire /c/certs con /mnt/c/certs.

Se si usa il contenitore compilato in precedenza per Windows, il comando Esegui sarà simile al seguente:

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

Quando l'applicazione è attiva, passare a contoso.com:8001 in un browser.

Assicurarsi che le voci host vengano aggiornate in modo che contoso.com risponda all'indirizzo IP appropriato, ad esempio 127.0.0.1. Se il certificato non viene riconosciuto, assicurarsi che anche il certificato caricato con il contenitore sia attendibile nell'host e che siano presenti voci SAN/DNS appropriate per contoso.com.

Eseguire la pulizia

$cert | Remove-Item
Get-ChildItem $certKeyPath | Remove-Item
$rootCert | Remove-item

Con OpenSSL

È possibile usare OpenSSL per creare certificati autofirmati. Questo esempio usa WSL/Ubuntu e una shell bash con OpenSSL.

Questo comando genera un file con estensione crt e un .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

Per ottenere un file PFX, usare il comando seguente:

openssl pkcs12 -export -out $PARENT.pfx -inkey $PARENT.key -in $PARENT.crt

Nota

A partire da .NET 5, Kestrel può accettare file .crt e .key con codifica PEM, oltre a file .pfx con password.

A seconda del sistema operativo host, il certificato deve essere considerato attendibile. In un host Linux, l'"attendibilità" del certificato è diversa e dipendente dalla distribuzione.

Ai fini di questa guida, di seguito è riportato un esempio in Windows con PowerShell:

Import-Certificate -FilePath $certKeyPath -CertStoreLocation 'Cert:\LocalMachine\Root'

Eseguire l'esempio usando il comando seguente in 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

Nota

In WSL, il percorso di montaggio del volume potrebbe cambiare a seconda della configurazione.

In PowerShell eseguire questo comando:

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

Quando l'applicazione è attiva, passare a contoso.com:8001 in un browser.

Assicurarsi che le voci host vengano aggiornate in modo che contoso.com risponda all'indirizzo IP appropriato, ad esempio 127.0.0.1. Se il certificato non viene riconosciuto, assicurarsi che anche il certificato caricato con il contenitore sia attendibile nell'host e che siano presenti voci SAN/DNS appropriate per contoso.com.

Eseguire la pulizia

Assicurarsi di pulire i certificati autofirmati una volta eseguiti i test.

Get-ChildItem $certKeyPath | Remove-Item

Vedi anche