Follow this page for useful information regarding upcoming and planned changes to TCS.
| Date | Description | Background Information | Action Required |
|---|
| September 2025 | Require domain validation and CAA checks to be performed from multiple Network Perspectives (MPIC) | https://cabforum.org/2023/07/14/ballot-sc063v4-make-ocsp-optional-require-crls-and-incentivize-automation | MPIC requirements have been in place for some time but we would like to add an advisory that these new requirements can have a significant impact on certificates with a large number of SANS due to the time these checks can take. This is particularly relevant in ACME scenarios where the timeout set by a specific tool may not be compatible with the time needed to run checks. We advise that organisations look to minimise the number of SANs used within single certificates. |
| 2nd March 2026 | End of all support for OCSP URLs | The end of life for OCSP and requirement for CRL for revocation information has been progressing for sometime, this date finalises the removal of this information from TCS certificates. https://cabforum.org/2023/07/14/ballot-sc063v4-make-ocsp-optional-require-crls-and-incentivize-automation/ | No specific action needed but be aware that specific certicate implementations may need to change their default settings in order to not run into errors. |
| 15th March 2026 | Certificate validity drops to 200 days | If your certificate is issued before the deadline, it can still have the current maximum validity (398 days max). However, any certificate issued on or after 15 March 2026 must follow the new 200-day rule – even if the renewal process started earlier. For Organisation Validation (OV) certificates, the reuse periods for domain and organisation validation are also shortening in line with the certificate lifetimes. That means even your validation data (like proof of domain control) must be refreshed more frequently, reinforcing the need for automation. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/ Further informaton as of 20th February 2026: Pursuant to the updated Baseline Requirements for SSL/TLS Certificates, effective as of 15 March 2026, the reuse periods for the following validation types will be amended as follows: - Domain Validation (DCV): reduced from 398 days to 200 days
- Identity Validation (OV): reduced from 825 days to 398 daysIn order to ensure compliance with the upcoming requirements, HARICA has proactively adjusted the corresponding expiration dates for all onboarded organizations that currently maintain active Domain Validation (DCV) and/or Identity Validation (OV).
As a result, organizations will receive advance expiration notifications (15 days for DCV and 30 days for OV) in accordance with the new validation periods taking effect on 15 March 2026, enabling the timely completion of the required renewal actions.
Review of updated validation status
To review the updated expiration dates for Domain Validation and Identity Validation (OV) and to initiate the necessary actions, please refer to the attached Enterprise Admin Guide, specifically:
- C) Initiate Domain Validation for Enterprises
- E) Submit Legal Evidence for Identity Validation
Specific changes to be applied
- Domain Validation (DCV):
- For organizations with an active DCV expiring between 13 March 2026 and 26 September 2026, the expiration date has been set to 13 March 2026.
- For organizations with an active DCV expiring on 27 September 2026 or later, the expiration date has been reduced by 199 days.
These adjustments ensure that the total validity period does not exceed 199 days.
- Identity Validation (OV):
- For organizations with an active OV Validation expiring between 13 March 2026 and 13 May 2027, the expiration date has been set to 13 March 2026.
- For organizations with an active OV Validation expiring on 14 May 2027 or later, the expiration date has been reduced by 428 days.
These adjustments ensure that the total validity period does not exceed 397 days.
Important notes
- One day has been intentionally deducted from the maximum validity periods (200 → 199 days and 398 → 397 days) as a precautionary measure, ensuring that no certificate is issued without an active and valid validation in place.
- 13 March was selected as the reference date instead of 15 March, as 15 March falls on a Sunday. This allows HARICA personnel to be fully available to promptly address any potential validation-related issues.
- For OV Validations expiring within 30 days from the date of this notice, organizations are strongly advised to submit Legal Evidence for Identity Validation (OV) without delay.
| Be aware of the changing time limits and work with your organisations to support automation wherever possible. Be aware of further changes to the lifespan in upcoming years. Be aware of the changes regarding the need to provide validation documentation for organisations annually - this MUST be reuploaded even if it is the same source. Be aware that DCV dates may be brought forward in 2026 to comply with the new regulations. |
| 15th March 2026 |
|
|
|
| 15th March 2026 | Enforcement of DNSSEC | CAs complying with the TLS Baseline Requirements are required to validate DNSSEC, when present, in the course of retrieving CAA records or performing DCV-related DNS lookups from Primary Network Perspectives. https://cabforum.org/2025/06/18/ballot-sc-085v2-require-validation-of-dnssec-when-present-for-caa-and-dcv-lookups/ | No specific action required, just be aware of the potential impacts if CAA records are not correctly set. |
6th April 2026
This is currently postponed due to changes introduced by Google. Further information will follow.
https://googlechrome.github.io/chromerootprogram/#132-promote-use-of-dedicated-tls-server-authentication-pki-hierarchies | End of Support for EKU | Public TLS certificates are intended solely for server authentication on the open Internet. If they also contain the ClientAuth EKU, they could be misused for purposes that public CAs cannot validate or govern (e.g., authenticating users into enterprise systems).
This does not mean client authentication is going away — it means organisations must use private PKI, enterprise PKI services, or sector-specific solutions instead of public TLS certificates for mTLS. We recommend that TCS "IGTF Client Authentication Certificates" are used for this purpose.
| It is like that use cases will emerge where these EKUs are being actively used and they may not become apparent untl something fails when support is removed. Be aware of this as a potential root cause.
Some software might be using this as a default aproach - HARICA are aware of some issues with CISCO communication tools and Microsoft Teams.
|
