RA-Portal

New CA/Browser-Forum requirements take effect, which bring the following changes to the issuance of TLS server certificates through Harica.
- TLS server certificate validity maximum of 200 days
- Domain revalidation (DV) interval maximum of 200 days
- Organisation revalidation (OV) interval maximum of 398 days
- Extended and more rigorous validation of DNSSEC at Domain Validation (DV) and CAA Record Validation

The following text comes from our certification authority Harica, we saw no need to change it.

Effective March 2, 2026, HARICA will officially deprecate the use of the Online Certificate Status Protocol (OCSP) for all newly issued publicly- trusted server TLS certificates, with exceptions made only for specific use cases where required.
In accordance with evolving industry standards and browser requirements, certificates issued after this date will no longer contain an OCSP responder URL in the Authority Information Access (AIA) extension, by default. Instead, certificate revocation status will be managed exclusively through Certificate Revocation Lists (CRLs) and modern browser-native mechanisms.

Why is this change happening?
The industry-wide move away from OCSP is driven by three primary factors:
1. User Privacy: Standard OCSP requests are unencrypted. When a browser checks a certificate’s status via OCSP, it informs the CA which IP address is visiting which website. Removing OCSP eliminates this privacy leak, ensuring that HARICA cannot track user browsing patterns.
2. Reliability and Performance: OCSP lookups often add significant latency to the TLS handshake (the "OCSP stapling" solution, while helpful, has seen inconsistent adoption). Furthermore, if an OCSP responder is slow or unreachable, it can cause "soft-fail" delays or "hard-fail" connection errors, impacting site availability.
3. Modern Revocation Standards: Browsers such as Apple Safari, Google Chrome and Mozilla Firefox have shifted toward more efficient, privacy- preserving methods for checking revocation at scale, such as CRLSets and CRLite. These methods rely on the CA publishing compressed CRLs rather than answering individual OCSP queries.

Timeline of Changes
March 2, 2026: All new TLS certificates issued by HARICA will omit the OCSP AIA extension by default.
Post-March 2, 2026: Existing certificates issued prior to this date will continue to have functional OCSP support until their natural expiration. By May 4, 2027, we expect our public OCSP infrastructure to be fully decommissioned for TLS.

Impact on Subscribers
For the vast majority of subscribers, no action is required. Modern web browsers (Chrome, Safari, Firefox, and Edge) have already prepared for this transition. However, a small number of "legacy" or "non-browser" applications that rely strictly on the presence of an OCSP URL in the certificate for hard-fail revocation checking may experience issues. We recommend the following:
- Review Legacy Systems: If you use specialized hardware or older software that requires OCSP for mutual TLS (mTLS) or specific compliance checks, ensure they support CRL-based revocation. If you operate legacy systems that rely exclusively on OCSP and cannot process CRLs, please contact [ra@rwth-aachen.de].
- OCSP Stapling: If you currently use OCSP Stapling on your web servers, the server will simply stop stapling a response once the new certificate (without an OCSP URL) is installed. This will not break the connection in modern browsers.

This update is required by the Google Chrome Root Program Policy. It strengthens security by ensuring that server authentication certificates are restricted strictly to server authentication.
For Standard Web Servers (HTTPS): There is no impact. Certificates used solely to secure a website and issued prior to the effective date will remain valid and functional until their expiration date.
For Mutual TLS (mTLS) Configurations: If you currently use the same certificate to identify your server to clients and to authenticate your server as a client to other back-end systems, you must take action, by e.g. separating your certificates. The clientAuth EKU is included in S/MIME certificates issued by Harica, via RA-Portal, or in server certificates issued by the private DFN-Verein Community PKI (with e.g. profile "Shibboleh IdP SP").

Following the recent (05.02.2026 ) updates to the Chrome Root Program Policy and the extension of the deprecation timeline for the TLS Client Authentication EKU in TLS Server certificates, HARICA will continue to support the EKU "clientAuth" in its TLS Server certificates for approximately nine (9) more months.
DFN urges you nevertheless to disentangle your mTLS certificates as soon as possible, in order to have sufficient time to resolve any unforeseen technical issues.

Due to a SW error in RA-Portal it is currently not possible to apply for a user certificate (S/MIME) from our certification authority. We apologise for the inconvenience and are working on the solution.

The error has been resolved.