> For the complete documentation index, see [llms.txt](https://docs.radiusaas.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.radiusaas.com/de/admin-portal/settings/settings-server.md). # Servereinstellungen ## Ports & IP-Adressen ### Übersicht RADIUSaaS betreibt einen RadSec-Dienst, um seinen Nutzern eine sichere cloudbasierte Authentifizierung bereitzustellen. Darüber hinaus bietet RADIUSaaS für diejenigen Kunden, die RadSec in ihrer Netzwerkumgebung nicht nutzen können, z. B. aufgrund von Hardware- und Softwareeinschränkungen, RADIUS-Proxies an, die die Protokollkonvertierung von RADIUS zu RadSec übernehmen. Sowohl der RadSec- als auch der RADIUS-Dienst bieten öffentliche IP-Adressen, die es Ihren Netzwerkgeräten und Diensten ermöglichen, von überall über das Internet mit unserem Dienst zu kommunizieren. Diese Dienste arbeiten auf ihren eindeutigen registrierten Ports. ## RadSec / TCP
#### **RadSec-DNS** Der DNS-Eintrag, über den der RadSec-Dienst erreicht werden kann. #### **Server-IP-Adressen** Dies ist die öffentliche IP-Adresse des RadSec-Dienstes. #### **RadSec-Ports** Dies ist der registrierte Port für RadSec: 2083 ### Failover & Redundanz In Fällen, in denen Kunden höhere Redundanzstufen benötigen, können für Ihre Instanz mehrere RadSec-Endpunkte konfiguriert werden, wodurch zusätzliche IP-Adressen bereitgestellt werden. Bitte beachten Sie, dass für diesen Dienst zusätzliche Kosten anfallen.
{% hint style="info" %} Es ist wichtig zu beachten, dass RADIUSaaS **KEIN Failover bereitstellt** zwischen RadSec-Endpunkten. Stattdessen wird dieses Failover in der Regel auf Ihrer Netzwerkausrüstung implementiert, wie im folgenden Beispiel mit Meraki gezeigt. Es wird empfohlen, Ihr Failover-Szenario mithilfe von IP-Adressen statt DNS zu konfigurieren, um eine bessere Übersicht und weniger Abhängigkeit von einem zusätzlichen Dienst (DNS) zu haben. {% endhint %} In dieser Konfiguration werden die beiden RadSec-IP-Adressen in der Reihenfolge ihrer Priorität aufgeführt. Wenn Meraki eine der IP-Adressen nicht erreichen kann, versucht es in der Regel noch zwei weitere Male und wechselt dann zur nächsten. Weitere Informationen zur Failover-Fähigkeit Ihres Meraki- (oder anderen) Systems entnehmen Sie bitte Ihren eigenen Unterlagen.

Anzeige mehrerer RadSec-Server in der Reihenfolge der Priorität (Meraki).

## RadSec-Einstellungen ### Maximale TLS-Version Diese Einstellung steuert die maximale TLS-Version für Ihre **RadSec-Schnittstelle**. Die Mindestversion ist auf 1.2 festgelegt, die Standard-Maximalversion ist auf 1.3 gesetzt. TLS 1.3 bietet mehrere Vorteile gegenüber 1.2, darunter den Mechanismus zur Authentifizierung nach dem Handshake, der das Anfordern zusätzlicher Anmeldeinformationen vor Abschluss des Handshakes ermöglicht. Dies ist wichtig für die im nächsten Abschnitt behandelten Überprüfungen der Widerrufsprüfung für RadSec-Zertifikate. ### Maximale EAP-TLS-Version Diese Einstellung steuert die maximale TLS-Version, die bei EAP verwendet wird, wenn sich Ihre Endpunkte gegenüber Ihrer RADIUSaaS-Instanz mit einem Zertifikat (EAP-TLS) oder [Benutzername/Passwort-Anmeldeinformationen](/de/admin-portal/benutzer/users.md#protocols). Für alle modernen Betriebssysteme **ist TLS 1.3 die empfohlene Standardvorgabe**. Allerdings warben bestimmte (ältere) Windows 10/11-Builds mit TLS-1.3-Unterstützung für EAP-TLS, jedoch mit einer nicht konformen Implementierung. Wenn Windows-Clients auf betroffenen Builds Verbindungsprobleme aufweisen, begrenzen Sie die ausgehandelte Protokollversion auf TLS 1.2, um eine breitere Kompatibilität zu gewährleisten. ### Widerrufsprüfung für RadSec-Zertifikate {% hint style="info" %} Diese Einstellung legt fest, ob für alle RadSec-Verbindungen eine Widerrufsprüfung durchgeführt werden soll. Die Methode zur Überprüfung der Widerrufsprüfung unterscheidet sich leicht von derjenigen, die für Clientauthentifizierungszertifikate verwendet wird. {% endhint %} Für einen ordnungsgemäßen RadSec-Betrieb stellen Netzwerkgeräte wie Access Points, Switches und VPN-Server eine TLS-geschützte Verbindung zum RadSec-Server her. RadSec-Bereitstellungen verwenden typischerweise Mutual TLS (mTLS), bei dem sich beide Peers mithilfe von X.509-Zertifikaten während des TLS-Handshakes gegenseitig authentifizieren. Die Implementierung von RADIUSaaS erzwingt mTLS. Um die Gültigkeit und den Widerrufsstatus eines RadSec-Clientzertifikats zu bestimmen, muss das Zertifikat vom Client als Teil des TLS-Authentifizierungsprozesses vorgelegt werden. Erst nachdem das Zertifikat empfangen wurde, können Widerrufsprüfungen (z. B. über CRL oder OCSP) durchgeführt werden. #### **TLS 1.2** TLS 1.2 unterstützt die gegenseitige TLS-Authentifizierung während des ersten Handshakes mithilfe der `CertificateRequest`, `Certificate`, und `CertificateVerify` Nachrichten. Wenn die Clientauthentifizierung erforderlich und korrekt durchgesetzt wird, wird das RadSec-Clientzertifikat vor dem Aufbau der TLS-Sitzung und bevor RADIUS-Datenverkehr ausgetauscht wird vorgelegt, validiert und auf Widerruf geprüft. \ TLS 1.2 erlaubt jedoch auch optionale Clientauthentifizierung und unterstützt Neuverhandlungen. Dadurch können einige RadSec-Clientimplementierungen den ersten Handshake abschließen, ohne ein Clientzertifikat vorzulegen. Dieses Verhalten ist implementierungsspezifisch und keine Einschränkung des TLS-1.2-Protokolls. {% hint style="info" %} Um das oben beschriebene Verhalten zu entschärfen, wird die **Widerrufsprüfung für RadSec-Zertifikate** Einstellung deaktiviert, wenn die maximale TLS-Version auf 1.2 gesetzt ist. Bitte beachten Sie, dass Sie sie später manuell wieder aktivieren können. {% endhint %} #### **TLS 1.3** TLS 1.3 bietet ein deterministischeres und schlankeres Modell für die gegenseitige TLS-Authentifizierung. Wenn die Clientauthentifizierung angefordert wird, wird das RadSec-Clientzertifikat als Teil des ersten Handshakes ausgetauscht und vor dem Aufbau der TLS-Verbindung validiert.\ Dadurch kann der RadSec-Server das Clientzertifikat, einschließlich seines Widerrufsstatus, sofort überprüfen und den Handshake fehlschlagen lassen, wenn das Zertifikat ungültig oder widerrufen ist. Dadurch ermöglicht TLS 1.3 eine strengere und besser vorhersagbare Durchsetzung der gegenseitigen TLS-Authentifizierung für RadSec-Verbindungen. {% hint style="info" %} Die **Widerrufsprüfung für RadSec-Zertifikate** Einstellung wird automatisch aktiviert, wenn die maximale TLS-Version auf 1.3 gesetzt ist. {% endhint %}
## RADIUS / UDP Dieser Abschnitt ist verfügbar, wenn Sie mindestens einen [RADIUS-Proxy](/de/admin-portal/settings/settings-proxy.md). Für jeden Proxy ist eine separate öffentliche IP-Adresse verfügbar. Die öffentlichen IP-Adressen in diesem Abschnitt unterstützen ausschließlich das RADIUS-Protokoll und lauschen daher auf den Ports 1812/1813.
### **Server-IP-Adressen und Standort** {% hint style="warning" %} Diese IP-Adressen lauschen nur auf [RADIUS](/de/overview.md#what-is-radius) über UDP-Ports 1812/1813. {% endhint %} Geolokation des/der RADIUS-Proxys sowie der jeweiligen öffentlichen IP-Adresse(n). ### **Gemeinsame Geheimnisse** Das Shared Secret für den jeweiligen RADIUS-Proxy. Standardmäßig werden alle RADIUS-Proxys mit demselben Shared Secret initialisiert.

Anzeige der Änderung von Shared Secrets pro Proxy

### **Ports** Dieser Abschnitt zeigt die Standardports für die Dienste RADIUS-Authentifizierung (1812) und RADIUS-Abrechnung (1813) an. ### **Failover & Redundanz** #### Proxy-Redundanz Beachten Sie, dass ein einzelner RADIUSaaS-Proxy keine Redundanz bietet. Um Redundanz sicherzustellen, richten Sie mehrere RADIUSaaS-Proxys wie beschrieben ein [hier](/de/admin-portal/settings/settings-proxy.md#load-balancing). #### RadSec-Dienst-Redundanz für Proxys Bei der Verwendung von RADIUSaaS mit mehreren RadSec-Instanzen werden Proxys automatisch so konfiguriert, dass sie sich mit allen verfügbaren RadSec-Instanzen verbinden. Ein RADIUSaaS-Proxy priorisiert die Verbindung zum nächstgelegenen regionalen RadSec-Dienst. Wenn dieser Dienst nicht verfügbar ist, wechselt er zu einem anderen verfügbaren RadSec-Dienst. ## Serverzertifikate ### Kunden-CA Standardmäßig generiert RADIUSaaS ein **RADIUS-Serverzertifikat** das von einer Zertifizierungsstelle (CA) signiert ist, die auf unserem Dienst ausschließlich für genau diesen Zweck verfügbar ist. Wir bezeichnen sie als die **Kunden-CA**. Die Kunden-CA ist für jeden Kunden eindeutig. Um Ihre Kunden-CA zu erstellen, befolgen Sie diese einfachen Schritte: 1. Navigieren Sie zu **Einstellungen** > **Servereinstellungen** 2. Klicken Sie auf **Hinzufügen** 3. Wählen Sie **Lassen Sie RaaS eine CA für Sie erstellen** 4. Klicken Sie auf **Speichern** 5. Nach der Erstellung sehen Sie unter Serverzertifikate ein neues Zertifikat verfügbar
### Verwenden Sie Ihr eigenes Zertifikat Falls Sie die **Kunden-CA**nicht verwenden möchten, können Sie bis zu zwei Ihrer eigenen Zertifikate hochladen. #### Von SCEPman ausgestelltes Serverzertifikat Bitte befolgen Sie diese Schritte, um SCEPman Certificate Master zu nutzen und ein neues Serverzertifikat zu erzeugen: 1. Navigieren Sie zu Ihrem SCEPman Certificate Master-Webportal. 2. Wählen Sie links Zertifikat anfordern 3. Wählen Sie **(Web-)Server** oben 4. Wählen Sie **Formular** 5. Geben Sie alle Subject Alternative Names (SANs) ein, für die das Zertifikat gültig sein soll, getrennt durch Kommas, Semikolons oder Zeilenumbrüche. Erstellen Sie ein Serverzertifikat wie beschrieben [hier](https://docs.scepman.com/certificate-deployment/certificate-master/tls-server-certificate-pkcs-12) und geben Sie einen beliebigen FQDN an. Wir empfehlen, den SAN des Standard-Serverzertifikats anzupassen, z. B. `radsec-.radius-as-a-service.com`. 6. Setzen Sie das **Dateiformat für den Download** auf **PEM** 7. Wählen Sie **Zertifikatskette einbeziehen** und laden Sie das Zertifikat herunter. 8. Stellen Sie sicher, dass **sowohl Server- als auch Clientauthentifizierung** für die EKU enthalten sind. 9. **Senden Sie** die Anfrage zum Herunterladen des neuen Serverzertifikats ab. {% hint style="warning" %} **Wichtig**: Notieren Sie sich das Passwort vorübergehend, da es aus Certificate Master nicht wiederhergestellt werden kann. {% endhint %}
### Laden Sie das neue Serverzertifikat in **RADIUSaaS** Um Ihr oben erstelltes Serverzertifikat hinzuzufügen, navigieren Sie zu **RADIUSaaS-Instanz** > **Einstellungen** > **Servereinstellungen** > **Hinzufügen,** dann 1. Wählen Sie **PEM- oder PKCS#12-codiertes Zertifikat** (Wenn Sie in Schritt 5 PKCS#12 ausgewählt haben, enthält dies sowohl den öffentlichen als auch den privaten Schlüssel) 2. Ziehen Sie Ihre Zertifikatsdatei per Drag & Drop hierher oder klicken Sie, um sie zu durchsuchen 3. Geben Sie das Passwort Ihres **Privaten Schlüssels** 4. Klicken Sie auf **Speichern**
{% hint style="info" %} Bitte beachten Sie: Standardmäßig stellt SCEPman Certificate Master Zertifikate aus, die 730 Tage gültig sind. Wenn Sie dies ändern möchten, lesen Sie bitte die [Dokumentation](https://docs.scepman.com/advanced-configuration/application-settings/certificates#appconfig-validityperioddays). {% endhint %} ### Zertifikatsaktivierung {% hint style="warning" %} Stellen Sie sicher, dass Sie das Ablaufdatum Ihres Serverzertifikats überwachen und es rechtzeitig erneuern, um Dienstunterbrechungen zu vermeiden. {% endhint %} Da Zertifikate von Zeit zu Zeit ablaufen oder sich Ihre Präferenz hinsichtlich der zu verwendenden Zertifikate ändern kann, ist es wichtig, dass Sie das von Ihrem Server verwendete Zertifikat steuern können. Die **Aktiv** Spalte zeigt Ihnen das Zertifikat, das Ihr Server derzeit verwendet. Um das von Ihrem Server verwendete Zertifikat zu ändern, erweitern Sie die Zeile des Zertifikats, das Sie auswählen möchten, und klicken Sie auf **Aktivieren**. ### Herunterladen Um Ihr **Serverzertifikat** herunterzuladen, haben Sie zwei Optionen: 1. Klicken Sie auf **CA-Zertifikat herunterladen** oben. Dadurch wird direkt das **vertrauenswürdige Root-CA** des aktuell **aktiven** Serverzertifikats heruntergeladen. 2. Klicken Sie auf das **Download-** Symbol in der entsprechenden Zeile.
**Option 2** öffnet einen Dialog, der den vollständigen Zertifikatspfad anzeigt. Das **Root-Zertifikat** wird immer grün markiert sein.

Anzeige des Root-Zertifikats in Grün

Bei beiden Optionen ist das heruntergeladene Root-Zertifikat in Base64 (PEM) kodiert. Falls Ihr Gerät (z. B. ein WiFi-Controller) eine binäre Kodierung (DER) benötigt, können Sie es mit [OpenSSL](https://openssl.org/): ```sh openssl x509 -inform pem -in -outform der -out ``` ### Löschen Um ein Zertifikat zu löschen, erweitern Sie die entsprechende Zeile, klicken Sie auf **Löschen** und bestätigen Sie Ihre Auswahl. ### Zertifikatsablauf {% hint style="danger" %} Lassen Sie das RADIUS-Serverzertifikat nicht ablaufen. Dadurch wird die Authentifizierung unterbrochen. {% endhint %} Zertifikate laufen von Zeit zu Zeit ab. Fünf Monate bevor Ihr Zertifikat abläuft, weist Sie Ihr Dashboard durch die Anzeige eines Warnsymbols darauf hin. ![Screenshot, der den Ablauf des Zertifikats zeigt](/files/0061977ddad48076b2cf4ecb68d55b1361ea5860) Wenn das Dreieck neben dem aktiven RADIUS-Serverzertifikat angezeigt wird, folgen Sie dieser Anleitung, um es zu aktualisieren: {% content-ref url="/pages/06ae9d9cfee479bac5c22c76b960116f4e1c4674" %} [Erneuerung des Serverzertifikats](/de/konfiguration/renew-certificate.md) {% endcontent-ref %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.radiusaas.com/de/admin-portal/settings/settings-server.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.