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 by 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

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.

Die Beantragung von Client-Zertifikaten ist z.Z. nicht möglich. Das RA-Portal fragt die RWTH-Postfächer der Antragsteller*innen bei dem RWTH-Mail-Server ab. Diese Kommunikation ist wegen einer Umstellung der Schnittstelle zwischen den beiden Systemen nicht möglich. Wir arbeiten an einer Lösung.

Manche Nutzer*innen können seit der Aktualisierung der Schnittstelle zwischen RA-Portal und RWTH-Mail-Server keine Nutzer-Zertifikate beantragen. Das RA-Portal meldet "Error 503 - Service Unavailable" mit Erklärung "Die Abfrage Ihrer E-Mail-Accounts ist fehlgeschlagen. Die Beantragung von Client-Zertifikaten ist daher aktuell nicht möglich. Bitte versuchen Sie es zu einem späteren Zeitpunkt erneut."

Wir haben den Timeout-Timer bei der Abfrage der E-Mail-Adressen beim RWTH-Mailserver erhöht. Für Nutzer*innen mit vielen Postfächern kann das Auflisten der eigenen E-Mail-Adressen bei der Zertifikatsbeantragung gefühlt ewig dauern. Die endgültige Lösung wird mit der anstehenden Umstellung auf die REST API zum Mailserver erfolgen. Sollten Nutzer*innen bis dahin auf Error 503 stoßen, bitten wir diese das Problem an die ra@rwth-aachen.de zu melden. Bitte nennen Sie dabei Datum und Uhrzeit.