RA-Portal

Auf Grund von neuen bzw. aktualisierten Anforderungen der Baseline Requirements Dokumente vom CA/Browser-Forum und der Root-Programme von Browser- und Betriebssystemherstellern sind folgende Änderungen bei der Zertifikatausstellung von Server-Zertifikaten bei TCS (HARICA):
- Verkürzung der Gültigkeitsdauern von neuen Server-Zertifikaten auf maximal 200 Tage
- Verkürzung der Validierungszeiträume für Domains (DV) auf maximal 200 Tage
- Verkürzung der Validierungszeiträume für Organisationen (OV) auf maximal 398 Tage
- Erweiterte und verschärfte DNSSEC-Prüfung bei Domain-Validierung (DV) und CAA-Record-Prüfung

Die Server, die für die Bereitstellung des RA-Portals nötig sind, müssen im Zuge eines Updates neu gestartet werden. In dieser Zeit können keine neuen Zertifikate beantragt oder beantragte abgeholt werden.

Der folgende Text wurde aus dem Harica Info Schreiben übernommen, und wird nicht übersetz. Sollten Sie Fragen haben melden Sie sich bitte bei ra@rwth-aachen.de.

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.

Die Änderung wurde zur Umsetzung der "Google Chrome Root Program Policy" notwendig. Diese "... strengthens security by ensuring that server authentication certificates are restricted strictly to server authentication."
Für standard Webserver (HTTPS) ergibt dieser Wegfall keine Änderung, da solche Server kein clientAuth benötigen.
Bis zum 01.03.2026 von Harica ausgestellte SSL-Zertifikate bleiben bis zu deren Ablaufdatum gültig, mit clientAuth gesetzt.
Für Server mit Mutual TLS (mTLS) Konfigurationen müssen Sie handeln. Wenn Sie das Harica SSL-Zertifikat für Server und Client Authentifizierung benötigen oder benutzt haben, müssen Sie bald auf distinkte Zertifikate umstellen. Zertifikate mit clientAuth gibt es von Harica als S/MIME-Zertifikate oder von der privaten DFN Community PKI als Serverzertifikate mit z.B. "Profil Shibboleh IdP SP".
Eine mTLS Konfiguration bedeutet, dass das gleiche SSL-Zertifikat für die Authentifizierung des Servers gegenüber seiner Clients (z.B. Webserver) als für die Authentifizierung des Servers als Client gegenüber anderer Back-End Systeme (z.B. zwischen LDAPs) benutzt wird.

Google hat kurzfristig am 05.02.2026 die Chrome Root Program Policy derart geändert, dass der Zeitpunkt des Wegfalls der EKU clientAuth in Server-Zertifikaten vom 15. Juni 2026 um ca. 9 Monate auf den 15. März 2027 verschoben ist.

Als Folge verschiebt HARICA den Termin für den Wegfall der EKU clientAuth in neu ausgestellten HARICA TCS Server-Zertifikaten um ebenfalls ca. neun Monate nach hinten.

Bereits ausgestellte Server-Zertifikate sind von dieser Änderung nicht betroffen!

Der DFN Verein empfehlt trotzdem für die mutual TLS (mTLS) Szenarien, wo es denn jetzt schon technisch möglich ist, möglichst bald die Umstellung auf jeweils separate Server-Zertifikate (dann halt erstmal weiterhin mit den EKUs serverAuth & clientAuth) und Client-Zertifikate mit der EKU clientAuth (letztere z.B. von der DFN-Verein Community-PKI oder einer internen PKI) vorzunehmen. Kommt es hierbei zu unerwartet auftretenden Problemen, haben Sie nun ca. neun Monate Zeit für eine Lösungsfindung gewonnen.