mirror of
https://github.com/veracrypt/VeraCrypt.git
synced 2026-08-02 21:26:01 +00:00
Windows: make EFI trust checks dbx-aware
Reject revoked loader CA sets and diagnose the chainloaded Windows manager. Add PCA 2011 migration warnings and update Secure Boot guidance.
This commit is contained in:
Mounir IDRASSI
@@ -53,7 +53,7 @@ Since version 1.26.29, VeraCrypt ships two complete sets of Microsoft-signed EFI
|
||||
</li>
|
||||
</ul>
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
At installation, upgrade, repair and system encryption time, VeraCrypt reads the firmware db and selects the loader set whose signing CAs are trusted. If the 2023 CA pair is present, the 2023 set is preferred; otherwise the 2011 set is used when <em>Microsoft Corporation UEFI CA 2011</em> is trusted. If Secure Boot is enabled and neither set is trusted by the firmware, VeraCrypt refuses to install its bootloader and displays an error instead of installing a loader that the firmware would reject at the next reboot.
|
||||
At installation, upgrade, repair and system encryption time, VeraCrypt reads the firmware db and dbx and selects a loader set whose known signing CAs are present in db and not listed in dbx. The optional dbx variable may legitimately be absent (especially on custom-key systems); VeraCrypt treats that state as an empty forbidden database, while a genuine read or parse failure remains an error when Secure Boot is enabled. If the 2023 CA pair is available, the 2023 set is preferred; otherwise the 2011 set is used when <em>Microsoft Corporation UEFI CA 2011</em> is available. If Secure Boot is enabled and neither set is compatible with the known CA policy, VeraCrypt refuses to install its bootloader rather than knowingly installing a loader whose CA the firmware will reject.
|
||||
</div>
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
Changing the firmware Secure Boot configuration (for example enabling additional certificates in the BIOS setup) does not by itself rewrite the files already installed on the EFI System Partition. Run VeraCrypt Setup in <em>Repair/Reinstall</em> mode after changing the firmware Secure Boot database, or let the VeraCrypt System Favorites service refresh the loader automatically (it re-evaluates the selection at Windows startup, session logon/unlock, resume from sleep, and shutdown).
|
||||
@@ -68,10 +68,27 @@ HKEY_LOCAL_MACHINE\SOFTWARE\VeraCrypt\Diagnostics\EfiBootLoader
|
||||
EfiBootLoaderResourceSet REG_DWORD 2011 (0x7db) or 2023 (0x7e7)
|
||||
EfiBootLoaderSelectionReason REG_SZ human readable selection reason
|
||||
EfiBootLoaderFirmwareDbLastError REG_DWORD last firmware db read/parse error (0 = none)
|
||||
EfiBootLoaderFirmwareDbxLastError REG_DWORD last firmware dbx read/parse error (0 = none)
|
||||
EfiBootLoaderSelectionTimeUtc REG_SZ time of the last selection
|
||||
EfiBootChainStatusKnown REG_DWORD db/dbx known-CA assessment is available
|
||||
EfiBootChainLastError REG_DWORD last incomplete-assessment error (0 = none)
|
||||
SecureBootEnabled REG_DWORD Secure Boot state at the last assessment
|
||||
FirmwareDbxPresent REG_DWORD dbx exists (0 is valid: optional variable absent)
|
||||
VeraCryptLoaderFilesValid REG_DWORD installed DCS files match one embedded set
|
||||
VeraCryptLoaderKnownCaAllowed REG_DWORD known required CAs are in db and not in dbx
|
||||
VeraCryptLoaderKnownCaRevoked REG_DWORD a known required VeraCrypt CA is in dbx
|
||||
EfiBootLoaderInstalledResourceSet REG_DWORD set identified from the actual ESP files
|
||||
EfiBootLoaderRecordedResourceSet REG_DWORD set recorded at the last successful refresh
|
||||
WindowsLoaderInspectionSucceeded REG_DWORD embedded PE signature was parsed
|
||||
WindowsLoaderPresent REG_DWORD bootmgfw_ms.vc was found
|
||||
WindowsLoaderSigner REG_DWORD 0 (unknown), 2011, or 2023
|
||||
WindowsLoaderKnownCaAllowed REG_DWORD known signing CA is in db and not in dbx
|
||||
WindowsLoaderKnownCaRevoked REG_DWORD known Windows loader signing CA is in dbx
|
||||
WindowsLoaderMigrationRecommended REG_DWORD PCA 2011 copy remains while CA 2023 is available
|
||||
EfiBootChainCheckTimeUtc REG_SZ time of the last attempted chain check
|
||||
</pre>
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
The following commands, run from an elevated PowerShell prompt, show which Microsoft certificates are present in the firmware db (note that on some firmware the names may not be visible in this simple text search even when the certificates are present):
|
||||
The following commands, run from an elevated PowerShell prompt, provide additional evidence. The text search is only a convenience and may not expose certificate names on every firmware. An absent dbx is valid; any other exception needs investigation.
|
||||
</div>
|
||||
<pre>
|
||||
reg query HKLM\SOFTWARE\VeraCrypt\Diagnostics\EfiBootLoader /s
|
||||
@@ -83,9 +100,33 @@ $t = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).Bytes)
|
||||
'Microsoft UEFI CA 2023',
|
||||
'Microsoft Option ROM UEFI CA 2023' |
|
||||
ForEach-Object { "$_ : $($t -match [regex]::Escape($_))" }
|
||||
|
||||
try {
|
||||
$dbx = (Get-SecureBootUEFI dbx).Bytes
|
||||
'Windows PCA 2011 in dbx: ' +
|
||||
([Text.Encoding]::ASCII.GetString($dbx) -match
|
||||
'Microsoft Windows Production PCA 2011')
|
||||
} catch {
|
||||
'dbx is absent or could not be read; check FirmwareDbxPresent and EfiBootLoaderFirmwareDbxLastError'
|
||||
}
|
||||
|
||||
# After mounting the EFI System Partition as S:, inspect the embedded signer.
|
||||
# Do not use Get-AuthenticodeSignature here: it may report a catalog signer.
|
||||
Get-PfxCertificate -FilePath S:\EFI\Microsoft\Boot\bootmgfw_ms.vc |
|
||||
Select-Object Subject,Issuer,Thumbprint
|
||||
|
||||
Get-WinEvent -FilterHashtable @{
|
||||
LogName='System'
|
||||
ProviderName='Microsoft-Windows-TPM-WMI'
|
||||
Id=@(1036,1037,1043,1044,1045,1797,1798,1799,1800,1801,1802,1803)
|
||||
StartTime=(Get-Date).AddDays(-30)
|
||||
} | Select-Object TimeCreated,Id,LevelDisplayName,Message
|
||||
</pre>
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
In addition, the VeraCrypt System Favorites service writes a warning to the Windows Application event log (source <em>VeraCryptSystemFavorites</em>) when it detects that the active Secure Boot db no longer trusts a component of the installed boot chain.
|
||||
In addition, the VeraCrypt System Favorites service writes a warning to the Windows Application event log (source <em>VeraCryptSystemFavorites</em>) when installed DCS files do not match an embedded set, the chainloaded Windows Boot Manager is missing or its embedded signer cannot be identified, a known required CA is absent from db or listed in dbx, or a PCA 2011-signed Windows Boot Manager should be migrated before revocation.
|
||||
</div>
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
These values are deliberately described as a <em>known-CA compatibility assessment</em>, not proof that firmware will accept an image. UEFI dbx can also contain individual image hashes, certificate TBS hashes and security-version revocations that this diagnostic does not fully evaluate. A successful controlled reboot with Secure Boot enabled remains the final validation.
|
||||
</div>
|
||||
|
||||
<h2>The Microsoft 2023 certificate transition</h2>
|
||||
@@ -97,10 +138,10 @@ Two important points for VeraCrypt users:
|
||||
</div>
|
||||
<ul style="text-align:left; margin-top:18px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
<li style="text-align:left; margin-top:0px; margin-bottom:0px; padding-top:0px; padding-bottom:0px">
|
||||
<strong>Certificate expiration does not stop already-installed loaders from booting.</strong> UEFI firmware does not evaluate certificate validity periods during Secure Boot verification, so bootloaders signed through the 2011 CAs continue to load after the expiration dates on virtually all firmware implementations. The expiration means that <em>new</em> binaries can no longer be signed through the 2011 CAs, and that systems which never receive the 2023 certificates will stop receiving boot-chain security updates.
|
||||
<strong>Certificate expiration does not normally stop already-installed loaders from booting.</strong> UEFI Secure Boot image verification does not normally enforce the signing certificate's validity period, so a loader signed through a 2011 CA is not rejected merely because that CA certificate has expired. Expiration is nevertheless the end of the signing ecosystem for new binaries; systems that never receive the 2023 certificates cannot continue receiving boot-chain updates signed through the replacement CAs.
|
||||
</li>
|
||||
<li style="text-align:left; margin-top:0px; margin-bottom:0px; padding-top:0px; padding-bottom:0px">
|
||||
<strong>A future revocation of the 2011 CAs would stop them from booting.</strong> Microsoft has announced that, at a later stage of the transition (not yet scheduled), the 2011 CAs may be revoked via the Secure Boot forbidden signature database (dbx) on systems that have completed the transition. Migrating to the 2023 loader set before that stage is therefore recommended.
|
||||
<strong>Expiration and revocation are separate.</strong> Microsoft provides a separate, deliberate mitigation that adds <em>Microsoft Windows Production PCA 2011</em> to the Secure Boot forbidden signature database (dbx); once applied, every Windows Boot Manager signed through that CA is rejected. This Windows PCA revocation is not part of the <code>0x5944</code> certificate/Boot Manager migration described below. As of July 2026, <a href="https://techcommunity.microsoft.com/blog/linuxandopensourceblog/what-it-teams-need-to-know-about-linux-secure-boot-certificates-expiring-in-2026/4530725">Microsoft states that it has no plan to revoke Microsoft Corporation UEFI CA 2011</a>, the third-party CA used by the VeraCrypt 2011 loader set. Nevertheless, migrating both the VeraCrypt and Windows portions of the chain to their 2023 CAs is recommended before applying any Windows PCA 2011 revocation.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
@@ -114,10 +155,13 @@ If the firmware provides no way to trust a Microsoft third-party CA, VeraCrypt s
|
||||
|
||||
<h2>Updating an existing system to the 2023 certificates</h2>
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
Windows deploys the 2023 certificates through a staged, telemetry-driven rollout. Devices are updated automatically only once Microsoft has high confidence in their hardware/firmware combination. Because a system-encrypted VeraCrypt machine boots through a non-standard boot chain (the VeraCrypt loader occupies the Windows Boot Manager location), such machines are typically not classified for automatic update and the rollout does not trigger on its own. The Windows Security app may report that there is <em>"not yet enough data to classify your device"</em>. For the same reason, opting into the Microsoft-managed rollout (the <code>MicrosoftUpdateManagedOptIn</code> registry value) may not be sufficient on these machines.
|
||||
Windows deploys the 2023 certificates through a staged, telemetry-driven rollout. Devices are updated automatically only once Microsoft has sufficient confidence in their hardware/firmware combination. A VeraCrypt system-encrypted machine has a non-standard boot chain because the VeraCrypt loader occupies the standard Windows Boot Manager location; this may affect servicing checks, but Microsoft does not document VeraCrypt as a categorical exclusion from the rollout. A Windows Security report that there is <em>"not yet enough data to classify your device"</em> describes the current rollout state, not proof that VeraCrypt caused it.
|
||||
</div>
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
Microsoft documents a registry value that triggers the update explicitly (see Microsoft KB5068202, <em>"Registry key updates for Secure Boot"</em>). From an elevated command prompt:
|
||||
The <code>MicrosoftUpdateManagedOptIn</code> value is a separate opt-in to Microsoft's asynchronous managed rollout. It requires the applicable Windows diagnostic-data configuration and does not guarantee immediate deployment. Do not mix that method with a manual <code>AvailableUpdates</code> deployment; choose one method and monitor it to completion.
|
||||
</div>
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
For an administrator performing a controlled manual deployment, Microsoft documents <code>0x5944</code> as the explicit request for the 2023 CA, KEK, and Windows Boot Manager migration (see <a href="https://support.microsoft.com/en-us/topic/registry-key-updates-for-secure-boot-windows-devices-with-it-managed-updates-a7be69c9-4634-42e1-9ca1-df06f43f360d">Microsoft's registry-key guidance for Secure Boot</a>). It does <strong>not</strong> apply the Windows PCA 2011 dbx revocation. VeraCrypt does not set this registry value automatically. On a fully updated Windows installation, after reviewing the precautions below:
|
||||
</div>
|
||||
<pre>
|
||||
reg add HKLM\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
|
||||
@@ -126,7 +170,7 @@ rem optionally run the servicing task immediately (it otherwise runs every 12 ho
|
||||
schtasks /Run /TN "\Microsoft\Windows\PI\Secure-Boot-Update"
|
||||
</pre>
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
Progress can be monitored under <code>HKLM\SYSTEM\CurrentControlSet\Control\Secureboot\Servicing</code> (values <code>UEFICA2023Status</code> and <code>UEFICA2023Error</code>) and through Secure Boot servicing events in the Windows event log. The db update adds <em>Windows UEFI CA 2023</em>, and, on systems that already trust <em>Microsoft Corporation UEFI CA 2011</em> (which is the case on every VeraCrypt Secure Boot system), it also adds <em>Microsoft UEFI CA 2023</em> and <em>Microsoft Option ROM UEFI CA 2023</em>.
|
||||
Progress can be monitored under <code>HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot</code> and its <code>Servicing</code> subkey, and through the Secure Boot servicing events shown above. The expected <code>AvailableUpdates</code> progression is <code>0x5944</code>, then <code>0x4100</code>, and finally the terminal modifier <code>0x4000</code> after the required task runs and restarts. <code>UEFICA2023Status=Updated</code> is useful Windows-servicing evidence, but it may remain incomplete when VeraCrypt intentionally occupies the standard ESP path. Conversely, <code>0x4000</code> alone does not prove that VeraCrypt's <code>bootmgfw_ms.vc</code> was refreshed. Verify the firmware CAs, the actual installed DCS resource set, the embedded signer of <code>bootmgfw_ms.vc</code>, and the absence of unresolved servicing errors. The db update adds <em>Windows UEFI CA 2023</em>. It conditionally adds <em>Microsoft UEFI CA 2023</em> and <em>Microsoft Option ROM UEFI CA 2023</em> on systems that already trust <em>Microsoft Corporation UEFI CA 2011</em>; not every system on which VeraCrypt can be installed necessarily has that legacy third-party CA.
|
||||
</div>
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
Before triggering the update on a VeraCrypt system-encrypted machine, take the following precautions:
|
||||
@@ -139,7 +183,10 @@ Before triggering the update on a VeraCrypt system-encrypted machine, take the f
|
||||
<strong>Create or update your VeraCrypt Rescue Disk first</strong>, and verify that it boots.
|
||||
</li>
|
||||
<li style="text-align:left; margin-top:0px; margin-bottom:0px; padding-top:0px; padding-bottom:0px">
|
||||
Do not disable the <em>VeraCrypt System Favorites</em> service or its bootloader update function. When the Windows servicing task installs the 2023-signed Windows Boot Manager at the standard location, this service is what preserves the VeraCrypt boot chain: it saves the new boot manager as <code>bootmgfw_ms.vc</code> (the copy VeraCrypt chainloads after pre-boot authentication) and restores the VeraCrypt loader.
|
||||
Record the existing <code>AvailableUpdates</code> value and make sure the device is not already managed by another Secure Boot deployment policy. Setting <code>0x5944</code> requests authenticated firmware db/KEK writes and a boot-file replacement. Firmware defects, a missing OEM-authorized KEK, interruption during servicing, or overwriting another pending deployment value can leave the transition incomplete. Use the computer manufacturer's recovery procedure if a firmware variable update fails.
|
||||
</li>
|
||||
<li style="text-align:left; margin-top:0px; margin-bottom:0px; padding-top:0px; padding-bottom:0px">
|
||||
Do not disable the <em>VeraCrypt System Favorites</em> service or its bootloader update function. When Windows installs a new Boot Manager at the standard ESP location, the service saves it as <code>bootmgfw_ms.vc</code> and restores the VeraCrypt loader. If Windows leaves the standard path unchanged, current VeraCrypt versions also inspect Windows' serviced copies under <code>%SystemRoot%\Boot\EFI_EX</code> and <code>%SystemRoot%\Boot\EFI</code>, verify the embedded signer, and atomically refresh <code>bootmgfw_ms.vc</code> with the best copy permitted by the known firmware CA policy.
|
||||
</li>
|
||||
<li style="text-align:left; margin-top:0px; margin-bottom:0px; padding-top:0px; padding-bottom:0px">
|
||||
<strong>Hidden operating system users should not trigger the update from the hidden OS.</strong> The automatic boot-chain preservation is disabled when a hidden OS is running.
|
||||
@@ -148,23 +195,26 @@ Do not disable the <em>VeraCrypt System Favorites</em> service or its bootloader
|
||||
Avoid forced power-off between the moment Windows replaces the boot manager and the next normal restart or shutdown. On most systems the VeraCrypt boot entry keeps the machine bootable during this window, but firmware that ignores the boot order could boot the plain Windows Boot Manager, which cannot start an encrypted Windows (recoverable with the Rescue Disk).
|
||||
</li>
|
||||
<li style="text-align:left; margin-top:0px; margin-bottom:0px; padding-top:0px; padding-bottom:0px">
|
||||
Expect Windows to keep reporting the Secure Boot certificate servicing as not fully completed even after everything works. Windows checks whether the file at the standard boot manager location is the 2023-signed Microsoft Boot Manager; on a VeraCrypt system that location holds the VeraCrypt loader by design. This status is cosmetic and does not affect the security or operation of the system.
|
||||
Windows may continue reporting the transition as incomplete because the standard Windows Boot Manager location contains the VeraCrypt loader by design. Treat this as a possible servicing false negative only after the firmware db contains the required 2023 CAs, <code>EfiBootLoaderInstalledResourceSet</code> identifies the actual 2023 DCS files, the <em>embedded</em> issuer of <code>bootmgfw_ms.vc</code> is <em>Windows UEFI CA 2023</em>, and the event log contains no unresolved Secure Boot servicing failure.
|
||||
</li>
|
||||
</ul>
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
After the db update has been applied, VeraCrypt automatically switches to the 2023 loader set the next time the bootloader is refreshed (Repair/Reinstall, upgrade, or one of the automatic refresh points of the System Favorites service). You can verify the result in the diagnostics registry key described above and recreate the Rescue Disk when prompted.
|
||||
After the db update has been applied, VeraCrypt automatically switches to the 2023 DCS set and attempts to import the current 2023-signed Windows Boot Manager the next time the bootloader is refreshed (Repair/Reinstall, upgrade, or one of the automatic refresh points of the System Favorites service). Verify the actual result in the diagnostics registry key and recreate the Rescue Disk when prompted.
|
||||
</div>
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
The Windows PCA 2011 dbx revocation is a later, separate operation documented in <a href="https://support.microsoft.com/en-us/topic/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d">Microsoft KB5025885</a>. Do not request its <code>0x80</code> bit (or the combined <code>0x280</code> value, which also requests the SVN update) until <code>bootmgfw_ms.vc</code> is confirmed to be signed by <em>Windows UEFI CA 2023</em>, recovery media are current, and a controlled reboot with Secure Boot enabled has succeeded. VeraCrypt never enables this revocation automatically.
|
||||
</div>
|
||||
|
||||
<h2>Recovering from a Secure Boot boot failure</h2>
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
Two distinct failures can occur when the firmware Secure Boot configuration no longer trusts a component of the boot chain:
|
||||
Two distinct failures can occur when the firmware Secure Boot policy rejects a component of the boot chain (because of a missing CA, a CA or image revocation, or another policy restriction):
|
||||
</div>
|
||||
<ul style="text-align:left; margin-top:18px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
<li style="text-align:left; margin-top:0px; margin-bottom:0px; padding-top:0px; padding-bottom:0px">
|
||||
<strong>Before the password prompt</strong> (message such as <em>"Secure Boot Violation"</em> or an immediate return to the firmware): the firmware does not trust the CA that signs the installed VeraCrypt loader.
|
||||
<strong>Before the password prompt</strong> (message such as <em>"Secure Boot Violation"</em> or an immediate return to the firmware): the firmware policy rejects the installed VeraCrypt loader.
|
||||
</li>
|
||||
<li style="text-align:left; margin-top:0px; margin-bottom:0px; padding-top:0px; padding-bottom:0px">
|
||||
<strong>After successful password entry</strong> (an explicit Secure Boot error message from the VeraCrypt loader, or on older loader versions a return to the password prompt): the firmware does not trust the CA that signs the Windows Boot Manager copy (<code>bootmgfw_ms.vc</code>) that VeraCrypt chainloads.
|
||||
<strong>After successful password entry</strong> (an explicit Secure Boot error message from the VeraCrypt loader, or on older loader versions a return to the password prompt): the firmware policy rejects the Windows Boot Manager copy (<code>bootmgfw_ms.vc</code>) that VeraCrypt chainloads.
|
||||
</li>
|
||||
</ul>
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
@@ -172,19 +222,19 @@ In both cases, the recovery procedure is:
|
||||
</div>
|
||||
<ol style="text-align:left; margin-top:18px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
<li style="text-align:left; margin-top:0px; margin-bottom:0px; padding-top:0px; padding-bottom:0px">
|
||||
Temporarily disable Secure Boot in the firmware setup and start Windows normally (VeraCrypt pre-boot authentication works with Secure Boot disabled), or boot the VeraCrypt Rescue Disk and use <em>"Restore VeraCrypt loader binaries to system disk"</em>.
|
||||
Temporarily disable Secure Boot in the firmware setup and start Windows normally (VeraCrypt pre-boot authentication works with Secure Boot disabled). The VeraCrypt Rescue Disk can restore VeraCrypt loader components when they are missing or damaged, but it cannot manufacture a current Windows Boot Manager or make a PCA 2011-signed <code>bootmgfw_ms.vc</code> acceptable after that CA has been added to dbx; it is not a substitute for completing the Windows migration.
|
||||
</li>
|
||||
<li style="text-align:left; margin-top:0px; margin-bottom:0px; padding-top:0px; padding-bottom:0px">
|
||||
In Windows, adjust the firmware/Windows Secure Boot certificates as needed (enable the third-party CAs in the firmware setup, or apply the Windows Secure Boot certificate updates as described above), then run VeraCrypt Setup in Repair/Reinstall mode.
|
||||
In Windows, adjust the firmware/Windows Secure Boot policy as needed (enable the third-party CAs in firmware setup, restore a valid dbx if a custom-key workflow removed it, or apply the Windows Secure Boot certificate updates as described above), then run VeraCrypt Setup in Repair/Reinstall mode. Repair now checks Windows' serviced <code>EFI_EX</code>/<code>EFI</code> copies and can install a compatible current Windows Boot Manager even while the standard ESP path contains VeraCrypt.
|
||||
</li>
|
||||
<li style="text-align:left; margin-top:0px; margin-bottom:0px; padding-top:0px; padding-bottom:0px">
|
||||
Re-enable Secure Boot.
|
||||
Review the VeraCrypt diagnostics and embedded signer as described above, then re-enable Secure Boot and perform a controlled reboot. Do not re-enable it while VeraCrypt reports an incomplete policy assessment or incompatible loader files.
|
||||
</li>
|
||||
</ol>
|
||||
|
||||
<h2>Legacy custom-key procedure (deprecated)</h2>
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
Older VeraCrypt versions documented a custom-key procedure (the VeraCrypt-DCS <em>SecureBoot</em> script, <code>sb_set_siglists.ps1</code>) that replaced the firmware Secure Boot databases with a custom platform key and the 2011-era Microsoft certificates. This procedure is <strong>deprecated and must not be used</strong> on systems using the 2023 certificate chain: it removes trust for the 2023-signed Windows Boot Manager and breaks the Windows boot process after VeraCrypt pre-boot authentication. Systems where it was applied should restore the manufacturer Secure Boot keys, then follow the normal procedure described on this page.
|
||||
Older VeraCrypt versions documented a custom-key procedure (the VeraCrypt-DCS <em>SecureBoot</em> script, <code>sb_set_siglists.ps1</code>) that replaced PK, KEK, db and dbx with a custom platform key, 2011-era Microsoft certificates and an obsolete bundled dbx. This procedure is <strong>deprecated and must not be used</strong> on systems using the 2023 certificate chain: it removes trust for the 2023-signed Windows Boot Manager, discards current revocations and can break the Windows handoff after VeraCrypt pre-boot authentication. Systems where it was applied should restore the manufacturer Secure Boot keys and current dbx, then follow the normal procedure described on this page.
|
||||
</div>
|
||||
|
||||
<div style="text-align:left; margin-top:19px; margin-bottom:19px; padding-top:0px; padding-bottom:0px">
|
||||
|
||||
@@ -73,7 +73,7 @@ Thus, when setting or entering your password, it's crucial to type it manually u
|
||||
<p>Note: By default, Windows 7 and later boot from a special small partition. The partition contains files that are required to boot the system. Windows allows only applications that have administrator privileges to write to the partition (when the system is
|
||||
running). In EFI boot mode, which is the default on modern PCs, VeraCrypt can not encrypt this partition since it must remain unencrypted so that the BIOS can load the EFI bootloader from it. This in turn implies that in EFI boot mode, VeraCrypt offers only to encrypt the system partition where Windows is installed (the user can later manually encrypt other data partitions using VeraCrypt).
|
||||
In MBR legacy boot mode, VeraCrypt encrypts the partition only if you choose to encrypt the whole system drive (as opposed to choosing to encrypt only the partition where Windows is installed).</p>
|
||||
<p>In EFI boot mode with Secure Boot enabled, VeraCrypt selects a Microsoft UEFI CA-signed bootloader set trusted by the active firmware Secure Boot db during install, repair, upgrade, or Windows PostOOBE repair. The 2023 VeraCrypt loader set requires both Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023, while the 2011 loader set requires Microsoft Corporation UEFI CA 2011. If the active db trusts neither supported set, VeraCrypt aborts instead of installing a loader that firmware will reject. If you manually change firmware Secure Boot db entries, run VeraCrypt repair or reinstall to refresh the installed bootloader set. For details, including the Microsoft 2023 certificate transition and recovery procedures, see <a href="EFISecureBoot.html" style="text-align:left; color:#0080c0; text-decoration:none">EFI Secure Boot</a>.</p>
|
||||
<p>In EFI boot mode with Secure Boot enabled, VeraCrypt selects a Microsoft UEFI CA-signed bootloader set allowed by the active firmware Secure Boot policy during install, repair, upgrade, or Windows PostOOBE repair: every required CA must be present in the allowed database (db) and absent from the forbidden database (dbx). The 2023 VeraCrypt loader set requires both Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023, while the 2011 loader set requires Microsoft Corporation UEFI CA 2011. If the active db/dbx policy permits neither supported set, VeraCrypt aborts instead of installing a loader that firmware will reject. If you manually change firmware Secure Boot db or dbx entries, run VeraCrypt repair or reinstall to refresh the installed bootloader set. For details, including the Microsoft 2023 certificate transition and recovery procedures, see <a href="EFISecureBoot.html" style="text-align:left; color:#0080c0; text-decoration:none">EFI Secure Boot</a>.</p>
|
||||
<p> </p>
|
||||
<p><a href="Hidden%20Operating%20System.html" style="text-align:left; color:#0080c0; text-decoration:none; font-weight:bold">Next Section >></a></p>
|
||||
</div>
|
||||
|
||||
Reference in New Issue
Block a user