Servereinstellungen
Die Servereinstellungen sind unter https://YOURNAME.radius-as-a-service.com/settings/server verfügbar
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.

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.

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

RADIUS / UDP
Dieser Abschnitt ist verfügbar, wenn Sie mindestens einen RADIUS-Proxy. 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
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.

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.
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:
Navigieren Sie zu Einstellungen > Servereinstellungen
Klicken Sie auf Hinzufügen
Wählen Sie Lassen Sie RaaS eine CA für Sie erstellen
Klicken Sie auf Speichern
Nach der Erstellung sehen Sie unter Serverzertifikate ein neues Zertifikat verfügbar

Verwenden Sie Ihr eigenes Zertifikat
Falls Sie die Kunden-CAnicht 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:
Navigieren Sie zu Ihrem SCEPman Certificate Master-Webportal.
Wählen Sie links Zertifikat anfordern
Wählen Sie (Web-)Server oben
Wählen Sie Formular
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 und geben Sie einen beliebigen FQDN an. Wir empfehlen, den SAN des Standard-Serverzertifikats anzupassen, z. B.
radsec-<Ihr RADIUSaaS-Instanzname>.radius-as-a-service.com.Setzen Sie das Dateiformat für den Download auf PEM
Wählen Sie Zertifikatskette einbeziehen und laden Sie das Zertifikat herunter.
Stellen Sie sicher, dass sowohl Server- als auch Clientauthentifizierung für die EKU enthalten sind.
Senden Sie die Anfrage zum Herunterladen des neuen Serverzertifikats ab.

Laden Sie das neue Serverzertifikat in RADIUSaaS
Um Ihr oben erstelltes Serverzertifikat hinzuzufügen, navigieren Sie zu RADIUSaaS-Instanz > Einstellungen > Servereinstellungen > Hinzufügen, dann
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)
Ziehen Sie Ihre Zertifikatsdatei per Drag & Drop hierher oder klicken Sie, um sie zu durchsuchen
Geben Sie das Passwort Ihres Privaten Schlüssels
Klicken Sie auf Speichern

Zertifikatsaktivierung
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:
Klicken Sie auf CA-Zertifikat herunterladen oben. Dadurch wird direkt das vertrauenswürdige Root-CA des aktuell aktiven Serverzertifikats heruntergeladen.
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.

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:
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
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.

Wenn das Dreieck neben dem aktiven RADIUS-Serverzertifikat angezeigt wird, folgen Sie dieser Anleitung, um es zu aktualisieren:
Zuletzt aktualisiert
War das hilfreich?