Aug 02, 2019 If the verified certificate in its certification chain refers to the root CA that participates in this program, the system will automatically download this root certificate from the Windows Update servers and add it to the trusted ones. Windows requests a trusted root certificate lists (CTL) renewal once a week. For certificates that are issued by Enterprise CAs, the validity period is defined in the template that is used to create the certificate. Windows 2000 and Windows Server 2003 Standard Edition do not support modification of these templates. Windows Server 2003 Enterprise Edition supports Version 2 certificate templates that can be modified.

1. Windows 7 Iso
2. Windows 7 Download

• If a chain ends up in root certificate which is part of the Root Program but is not present in the list of trusted roots currently on the machine, Windows downloads the appropriate root certificate directly from Windows Update. The full process for all versions of the OS is described in a KB article. I’m not going to rehash the explanation of.
• When configured in alternate client TLS binding mode, AD FS performs device certificate authentication on port 443 and user certificate authentication on port 443 as well, on a different hostname. The user certificate hostname is the AD FS hostname pre-pended with 'certauth', for example 'certauth.fs.contoso.com'.
• Replace $CERT with the path to your certificate the you previously installed to the system. Replace $ALIAS with the preferred alias to be used in the keystore. Note that changeit is the default password for Java's cacerts file. Check whether it has been changed on your system. When prompted, check the certificate and confirm that it should be trusted.

This article describes how to change the validity period of a certificate that is issued by Certificate Authority (CA).

Original product version: Windows 10 - all editions, Windows Server 2012 R2
Original KB number: 254632

Summary

By default, the lifetime of a certificate that is issued by a Stand-alone Certificate Authority CA is one year. After one year, the certificate expires and is not trusted for use. There may be situations when you have to override the default expiration date for certificates that are issued by an intermediate or an issuing CA.

The validity period that is defined in the registry affects all certificates that are issued by Stand-alone and Enterprise CAs. For Enterprise CAs, the default registry setting is two years. For Stand-alone CAs, the default registry setting is one year. For certificates that are issued by Stand-alone CAs, the validity period is determined by the registry entry that is described later in this article. This value applies to all certificates that are issued by the CA.

For certificates that are issued by Enterprise CAs, the validity period is defined in the template that is used to create the certificate. Windows 2000 and Windows Server 2003 Standard Edition do not support modification of these templates. Windows Server 2003 Enterprise Edition supports Version 2 certificate templates that can be modified. The validity period defined in the template applies to all certificates issued by any Enterprise CA in the Active Directory forest. A certificate that is issued by a CA is valid for the minimum of the following periods of time:

• The registry validity period that is noted earlier in this article.

  This applies to the stand-alone CA, and Subordinate CA certificates issued by the Enterprise CA.

• The template validity period.

This applies to the Enterprise CA. Templates supported by Windows 2000 and Windows Server 2003 Standard Edition cannot be modified. Templates supported by Windows Server Enterprise Edition (Version 2 templates) do support modification.

For an Enterprise CA, the validity period of an issued certificate is set to the minimum of all the following:

• The registry validity period of the CA (for example: ValidityPeriod Years, ValidityPeriodUnits 1)
• The template validity period
• The remaining validity period of the signing certificate of the CA
• If the EDITF_ATTRIBUTEENDDATE bit is enabled in the policy module's EditFlags registry value, the validity period specified through the request attributes (ExpirationDate:Date or ValidityPeriod:YearsnValidityPeriodUnits:1)

Note

• The ExpirationDate:Date syntax was not supported until Windows Server 2008.
• For a stand-alone CA, no templates are processed. Therefore, the template validity period does not apply.

The expiration date of the CA certificate

A CA cannot issue a certificate with a longer validity period than its own CA certificate.

Note

The Request Attribute name is made up of value string pairs that accompany the request and that specify the validity period. By default, this is enabled by a registry setting on a Standalone CA only.

Change expiration date of certificates issued by CA

To change the validity period settings for a CA, follow these steps.

Important

This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, see How to back up and restore the registry in Windows.

1. Click Start, and then click Run.

2. In the Open box, type regedit, and then click OK.

3. Locate, and then click the following registry key:

   HKEY_LOCAL_MACHINESystemCurrentControlSetServicesCertSvcConfiguration<CAName>

4. In the right pane, double-click ValidityPeriod.

5. In the Value data box, type one of the following, and then click OK:

   • Days
   • Weeks
   • Months
   • Years

6. In the right pane, double-click ValidityPeriodUnits.

7. In the Value data box, type the numeric value that you want, and then click OK. For example, type 2.

8. Stop, and then restart the Certificate Services service. To do so:

   1. Click Start, and then click Run.

   2. In the Open box, type cmd, and then click OK.

   3. At the command prompt, type the following lines. Press ENTER after each line.

   4. Type exit to quit Command Prompt.

To help prevent man-in-the-middle attacks, the January 2021 cumulative update for Windows 10 further improves security for devices that scan Windows Server Update Services (WSUS) for updates. These improvements build on the security changes for Windows devices scanning WSUS we introduced on September 8, 2020 and can be combined with certificate pinning for greater security. I'll now explain these changes in more detail.

Scanning behavior changes

For devices scanning HTTPS-configured WSUS servers

For those using proxies, we have switched to using system proxy first, rather than user proxy. This ensures that we are first trying the most secure proxy path if a proxy is needed. We will no longer fall back to user proxy for scanning WSUS servers if the policy to allow user proxy as a fallback method is not enabled. This ensures that admins must consciously enable a less secure method for scanning as doing so will put them at higher risk of attack.

If you need to allow devices to scan utilizing user proxy as a fallback method, you can do so by configuring one of the following policies:

To further increase security, we have added the capability for customers to pin certificates (cert-pinning) and not allow scans, even with system proxy, if cert-pinning fails. This provides the highest level of security for devices but will require more overhead for the admin in order to ensure that certificate stores are properly configured.

To enable cert-pinning, simply add the correct certificates to the new WSUS certificate store. Devices will then automatically begin enforcing cert-pinning when scanning your WSUS server. If no certificates are in your WSUS certificate store, cert-pinning will not be enforced. Further, if you do not wish devices to have this extra layer of security upon scan, you can ensure that cert-pinning is not enforced by configuring one of the following policies:

For devices scanning HTTP-configured WSUS servers

For those devices scanning HTTP-configured WSUS servers, there have been no additional changes since those we introduced with the September 2020 cumulative update.

For online scans

The order of proxy selection for online scans, if a proxy is needed, has changed:

Old behavior:

• Scan with user proxy.
• If user proxy fails, attempt scan with system proxy.

Windows 7 Iso

New behavior as of the January 2021 cumulative update:

• Scan with system proxy.
• If system proxy fails, attempt scan with user proxy.

This change ensures that we first try the most secure proxy path if a proxy is needed.

Next steps

To prevent scan failures and ensure the highest level of security, please follow these recommendations:

Windows 7 Download

• Don’t enable user proxy.
• If you require user proxy, enable user proxy via “Select the proxy behavior for Windows Update client for detecting updates” to ensure that devices do not encounter scan issues.
  

  Note: While this will allow you to fallback to use user proxy for scans against your WSUS server, you should be leveraging this process only as a stop gap to continue getting updates while transitioning to system proxy or no proxy.

• Secure your WSUS server with TLS protocol/HTTP. This is pivotal to maintain the chain of trust and prevent attacks on your client computers, see Recommendations for greater security in the previous Changes to improve security for Windows devices scanning WSUS blog.
• When scanning against a TLS/HTTPS-configured WSUS server, leverage cert-pinning to get the highest level of security and keep your devices protected. (Reminder that this requires populating the device’s certificate store.)