Configuración del servidor

La configuración del servidor está disponible en https://YOURNAME.radius-as-a-service.com/settings/server

Puertos y direcciones IP

Resumen

RADIUSaaS opera un servicio RadSec para proporcionar autenticación segura basada en la nube a sus usuarios. Además, para aquellos clientes que no pueden utilizar RadSec en su entorno de red, por ejemplo, debido a limitaciones de hardware y software, RADIUSaaS proporciona proxies RADIUS, que gestionan la conversión de protocolo de RADIUS a RadSec.

Tanto el servicio RadSec como el servicio RADIUS ofrecen direcciones IP públicas que permiten a los dispositivos y servicios de su red comunicarse con nuestro servicio desde cualquier lugar a través de Internet. Estos servicios operan en sus puertos registrados únicos.

RadSec / TCP

DNS de RadSec

La entrada DNS a través de la cual se puede acceder al servicio RadSec.

Direcciones IP del servidor

Esta es la dirección IP pública del servicio RadSec.

Puertos de RadSec

Este es el puerto registrado para RadSec: 2083

Conmutación por error y redundancia

En los casos en que los clientes requieran niveles más altos de redundancia, se pueden configurar múltiples puntos finales de RadSec para su instancia, proporcionando direcciones IP adicionales. Tenga en cuenta que hay un costo adicional por este servicio.

Es importante tener en cuenta que RADIUSaaS NO proporciona conmutación por error entre los puntos finales de RadSec. En su lugar, esta conmutación por error normalmente se implementa en su equipo de red, como se muestra en el siguiente ejemplo usando Meraki.

Se recomienda configurar su escenario de conmutación por error utilizando direcciones IP en lugar de DNS para una mejor visibilidad y menos dependencia de un servicio adicional (DNS).

En esta configuración, las dos direcciones IP de RadSec se enumeran en orden de preferencia. Cuando Meraki no puede الوصول a una de las direcciones IP, normalmente lo intentará dos veces más y pasará a la siguiente. Para obtener más información sobre la capacidad de conmutación por error de su sistema Meraki (u otro), consulte sus propios recursos.

Mostrando varios servidores RadSec en orden de prioridad (Meraki).

Configuración de RadSec

Versión máxima de TLS

Esta configuración controla la versión máxima de TLS para su interfaz RadSec. La versión mínima está fijada en 1.2 y la máxima predeterminada está establecida en 1.3.

TLS 1.3 ofrece varias ventajas sobre 1.2, incluido el mecanismo de autenticación posterior al handshake, que permite solicitar credenciales adicionales antes de completar el handshake. Esto es importante para las comprobaciones de verificación de la configuración de certificados de RadSec que se analizan a continuación.

Versión máxima de EAP TLS

Esta configuración controla la versión máxima de TLS utilizada con EAP cuando sus puntos finales se autentican contra su instancia de RADIUSaaS usando un certificado (EAP-TLS) o credenciales de usuario/contraseña.

Para todos los sistemas operativos modernos, TLS 1.3 es el valor predeterminado recomendado. Sin embargo, ciertas compilaciones (más antiguas) de Windows 10/11 anunciaban compatibilidad con TLS 1.3 para EAP-TLS con una implementación no conforme. Si los clientes Windows en compilaciones afectadas presentan problemas de conectividad, limite la versión de protocolo negociada a TLS 1.2 para una mayor compatibilidad.

Comprobación de revocación para certificados de RadSec

Esta configuración determina si se debe realizar una comprobación de revocación para todas las conexiones RadSec. El método para verificar la comprobación de revocación difiere ligeramente del utilizado para los certificados de autenticación de clientes.

Para un funcionamiento correcto de RadSec, los dispositivos de red, como puntos de acceso, switches y servidores VPN, establecen una conexión protegida por TLS con el servidor RadSec. Las implementaciones de RadSec suelen usar TLS mutuo (mTLS), donde ambos pares se autentican entre sí usando certificados X.509 durante el handshake de TLS. La implementación de RADIUSaaS impone mTLS.

Para determinar la validez y el estado de revocación de un certificado de cliente RadSec, el cliente debe presentar el certificado como parte del proceso de autenticación TLS. Solo después de recibir el certificado se pueden realizar las comprobaciones de revocación (por ejemplo, mediante CRL u OCSP).

TLS 1.2

TLS 1.2 admite la autenticación mutua TLS durante el handshake inicial usando los CertificateRequest, Certificatey CertificateVerify mensajes. Cuando se requiere autenticación del cliente y se aplica correctamente, el certificado de cliente RadSec se presenta, valida y comprueba su revocación antes de que se establezca la sesión TLS y antes de que se intercambie cualquier tráfico RADIUS.

Sin embargo, TLS 1.2 también permite autenticación opcional del cliente y admite renegociación. Como resultado, algunas implementaciones de clientes RadSec pueden completar el handshake inicial sin presentar un certificado de cliente. Este comportamiento es específico de la implementación y no una limitación del protocolo TLS 1.2.

Para mitigar el comportamiento anterior, la Comprobación de revocación para certificados de RadSec configuración se desactiva cuando la versión máxima de TLS se establece en 1.2. Tenga en cuenta que puede reactivarla manualmente más tarde.

TLS 1.3

TLS 1.3 proporciona un modelo más determinista y simplificado para la autenticación mutua TLS. Cuando se solicita autenticación del cliente, el certificado de cliente RadSec se intercambia como parte del handshake inicial y se valida antes de que se establezca la conexión TLS. Esto permite que el servidor RadSec verifique inmediatamente el certificado del cliente, incluido su estado de revocación, y que falle el handshake si el certificado no es válido o ha sido revocado. Como resultado, TLS 1.3 permite una aplicación más estricta y predecible de la autenticación mutua TLS para las conexiones RadSec.

La Comprobación de revocación para certificados de RadSec configuración se habilita automáticamente cuando la versión máxima de TLS se establece en 1.3.

RADIUS / UDP

Esta sección está disponible cuando ha configurado al menos un proxy RADIUS. Para cada proxy, hay disponible una dirección IP pública independiente. Las direcciones IP públicas de esta sección solo admiten el protocolo RADIUS y, por lo tanto, escuchan en los puertos 1812/1813.

Direcciones IP del servidor y ubicación

Estas direcciones IP solo escuchan en RADIUS a través de los puertos UDP 1812/1813.

Geolocalización de los proxies RADIUS, así como de la(s) respectiva(s) dirección(es) IP pública(s).

Secretos compartidos

El secreto compartido para el proxy RADIUS correspondiente. De forma predeterminada, todos los proxies RADIUS se inicializan con el mismo secreto compartido.

Mostrando el cambio de secretos compartidos por proxy

Puertos

Esta sección muestra los puertos estándar para los servicios de autenticación RADIUS (1812) y contabilidad RADIUS (1813).

Conmutación por error y redundancia

Redundancia del proxy

Tenga en cuenta que un único proxy de RADIUSaaS no proporciona redundancia. Para garantizar la redundancia, configure varios proxies de RADIUSaaS como se describe aquí.

Redundancia del servicio RadSec para proxies

Al usar RADIUSaaS con múltiples instancias de RadSec, los proxies se configuran automáticamente para conectarse a todas las instancias de RadSec disponibles. Un proxy de RADIUSaaS priorizará la conexión al servicio RadSec regional más cercano. Si ese servicio no está disponible, cambiará a otro servicio RadSec disponible.

Certificados del servidor

Customer-CA

De forma predeterminada, RADIUSaaS genera un certificado de servidor RADIUS firmado por una autoridad de certificación (CA) que está disponible en nuestro servicio únicamente para este propósito. Nos referimos a ella como la Customer-CA. La Customer-CA es única para cada cliente.

Para crear su Customer-CA, siga estos sencillos pasos:

1. Vaya a Configuración > Configuración del servidor
2. Haga clic en Agregar
3. Elija Deja que RaaS cree una CA para ti
4. Haga clic en Guardar
5. Después de la creación, verá un nuevo certificado disponible en Certificados del servidor

Traiga su propio certificado

En caso de que no desee usar la Customer CA, puede cargar hasta dos certificados propios.

certificado de servidor emitido por SCEPman

Siga estos pasos para aprovechar SCEPman Certificate Master y generar un nuevo certificado de servidor:

1. Vaya al portal web de SCEPman Certificate Master.
2. Seleccione Solicitar certificado en la izquierda
3. Seleccione (Web) Server en la parte superior
4. Seleccione Formulario
5. Introduzca todos los Nombres alternativos del sujeto (SANs) para los que el certificado debe ser válido, separados por comas, puntos y coma o saltos de línea. Genere un certificado de servidor como se describe aquí y proporcione cualquier FQDN que desee. Recomendamos adaptar el SAN del certificado de servidor predeterminado, por ejemplo radsec-<your RADIUSaaS instance name>.radius-as-a-service.com.
6. Establezca el Formato del archivo de descarga en PEM
7. Seleccione Incluir cadena de certificados y descargue el certificado.
8. Asegúrese de incluir tanto la autenticación de servidor como la de cliente para el EKU.
9. Envíe la solicitud para descargar el nuevo certificado de servidor.

Importante: Tome nota temporal de la contraseña, ya que no se puede recuperar de Certificate Master.

Cargue el nuevo certificado de servidor en RADIUSaaS

Para agregar el certificado de servidor creado en los pasos anteriores, vaya a instancia de RADIUSaaS > Configuración > Configuración del servidor > Agregar, luego

1. Elija Certificado codificado en PEM o PKCS#12 (Si seleccionó PKCS#12 en el paso 5, esto contiene tanto la clave pública como la privada)
2. Arrastre y suelte su archivo de certificado o haga clic para buscarlo
3. Introduzca la contraseña de su Clave privada
4. Haga clic en Guardar

Tenga en cuenta: de forma predeterminada, SCEPman Certificate Master emite certificados válidos durante 730 días. Si desea cambiar esto, consulte la documentación.

Activación del certificado

Asegúrese de supervisar la caducidad de su certificado de servidor y renovarlo a tiempo para evitar interrupciones del servicio.

Como los certificados caducan de vez en cuando o cambia su preferencia sobre qué certificados le gustaría usar, es importante que pueda controlar el certificado que está usando su servidor. La Activa columna muestra el certificado que su servidor está usando actualmente. Para cambiar el certificado que está usando su servidor, expanda la fila del certificado que desea elegir y haga clic en Activar.

Descargar

Para descargar su certificado de servidor, tiene dos opciones:

1. Haga clic en Descargar certificado de CA en la parte superior. Esto descargará directamente la CA raíz de confianza del certificado de servidor activo .
2. Haga clic en el icono de descarga de la fila correspondiente.

Opción 2 abrirá un diálogo que muestra la ruta completa del certificado. El certificado raíz siempre estará marcado en verde.

Mostrando el certificado raíz en verde

Para ambas opciones, el certificado raíz descargado está codificado en base64 (PEM). En caso de que su dispositivo (por ejemplo, un controlador WiFi) necesite una codificación binaria (DER), puede convertirlo usando OpenSSL:

openssl x509 -inform pem -in <DOWNLOADED_FILE> -outform der -out <CONVERTED_FILE>

Eliminar

Para eliminar un certificado, expanda la fila correspondiente, haga clic en Eliminar y confirme su elección.

Caducidad del certificado

No deje que caduque el certificado del servidor RADIUS. Romperá la autenticación.

Los certificados caducan de vez en cuando. Cinco meses antes de que su certificado vaya a caducar, su panel le dará una pista mostrando un signo de advertencia junto a él.

Captura de pantalla que muestra la caducidad del certificado

Si el triángulo se muestra junto al certificado activo del servidor RADIUS, siga esta guía para actualizarlo:

Renovación del certificado del servidor