RA-Portal

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.

Wegen eines SW Fehlers im RA-Portal ist die Beantragung von Nutzerzertifikaten bei der aktuellen Zertifizierungsstelle nicht möglich. Wir arbeiten an der Behebung des Fehlers.

Der Fehler wurde behoben.

Die für den Dienst relevanten Server müssen nach einem Systemupdate neu gestartet werden.
In dieser Zeit ist der Dienst temporär nicht erreichbar.

Zurzeit ist das RA-Portal nicht erreichbar.
Wir arbeiten an der Lösung des Problems.

Das RA-Portal ist wieder erreichbar.

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.

Bei dem verwendeten Betriebsystem wird einem Upgrade durchgeführt. Hierdurch kann der Dienst temp. für kurze Zeit nicht erreichbar sein.

Bei dem verwendeten Betriebsystem wird einem Upgrade durchgeführt. Hierdurch kann der Dienst temp. für kurze Zeit nicht erreichbar sein.

Die Wartung wurde erfolgreich abgeschlossen.

Die Ausstellung von Client-Zertifikaten (oder Nutzerzertifikaten oder S/MIME-Zertifikaten) wird z.Z. von der Zertifizierungsstelle abgelehnt. Die Erzeugung des Antrags im RA-Portal ist erfolgreich, das Absenden an die CA führt aber zu einem Fehler. Wir arbeiten an der Lösung.

Wir gehen davon aus, dass die Anwendung im Laufe der Kalenderwoche 46 wieder wie gewohnt funktioniert.

Client-Zertifikate können wieder beantragt werden. Es könnte aber aufgrund regelmäßiger Anpassungen der Zertifizierungsstelle an deren Schnittstelle gelegentlich noch zu Fehlern kommen.

Aktuell ist es nicht möglich, über das RA-Portal Client-Zertifikate zu beantragen. An einer Lösung wird gearbeitet.
--English Version--

wegen einer notwendigen Hardware Wartung eines zentralen Server in Datennetzbetrieb (NOC), werden im angegebenen Zeitraum einige Systeme nicht oder nur sporadisch funktionieren:
- RWTH-guests WLAN Datenverkehr (zentraler Router)
- Registration Authority (Kommunikation mit den Dienstanbietern)
- div. Dienste auf noc-portal, welche Kommunikation mit Routern oder Switchen erfordern

Wartung beendet. Wegen eines Hardware Schadens wurden die virtualisierten Ressourcen umverteilt.
Es wird daher eine weitere Wartung zur Wiederherstellung des Zustands erfolgen. Wir informieren entsprechend.

Zurzeit ist eine Anmeldung über RWTH Single Sign-On nicht möglich.
Bestehende Sessions sind nicht davon betroffen.
Wir arbeiten an der Behebung des Problems.
--English version---

Die Störung wurde behoben.

Aktuell kommt es zu Störungen des RWTH Single Sign-On. Nach Eingabe der Zugangsdaten lädt der Bildschirm, dann erscheint ein Internal Server Error.
Dies betrifft alle Services, welche den Single Sign-On Login verwenden.
Die zuständige Fachabteilung ist bereits informiert und arbeitet an der Behebung.
--- English version ---

Die Störung konnte behoben werden.
--- English version ---

Weitere API-Endpunkte wurden für die Verwaltung von E-Mail-Accounts durch die Netzansprechpersonen heute freigeschaltet.
Diese API-Endpunkte bilden die Funktionalität ab, die man sonst unter dem Reiter "Meine E-Mail-Domains" in graphischer Form hat.
Weitere Informationen finden Sie im RA-Portal unter
https://ra-portal.itc.rwth-aachen.de/api-tokens/documentation
Diese Funktionalität ist nur relevant für Netzansprechpersonen und nicht für Endnutzer*innen die z.B. ein Client-Zertifikat beantragen möchten.

In dem Zeitraum wird das Routing der bisherigen XWiN-Router (Nexus 7700) auf die neuen XWiN-Router (Catalyst 9600) umgestellt. Diese Router sind für die Netzverbindung der RWTH unerlässlich. Für diese Umstellung ist auch die Migration der DFN-Anbindung, welche redundant nach Frankfurt und Hannover geschaltet sind, sowie der RWTH-Firewall auf die neuen System erforderlich.
Innerhalb des Wartungsfensters wird es zu Ausfällen oder Teilausfällen der Außenanbindung kommen. Alle Services der RWTH (bspw. VPN, Email, RWTHonline, RWTHmoodle) werden innerhalb dieses Zeitraums nicht zur Verfügung zu stehen. Die Erreichbarkeit von Services innerhalb des RWTH-Netzes ist aufgrund eingeschränkter DNS-Funktionalität zeitweise nicht gegeben.
---english---

Der Uplink nach Frankfurt wurde erfolgreich auf das neue System geschwenkt.

Umbau des Uplinks nach Hannover beginnt.

Uplink nach Hannover auf das neue System umgezogen.

BGP v4/v6 nach Frankfurt und Hannover sind nun über die neue Routern funktional.

Es stehen noch ein paar kleinere Nacharbeiten an.

Wartung ist abgeschlossen. Der Datenverkehr läuft nun vollständig über die neuen Router!

Problematik mit der Anbindung zur Physik identifiziert, Lösung erfolgt morgen früh.

Das Hochladen einer selbst erzeugten (z.B. mit openssl) CSR-Datei für die Beantragung eines Nutzerzertifikats im RA-Portal ist nicht mehr möglich. Wegen der zu geringen Nutzung (weniger als 1% der Nutzerzertifikate wurden so beantragt) wird diese Funktionalität eingestellt. Nutzer*innen können weiterhin die eigene CSR-Datei im Browser erzeugen (vereinfacht ausgedrückt, die .json-Datei). Somit wird der private Schlüsselteil weder dem RA-Portal noch der CA übermittelt.

Aufgrund der Kündigung des bisherigen Zertifikat-Anbieters Sectigo ist es ab dem 9. Januar 2025 12:00 Uhr und auf noch unbestimmte Zeit nicht möglich, neue Nutzerzertifikate über das RA-Portal zu beantragen.
Obwohl der neue Zertifikat-Anbieter Harica uns zur Verfügung steht ist die Beantragung von Nutzerzertifikaten noch nicht möglich, da
- selbst generierte Schlüssel nicht unterstützt werden
- der notwendige Zeichensatz für den Common Name nicht unterstützt wird
Sobald die Beantragung im RA-Portal wieder möglich wird, werden wir
- diese Meldung aktualisieren
- den gelben Banner "Client-Zertifikatsbeantragung ab 09.01.2025 12:00 Uhr nicht mehr möglich" im RA-Portal entfernen.
--- English version ---

Die Beantragung von Client-Zertifikaten ist wieder möglich.
Außerdem ist es jetzt möglich, auszuwählen, welche Vornamen im Zertifikat übernommen werden sollen (entweder Rufname oder voller Vorname).
Aufgrund von Beschränkungen des Zeichensatzes seitens des Zertifikat-Anbieters Harica müssen wir Umlaute und sonstige Sonderzeichen im Namen automatisiert transkribieren.
Die Funktion, einen selbst erzeugten Client-Zertifikatsantrag hochzuladen, ist noch nicht verfügbar. Dies wird aber zu einem späteren Zeitpunkt wieder möglich sein.
--- English version ---

Bitte beachten Sie, dass alle SSL-Zertifikate, die ab dem 06.03.2025 im RA-Portal ausgestellt werden, ein neues intermediate Zertifikat in der Harica SSL-Zertifikatskette enthalten. D.h. am einfachsten die Download-Option "Zertifikat inklusive Kette (ohne Root-Zertifikat) herunterladen" im RA-Portal auswählen.

Aufgrund einer unvorhergesehenen Kündigung des bisherigen Zertifikat-Anbieters Sectigo wird es ab dem 9. Januar 2025 12:00 Uhr auf noch unbestimmte Zeit nicht mehr möglich sein, Zertifikate über das RA-Portal zu beantragen oder zu widerrufen. Dies betrifft SSL- und Client-Zertifikate.
GÉANT/TCS arbeitet intensiv zusammen mit DFN daran, ein lückenloses Weiterbestehen der TCS-Dienstleistung mit einem neuen Anbieter zu ermöglichen.
Der DFN erkundet parallel auch die Möglichkeiten für ein eigenes unabhängiges (von GÉANT/TCS) Angebot.
Es ist unklar, ob und wie ab dem 10. Januar 2025 Zertifikate des Anbieters Sectigo widerrufen werden können.
--- English version ---

Folgende Buttons (Funktionalität) stehen ab dem 09.01.2025 12:00 Uhr im RA-Portal nicht mehr zur Verfügung:
- Zertifikat neu hochladen (certificate upload)
- Zertifikat an die CA absenden (certificate enroll)
- Zertifikat erneuern (certificate renew)
- Zertifikat widerrufen (certificate revoke)
- OpenSSL-Befehlsgenerator
Folgende RA-Portal API-Endpunkte werden Error 503 liefern: csr-upload, enroll, renew, revoke.

Der DFN hat einen neuen Zertifikat-Anbieter (harica.gr) beauftragt. Wir arbeiten an der Umstellung (Programmierung) des RA-Portals, sodass zunächst SSL- und später auch Client-Zertifikate über diesen Anbieter erstellt werden können. Die Umstellung für SSL-Zertifikate wird voraussichtlich 2-4 Wochen dauern. Wir bitten um Ihre Geduld.
--- English version ---

Die Beantragung von SSL-Zertifikaten über das RA-Portal ist ab 07.02.2025 10:00 Uhr wieder möglich.
Der neue Zertifikat-Anbieter ist Harica.
- SSL-Zertifikat Ablaufzeit bleibt bei 1 Jahr
- Erlaubte Schlüssellängen bleiben unverändert und sind RSA-2048, RSA-3072, RSA-4096, ECC-prime256v1 und ECC-secp384r1
- "Key Usages" (X509v3 extensions) bleiben unverändert und sind:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
- z.Z. besteht eine Begrenzung auf 20 SANs pro Zertifikat.

Das Widerrufen von Zertifikaten des Zertifikat-Anbieters Sectigo ist wieder möglich:
- einfach den Widerrufen-Button im RA-Portal betätigen
- manueller Prozess Richtung Sectigo wird ausgelöst
- innerhalb den nächsten 7 Tage wird das Zertifikat widerrufen sein
- den Status kann man jederzeit im RA-Portal prüfen
Status: Momentan gültig
SN: Seriennummer
Certificate Authority: Sectigo
Ablauf: Ablaufdatum, Uhrzeit
Widerruf angefragt: Datum, Uhrzeit (Vorname Nachname)
Angefragt von: Vorname Nachname via API-Token/RA-Portal
oder
Status: Widerrufen
SN: Seriennummer
Certificate Authority: Sectigo
Widerrufen: Datum, Uhrzeit
Angefragt von: Vorname Nachname via API-Token/RA-Portal

Wir schließen diese Meldung und bitten Sie Neuheiten über Nutzerzertifikate unter der getrennten Meldung Ihttps:
maintenance.itc.rwth-aachen.de/ticket/status/messages/84/show_ticket/9722 zu folgen.

Heute Abend kam es gegen ca. 20:25 - 21:00 zu einem Performance-Tief des SSO-Service und wurde innerhalb dieser Zeit von der Fachabteilung geprüft. Das Problem ist behoben und schnelle Logins ohne Wartezeiten sind wieder möglich.
---English---

Aufgrund einer unvorhergesehenen Kündigung des aktuellen Zertifikat-Anbieters Sectigo wird es ab dem 10. Januar 2025 auf noch unbestimmte Zeit nicht mehr möglich sein, Zertifikate über das RA-Portal zu beantragen. Dies betrifft SSL- und Client-Zertifikate.
Wir empfehlen Ihnen
- Ihre SSL-Zertifikate im RA-Portal vorzeitig zu erneuern oder neue zu beantragen
- Ihre Nutzerzertifikate aus der "alten" DFN-PKI Global vorzeitig im RA-Portal neue zu beantragen
Diese Empfehlung gilt für alle Zertifikate, die vor dem 01. Juli 2025 ablaufen.
Wir informieren alle Netzansprechpersonen in den Einrichtungen über das empfohlene Handeln zu SSL- und Client-Zertifikaten zusätzlich via E-Mail.
Wir informieren alle betroffenen Personen mit Nutzerzertifikaten in der DFN-PKI Global über das empfohlene Handeln zusätzlich via E-Mail.
--- English version ---

Die Netzansprechpersonen in den Einrichtungen wurden am 22. November 2024 via E-Mail informiert.
Die betroffenen Personen mit Nutzerzertifikaten in der DFN-PKI Global wurden am 27. November 2024 via E-Mail informiert.
--- English version ---

Am 16.12.2024 wurden 292 SSL-Zertifikate durch die RWTH Registrierungsstelle automatisiert erneuert. Diese wären vor dem 01.07.2025 ersatzlos abgelaufen. Die Mitglieder der jeweiligen Netzwerkansprechpartner-Gruppen wurden via E-Mail über die Ausstellung der Zertifikate benachrichtigt.

Zurzeit ist der Single Sign-On und die Multifaktorauthentifizierung sporadisch gestört. Wir arbeiten bereits an einer Lösung und bitten um Geduld.
---english---

Wegen einer RWTH-internen Umkonfiguration der aus dem RA-Portal angesprochenen Mailserver, konnten einige ausgehende E-Mails (aus dem RA-Portal an die Endnutzer) nicht zugestellt werden.

wegen der Migration unseres Datenbankservers werden im Wartungszeitraum Applikationen auf TK-Portal, RA-Portal und NOC-Portal, sowie der Zugang zum WLAN RWTH-guests mit Gastkennung nicht zur Verfügung stehen.

Die Wartung ist beendet.

Aufgrund von Problemen mit den Loadbalancern (F5) sind ein Großteil der Services wie z.B. RWTHmoodle, RWTH Single Sign-On, RWTH E-Mail usw. sowie alle Service hinter dem RWTH Single Sign-On gestört.
--English Version--

Zur Problemlösung wurde nun zusätzlich noch ein Techniker des Herstellers hinzugezogen.

Die Störung konnte behoben werden. Allerdings kann es beim Versand bzw. Empfang noch zu Verzögerungen bei der Zustellung kommen.

Wegen eines SW-Fehlers versendet das RA-Portal z.Z. keine E-Mails z.B. zur Zertifikatsausstellung, Challenges an die Nutzer*innen usw. Wir arbeiten an die Lösung.

Aufgrund einer Datenbankwartung wird der Login in Anwendungen, die durch den RWTH Single Sign-On geschützt sind (u. a. RWTHonline, RWTHmoodle, Selfservice, SAP), im angegebenen Zeitraum kurzzeitig nicht möglich sein.
Bitte loggen Sie sich bereits vor der Wartung in die Anwendung ein, in der Sie in dem Zeitraum arbeiten möchten.
Wir gehen davon aus, dass die Unterbrechung des Login ca. fünf Minuten betragen wird.
--English Version--

Im Zuge eines Updates wird der Webserver u.a. auf dem RA-Portal neu gestartet.
--- English ---

Wegen eines SW Fehlers ist das Hochladen einer im Browser generierten CSR-Datei für ein Client-Zertifikat mit mehreren E-Mail-Adressen z.Z. nicht möglich. Wir arbeiten an einer Lösung und werden den Fehler voraussichtlich am 28.10.2024 beheben können.

Das Erstellen von Client-Zertifikatsanträgen mit mehreren SANs ist im Browser wieder möglich.

Seit dem 21.10.2024 werden neu ausgestellte SSL-Zertifikate für Webseiten, die im Rahmen des Dienstes Webhosting des IT Centers bereitgestellt werden, mit einer neuen Zertifikatskette ausgeliefert.
Alte Kette:
1a. C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
Neue Kette:
1b. C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
Das "Sectigo RSA Organization Validation Secure Server CA"-Zertifikat (unter 3a) wurde durch das "GEANT OV RSA CA 4"-Zertifikat (unter 3b) ersetzt.

Im Reiter "Meine E-Mail-Domains" können Netzansprechpersonen die E-Mail-Adressen der jeweiligen Einrichtung im RA-Portal verwalten. Bei "E-Mail-Account hinzufügen" war das Eintragen einer Absender-E-Mail bis dato case sensitive. Dies haben wir auf case insensitive geändert. D.h. wenn z.B. der Eintrag "email@itc.rwth-aachen.de" existiert, dann kann der Eintrag "Email@itc.rwth-aachen.de" usw. nicht hinzugefügt werden. Das Editieren der Absender-E-Mail war immer unterbunden. D.h. wenn Sie eine fehlerhafte Absender-E-Mail eingetragen haben, löschen Sie einfach den Eintrag. Wenn Sie aber die Challenge-E-Mail(s) schon ausgelöst haben, melden Sie sich bei ra@rwth-aachen.de, da das Löschen nicht mehr möglich ist.

Im Zuge einer Systemaktualisierung müssen die Server neu gestartet werden.
---english version---

Für eine kurze zeit gab es einen Fehler bei der Anmeldung über RWTH Single Sign-On kommen:
Internal Server Error
Das Problem konnte behoben werden.
---English---

Aufgrund von dem abgelaufenen Zertifikat für idm.rwth-aachen.de können keine IdM-Anwendungen und die Anwendungen, die über RWTH Single Sign-On angebunden sind, aufgerufen werden.
- Beim Aufrufen von IdM-Anwendungen wird eine Meldung zur unsicheren Verbindung angezeigt.
- Beim Aufrufen von Anwendungen mit dem Zugang über RWTH Single Sign-On wird eine Meldung zu fehlenden Berechtigungen angezeigt.
Wir arbeiten mit Hochdruck an der Lösung des Problems.
--- English ---

Das Zertifikat wurde aktualisiert und die Anwendungen können wieder aufgerufen werden. Bitte löschen Sie den Browsercache, bevor Sie die Seiten wieder aufrufen.

Im Zuge einer Systemaktualisierung müssen die Server neu gestartet werden.
---english version---

Wartung ist beendet

Wegen eines SW Fehlers waren im genannten Zeitraum auch für die Netzansprechpersonen aller Einrichtungen keine E-Mail-Domains unter dem Reiter "Meine E-Mail-Domains" sichtbar.

Aufgrund von kritischer Updates wird es durch einen Neustart des NOC-Portals zu einem kurzen Ausfall kommen.
Durch Schnittstellen zwischen den System, sind kurzfristig ebenfalls das TK-Portal und RA-Portal betroffen.

Updates abgeschlossen und Neustart durchgeführt.
Services laufen wieder wie gewohnt weiter.

Im Zuge einer Systemaktualisierung müssen die Server neu gestartet werden.
---english version---

Aufgrund einer Störung des DNS liefern die Nameserver verschiedener Provider aktuell keine IP-Adresse für Hosts unter *.rwth-aachen.de zurück.
Als Workaround können Sie alternative DNS-Server in Ihren Verbindungseinstellungen hinterlegen, wie z.B. die Level3-Nameserver (4.2.2.2 und 4.2.2.1) oder von Comodo (8.26.56.26 und 8.20.247.20). Ggf ist es auch möglich den VPN-Server der RWTH zu erreichen, dann nutzen Sie bitte VPN.

Anleitungen zur Konfiguration eines alternativen DNS-Server unter Windows finden Sie über die folgenden Links:
https:
www.ionos.de/digitalguide/server/konfiguration/windows-11-dns-aendern/
https:
www.netzwelt.de/galerie/25894-dns-einstellungen-windows-10-11-aendern.html
Als Alternative können Sie auch VPN nutzen. Wenn Sie den VPN-Server nicht erreichen, können Sie nach der folgenden Anleitung die Host-Datei unter Windows anpassen. Dadurch kann der Server vpn.rwth-aachen.de erreicht werden. Dazu muss der folgenden Eintrag hinzugefügt werden:
134.130.5.231 vpn.rwth-aachen.de
https:
www.windows-faq.de/2022/10/04/windows-11-hosts-datei-bearbeiten/

Die Host der RWTH Aachen sind nun wieder auch von ausserhalb des RWTH Netzwerkes erreichbar.

Auch nach der Störungsbehebung am 25.8. um 21 Uhr kann es bei einzelnen Nutzer*innen zu Problemen gekommen sein. Am 26.8. um 9 Uhr wurden alle Nacharbeiten abgeschlossen, sodass es zu keinen weiteren Problemen kommen sollte.

Wegen einer Wartung des zugrundeliegenden Datenbankservers ist im Wartungszeitraum mit Ausfällen von Webdiensten zu rechnen:
* NOC-Portal (z.B. DNS-Admin, DHCP-Admin, RADIUS-Admin, Interface-Admin, WLAN Gäste einrichten)
* TK-Portal
* RA-Portal
Die Dienste laufen wie gewohnt weiter. Bitte versuchen Sie zu einem späteren Zeitpunkt Ihre gewünschten Änderungen einzutragen.

leider ist die Wartung noch nicht zum Abschluss gekommen, weswegen die Daten heute für ca 1h nicht zur Verfügung stehen.

Die Migration ist abgeschlossen

Im Zuge einer Systemaktualisierung müssen die Server neu gestartet werden.
---english version---

Wartung ist beendet

Aufgrund von Erneuerung der SSL Zertifikate wird der vCenter Server im genannten Zeitraum teilweise kurzzeitig nicht erreichbar sein.
Alle VMs laufen wie gewohnt weiter und die Erreichbarkeit der darauf laufenden Dienste wird NICHT durch diese Wartung beeinträchtigt werden. Lediglich die Funktionen des HTML5 Clients für das Management ihrer VMs werden nicht verfügbar sein, da Sie sich während der Wartung nicht am vCenter Server einloggen können.

Während der Wartung ist es zu Fehlern gekommen, sodass die Wartung verlängert werden muss.

Aufgrund der Wartung sind gerade einige Server nicht erreichbar.
Es kommt daher kurzzeitig zu Verbindungsproblemen bei einigen Services.
---englisch version below---

Das Abfragen der validierten Domains hat wegen eines SW Updates auf Sectigo Seite nicht funktioniert. Als Folge konnten während der Störung keine Zertifikate beantragt werden oder E-Mail-Adressen durch den Netzsprechpersonen in RA-Portal eingetragen werden.

Im Zuge einer Systemaktualisierung muss das RA-Portal neu gestartet werden, wodurch das Portal (u.a. Download von Zertifikaten oder Upload von Zertifikatsanträgen) temp. nicht erreichbar sein wird.
---english version---

Seit dem 2. Juli 2024 ist der RWTH Single Sign-On (SSO) und hiermit der Login aller SSO-angebundener Services mit einer Multifaktor-Authentifizierung geschützt. Nutzende müssen neben einem individuellen Kennwort von nun an einen weiteren Sicherheitsfaktor beim Login angeben. Den zweiten Faktor müssen Sie im Selfservice [1] über den Tokenmanager generieren. Weitere Informationen finden Sie auf IT Center Help [2] und dem IT Center Blog [3].
---english version---

Aktuell ist der Login über den RWTH Single Sign-On und somit in die dahinter eingebundenen Services leider nur in Einzelfällen erfolgreich.
Bitte versuchen Sie im Falle einer Fehlermeldung den Login in ca. einer Stunde erneut.
Personen, die bereits erfolgreich eingeloggt sind, sind von der Störung nicht betroffen.
--English Version--

Die Server sind aktuell ausgelastet. Wir bitten Sie deshlab weiterhin, den Login erst zu einem späteren Zeitpunkt (ca. in einer Stunde) zu versuchen. Wir arbeiten an einer nachhaltigen Lösung des Problems.

Durch diverse Maßnahmen, die insgesamt die Performanz der Server deutlich erhöhen haben, wurden die Ladeschwierigkeiten und Loginprobleme gegen 15 Uhr behoben.
Die Meldung bleibt vorerst als Hinweis bestehen, da wir die Last des Systems weiterhin beobachten.

Der Login in den RWTH Single Sign-On ist stabilisiert. Aus dem Grund beenden wir den Hinweis.

Im Zuge einer Systemaktualisierung müssen die Server neu gestartet werden.
---english version---

Wartung ist beendet

Im Zuge einer Systemaktualisierung müssen die Server neu gestartet werden.
---english version---

Update ist erfolgt | update finished

Wegen einer fehlerhaften SW Implementierung konnten seit Oktober 2023 auch Mitglieder aller sekundären Admin-Gruppen für eine Domain diese unter "Meine E-Mail-Domains" sehen und verwalten. Die korrekte Implementierung der Admin-Reche ist aber, dass nur die Mitglieder der primären Domain-Kontakt-Gruppe diese verwalten sollen. Es gibt hier eine Ausnahme, Mitglieder einer sekundären Domain-Kontakt-Gruppe mit dem Extra-Recht "RA-Portal-Email-Domain" können auch die Domain unter "Meine E-Mail-Domains" verwalten. Die korrekte Implementierung wurde am 26.03.2024 umgesetzt.

Wegen eines SW-Fehlers wurden im Zeitraum vom 09. bis 23.04.2024 keine "SSL-Zertifikat [common_name] ausgestellt" und keine "SSL-Zertifikat [common_name] Ablauf am [ablaufdatum]" E-Mails versendet. Das RA-Portal hat das Absenden aller diesen fehlenden E-Mails am 24.04.2024 nachgeholt.