Hoe dotnetup downloads verifieert

dotnetup verifieert de .NET SDK's en runtimes die het downloadt voordat het deze extraheert. Het type verificatie is afhankelijk van waar de build vandaan komt.

Uitgebrachte builds

Voor uitgebrachte builds gebruikt dotnetup een vertrouwensketen die begint met een ondertekend releasemanifest:

1. dotnetup downloadt de .NET releasemanifesten. Deze manifesten zijn de releases-index en het releases.json bestand voor elk kanaal.
2. dotnetup Controleert de losgekoppelde codehandtekening (.p7s bestand) van elk manifest. Als de handtekening ontbreekt of niet geldig is, mislukt de commando.
3. Het geverifieerde manifest bevat de SHA-512-hash van elk archief.
4. dotnetup downloadt het archief en vergelijkt de SHA-512-hash met de hash in het manifest. Als de hashes niet overeenkomen, mislukt de opdracht en extraheert dotnetup het archief niet.

Omdat met het ondertekende manifest de hash van elk archief wordt vastgemaakt, controleert dotnetup geen afzonderlijke handtekening voor elk archief.

Handtekeningverificatie controleert ook online de intrekkingsstatus van het certificaat. Toegang tot de vereiste certificaatintrekkingseindpunten toestaan. Als deze controles door het netwerk worden geblokkeerd, mislukt de verificatie en dotnetup stopt de installatie, zelfs wanneer de handtekening geldig is.

Vervaldatum manifest

releasemanifesten bevatten een vervaltijd. dotnetup controleert of het manifest niet is verlopen, zelfs als de handtekening ervan en de archiefhashes geldig zijn. Er wordt ook gecontroleerd of het manifest vóór de vervaltijd is ondertekend.

Een onjuiste systeemklok of een verlopen manifest kan ertoe leiden dat verificatie mislukt. Zie Een releasemanifest is verlopen voor hulp bij herstel.

Vertrouwde certificaten

Voor manifesthandtekeningen en hun tijdstempels gebruikt dotnetup vertrouwde hoofdcertificaten die zijn gebundeld met het hulpprogramma. Er worden geen certificaten uit het vertrouwensarchief van het besturingssysteem toegevoegd aan die vertrouwenswortels.

Als u een certificaat toevoegt aan het vertrouwensarchief van het besturingssysteem, zorgt dat er niet voor dat dotnetup een handtekening voor het releasemanifest uit de certificaatketen van dat certificaat vertrouwt. De handtekening moet voldoen aan het verificatiebeleid van dotnetup en terug te voeren zijn op een meegeleverde vertrouwde root.

Dagelijkse en niet-openbare prerelease-builds

Dagelijkse builds en voorlopige versies die zich niet in het ondertekende releasemanifest bevinden, zijn afkomstig uit een andere feed. Deze builds hebben een SHA-512-hashbestand, maar geen codehandtekening. Voor deze builds verifieert dotnetup alleen de SHA-512-hash.

dotnetup gebruikt dit pad wanneer u installeert:

• Een dagelijks kanaal, zoals daily of 10.0-daily.
• Een volledig opgegeven prereleaseversie, zoals 10.0.100-preview.4.25216.37, die zich niet in het releasemanifest bevindt.

Voordat de installatie wordt gestart, wordt deze waarschuwing weergegeven door dotnetup:

⚠ Daily builds are not code-signed. Only the SHA-512 hash is verified.

Zie Preview en dagelijkse builds gebruiken voor meer informatie over dagelijkse builds.

Niet-ondertekende downloads blokkeren

Beheerders kunnen de installatie blokkeren van builds die niet met code zijn ondertekend. Wanneer dit beleid van kracht is, installeert dotnetup nog steeds uitgebrachte builds, maar mislukken installaties van dagelijkse en niet-vermelde prerelease-builds.

Windows

Maak de BlockUnsignedDownloads-registerwaarde aan als een REG_DWORD met een niet-nulwaarde onder HKLM\SOFTWARE\Policies\Microsoft\dotnet\Dotnetup. Voer bijvoorbeeld deze opdrachten uit in een PowerShell-sessie met verhoogde bevoegdheid:

$key = 'HKLM:\SOFTWARE\Policies\Microsoft\dotnet\Dotnetup'
New-Item -Path $key -Force | Out-Null
New-ItemProperty -Path $key -Name 'BlockUnsignedDownloads' -PropertyType DWord -Value 1 -Force | Out-Null

Als u het beleid wilt wissen, verwijdert u de waarde of stelt u het in op 0.

Linux en macOS

Maak het /etc/dotnet/dnup-block-unsigned-downloads bestand. De inhoud van het bestand maakt niet uit. Voorbeeld:

sudo mkdir -p /etc/dotnet
sudo touch /etc/dotnet/dnup-block-unsigned-downloads

Als u de beleidsinstelling wilt wissen, verwijdert u het bestand.

Geblokkeerde installaties

Wanneer het beleid een installatie blokkeert, geeft dotnetup een fout weer die vergelijkbaar is met het volgende bericht:

An IT policy on this machine requires code-signed downloads. Installing daily or unsigned prerelease builds of SDK <version> is blocked. Choose a released version, or have an administrator clear the policy ...

Als u wilt doorgaan, installeert u een vrijgegeven versie of vraagt u de beheerder om de beleidsinstelling te wissen.

Het uitvoerbare dotnetup-bestand

De get-dotnetup downloadscripts controleren het gedownloade dotnetup uitvoerbare bestand met het BIJBEHORENDE SHA-512-controlesombestand. Zie Aan de slag met dotnetup voor meer informatie.

dotnetup self update controleert ook de SHA-512-controlesom van het gedownloade uitvoerbare bestand. Als in Windows het geïnstalleerde uitvoerbare bestand Authenticode is ondertekend, moet de vervanging een Authenticode-handtekening hebben met een door Microsoft vertrouwde hoofdcertificeringsinstantie. Andere platforms en niet-ondertekende Windows installaties zijn afhankelijk van de controlesom.

Self-update maakt momenteel gebruik van de niet-ondertekende blobfeed, niet de ondertekende .NET releasemanifesten die eerder zijn beschreven. Het beleid voor niet-ondertekend downloaden blokkeert ook het zelf bijwerken van deze feed.

Na vervanging voert dotnetup het nieuwe uitvoerbare bestand uit met --version en controleert het of de versie overeenkomt met de opgeloste release. Als deze controle mislukt, probeert dotnetup het vorige uitvoerbare bestand te herstellen. Deze opstartcontrole authenticeert de download niet.

Zie ook

• Hoe dotnetup werkt
• Kanalen en versies
• Dagelijkse kanalen