> 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/es/portal-de-administracion/settings/settings-server.md).
# 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 para 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 del protocolo de RADIUS a RadSec.
Tanto el servicio RadSec como el servicio RADIUS ofrecen direcciones IP públicas que permiten que sus dispositivos y servicios de red se comuniquen con nuestro servicio desde cualquier lugar a través de Internet. Estos servicios operan en sus puertos registrados exclusivos.
## RadSec / TCP
#### **DNS de RadSec**
La entrada DNS a través de la cual se puede الوصول 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 varios puntos de conexión RadSec para su instancia, proporcionando direcciones IP adicionales. Tenga en cuenta que hay un coste adicional por este servicio.
{% hint style="info" %}
Es importante señalar que RADIUSaaS **NO proporciona conmutación por error** entre puntos de conexión RadSec. En su lugar, esta conmutación por error suele implementarse 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 una menor dependencia de un servicio adicional (DNS).
{% endhint %}
En esta configuración, las dos direcciones IP de RadSec se enumeran en orden de preferencia. Cuando Meraki no puede alcanzar 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 se establece en 1.3.
TLS 1.3 ofrece varias ventajas frente a 1.2, incluido el mecanismo de autenticación posterior al intercambio, que permite solicitar credenciales adicionales antes de completar el intercambio. Esto es importante para las comprobaciones de verificación de la configuración de certificados RadSec que se comentan a continuación.
### Versión máxima de TLS EAP
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 utilizando un certificado (EAP-TLS) o [credenciales de nombre de usuario/contraseña](/es/portal-de-administracion/usuarios/users.md#protocols).
Para todos los sistemas operativos modernos, **TLS 1.3 es el valor predeterminado recomendado**. Sin embargo, ciertas compilaciones 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 las compilaciones afectadas presentan problemas de conectividad, limite la versión del protocolo negociado a TLS 1.2 para una mayor compatibilidad.
### Comprobación de revocación de certificados RadSec
{% hint style="info" %}
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 que se utiliza para los certificados de autenticación de cliente.
{% endhint %}
Para un funcionamiento correcto de RadSec, 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), en el que ambos pares se autentican entre sí usando certificados X.509 durante el intercambio de TLS. La implementación de RADIUSaaS aplica mTLS.
Para determinar la validez y el estado de revocación de un certificado de cliente RadSec, el certificado debe ser presentado por el cliente 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 de TLS durante el intercambio inicial usando los `CertificateRequest`, `Certificate`, y `CertificateVerify` mensajes. Cuando se requiere autenticación de 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 la autenticación opcional de cliente y admite la renegociación. Como resultado, algunas implementaciones de cliente RadSec pueden completar el intercambio 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.
{% hint style="info" %}
Para mitigar el comportamiento anterior, la **Comprobación de revocación de certificados RadSec** configuración se desactiva cuando la versión máxima de TLS se establece en 1.2. Tenga en cuenta que puede volver a activarla manualmente más tarde.
{% endhint %}
#### **TLS 1.3**
TLS 1.3 proporciona un modelo más determinista y simplificado para la autenticación mutua de TLS. Cuando se solicita autenticación de cliente, el certificado de cliente RadSec se intercambia como parte del intercambio inicial y se valida antes de que se establezca la conexión TLS.\
Esto permite al servidor RadSec verificar inmediatamente el certificado de cliente, incluido su estado de revocación, y fallar el intercambio 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 de TLS para las conexiones RadSec.
{% hint style="info" %}
El **Comprobación de revocación de certificados RadSec** se habilita automáticamente cuando la versión máxima de TLS se establece en 1.3.
{% endhint %}
## RADIUS / UDP
Esta sección está disponible cuando ha configurado al menos un [Proxy RADIUS](/es/portal-de-administracion/settings/settings-proxy.md). 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**
{% hint style="warning" %}
Estas direcciones IP solo escuchan en [RADIUS](/es/overview.md#what-is-radius) los puertos UDP 1812/1813.
{% endhint %}
Geolocalización de los Proxies RADIUS, así como de las respectivas direcciones IP públicas.
### **Secretos compartidos**
El secreto compartido para el respectivo Proxy RADIUS. 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 de proxy
Tenga en cuenta que un solo Proxy de RADIUSaaS no proporciona redundancia. Para garantizar la redundancia, configure varios Proxies de RADIUSaaS como se describe [aquí](/es/portal-de-administracion/settings/settings-proxy.md#load-balancing).
#### Redundancia del servicio RadSec para Proxies
Al usar RADIUSaaS con varias 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 **Permita que RaaS cree una CA para usted**
4. Haga clic en **Guardar**
5. Después de la creación, verá disponible un nuevo certificado en Certificados del servidor
### Traiga su propio certificado
En caso de que no desee usar la **CA del cliente**, 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 Request Certificate en el panel izquierdo
3. Seleccione **(Servidor web)** en la parte superior
4. Seleccione **Formulario**
5. Introduzca todos los nombres alternativos del sujeto (SAN) para los que el certificado será válido, separados por comas, punto y coma o saltos de línea. Genere un certificado de servidor como se describe [aquí](https://docs.scepman.com/certificate-deployment/certificate-master/tls-server-certificate-pkcs-12) y proporcione cualquier FQDN que desee. Recomendamos adaptar el SAN del certificado de servidor predeterminado, por ejemplo `radsec-.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.
{% hint style="warning" %}
**Importante**: Tome nota temporal de la contraseña, ya que no puede recuperarse de Certificate Master.
{% endhint %}
### Cargue el nuevo certificado de servidor en **RADIUSaaS**
Para añadir el certificado de servidor creado en los pasos anteriores, vaya a **la instancia de RADIUSaaS** > **Configuración** > **Configuración del servidor** > **Añadir,** 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 el archivo de su certificado o haga clic para buscarlo
3. Introduzca la contraseña de su **Clave privada**
4. Haga clic en **Guardar**
{% hint style="info" %}
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](https://docs.scepman.com/advanced-configuration/application-settings/certificates#appconfig-validityperioddays).
{% endhint %}
### Activación del certificado
{% hint style="warning" %}
Asegúrese de supervisar la caducidad de su certificado de servidor y renovarlo a tiempo para evitar interrupciones del servicio.
{% endhint %}
Como los certificados caducan de vez en cuando o cambia su preferencia sobre qué certificados desea usar, es importante que pueda controlar el certificado que está usando su servidor. La **Activo** columna muestra el certificado que su servidor está usando actualmente. Para cambiar el certificado que usa 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 actualmente **activo** certificado de servidor.
2. Haga clic en el **icono de descarga** en la fila correspondiente.
**Opción 2** abrirá un diálogo que mostrará la ruta completa del certificado. El **certificado raíz** siempre se marcará 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](https://openssl.org/):
```sh
openssl x509 -inform pem -in -outform der -out
```
### Eliminar
Para eliminar un certificado, expanda la fila correspondiente, haga clic en **Eliminar** y confirme su elección.
### Caducidad del certificado
{% hint style="danger" %}
No deje que caduque el certificado del servidor RADIUS. Romperá la autenticación.
{% endhint %}
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.
Si el triángulo se muestra junto al certificado de servidor RADIUS activo, siga esta guía para actualizarlo:
{% content-ref url="/pages/963c6537e7c0ecd1a0a4fe92bb8d24de7c2badd3" %}
[Renovación del certificado del servidor](/es/configuracion/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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.radiusaas.com/es/portal-de-administracion/settings/settings-server.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
