Générer des certificats auto-signés avec CLI .NET

Il existe différentes façons de créer et d’utiliser des certificats auto-signés pour les scénarios de développement et de test. Cet article traite de l’utilisation de certificats auto-signés avec dotnet dev-certs et d’autres options telles que PowerShell et OpenSSL.

Vous pouvez ensuite valider que le certificat sera chargé à l’aide d’un exemple tel qu’une application ASP.NET Core hébergée dans un conteneur.

Prérequis

Pour dotnet dev-certs, veillez à avoir la version appropriée de .NET installée :

• Installer .NET sur Windows
• Installer .NET sur Linux
• Installer .NET sur macOS

Cet échantillon exige Docker 17.06 ou version ultérieure du client Docker.

Préparer l’échantillon d’application

Pour ce guide, vous allez utiliser un échantillon d’application et apporter des changements le cas échéant.

Assurez-vous que l’échantillon d’application Dockerfile utilise .NET 8.

Selon le système d’exploitation hôte, vous allez peut-être devoir mettre à jour le runtime ASP.NET. Par exemple, pour cibler le runtime Windows approprié, passez de mcr.microsoft.com/dotnet/aspnet:8.0-nanoservercore-2009 AS runtime à mcr.microsoft.com/dotnet/aspnet:8.0-windowsservercore-ltsc2022 AS runtime dans le Dockerfile.

Par exemple, cela vous aidera à tester les certificats sur 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"]

Si vous testez les certificats sur Linux, vous pouvez utiliser le fichier Dockerfile existant.

Assurez-vous que aspnetapp.csproj inclut la version cible de .Net Framework appropriée :

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

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

</Project>

Notes

Si vous souhaitez utiliser des paramètres dotnet publish pour découper le déploiement, assurez-vous que les dépendances appropriées sont incluses pour la prise en charge des certificats SSL. Mettez à jour le fichier dotnet-docker\samples\aspnetapp\aspnetapp.csproj pour vous assurer que les assemblys appropriés sont inclus dans le conteneur. Pour référence, vérifiez la procédure de mise à jour du fichier .csproj pour prendre en charge les certificats SSL lors de l’utilisation du découpage pour les déploiements autonomes.

Vérifiez que vous pointez vers l’échantillon d’application.

cd .\dotnet-docker\samples\aspnetapp

Générez le conteneur à des fins de test localement.

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

Créer un certificat auto-signé

Vous pouvez créer un certificat auto-signé :

• Avec dotnet dev-certs
• À l’aide de PowerShell
• Avec OpenSSL

Avec dotnet dev-certs

Vous pouvez utiliser dotnet dev-certs pour travailler avec des certificats auto-signés.

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

Notes

Le nom du certificat, dans ce cas aspnetapp.pfx doit correspondre au nom de l’assembly de projet. crypticpassword est utilisé comme remplacement d’un passe de votre choix. Si la console retourne « Un certificat HTTPS valide est déjà présent », un certificat approuvé existe déjà dans votre magasin. Il peut être exporté à l’aide de la console MMC.

Configurez les secrets d’application, pour le certificat :

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

Notes

Remarque : le mot de passe doit correspondre au mot de passe utilisé pour le certificat.

Exécutez l’image conteneur avec ASP.NET Core configuré pour 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

Une fois l’application démarrée, accédez à https://localhost:8001 dans votre navigateur web.

Nettoyage

Si les secrets et les certificats ne sont pas utilisés, veillez à les nettoyer.

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

Avec PowerShell

Vous pouvez utiliser PowerShell pour générer des certificats auto-signés. Le client PKI peut être utilisé pour générer un certificat auto-signé.

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

Le certificat sera généré, mais à des fins de test, il doit être placé dans un magasin de certificats à des fins de test dans un navigateur.

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

À ce stade, les certificats doivent être visibles à partir d’un composant logiciel enfichable MMC.

Vous pouvez exécuter l’échantillon de conteneur dans le Sous-système Windows pour 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

Remarque

Notez qu’avec le montage du volume, le chemin d’accès au fichier peut être géré différemment en fonction de l’hôte. Dans WSL par exemple, vous pouvez remplacer /c/certs par /mnt/c/certs.

Si vous utilisez le conteneur créé précédemment pour Windows, la commande d’exécution se présente comme suit :

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

Une fois l’application activée, accédez à contoso.com:8001 dans un navigateur.

Assurez-vous que les entrées de l’hôte sont mises à jour pour contoso.com pour répondre sur l’adresse IP appropriée (par exemple 127.0.0.1). Si le certificat n’est pas reconnu, assurez-vous que le certificat chargé avec le conteneur est également approuvé sur l’hôte et qu’il existe des entrées SAN/DNS appropriées pour contoso.com.

Nettoyage

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

Avec OpenSSL

Vous pouvez utiliser OpenSSL pour créer des certificats auto-signés. Cet exemple utilise WSL/Ubuntu et un interpréteur de commandes bash avec OpenSSL.

Cette commande génère un fichier .crt et un fichier .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

Pour obtenir un fichier .pfx, utilisez la commande suivante :

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

Remarque

À partir de .NET 5, Kestrel peut prendre les fichiers .crt et (encodés PEM) .key, en plus des fichiers .pfx avec un mot de passe.

En fonction du système d’exploitation hôte, le certificat doit être approuvé. Sur un hôte Linux, le certificat est différent et dépendant de la distribution.

Pour les besoins de ce guide, voici un exemple dans Windows utilisant PowerShell :

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

Exécutez l’exemple au moyen de la commande suivante dans 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

Remarque

Dans WSL, le chemin de montage du volume peut changer en fonction de la configuration.

Exécutez la commande suivante dans 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

Une fois l’application activée, accédez à contoso.com:8001 dans un navigateur.

Assurez-vous que les entrées de l’hôte sont mises à jour pour contoso.com pour répondre sur l’adresse IP appropriée (par exemple 127.0.0.1). Si le certificat n’est pas reconnu, assurez-vous que le certificat chargé avec le conteneur est également approuvé sur l’hôte et qu’il existe des entrées SAN/DNS appropriées pour contoso.com.

Nettoyage

Veillez à nettoyer les certificats auto-signés une fois le test terminé.

Get-ChildItem $certKeyPath | Remove-Item

Voir aussi

• dotnet dev-certs