> 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/fr/portail-dadministration/settings/settings-server.md). # Paramètres du serveur Les paramètres du serveur sont disponibles à l'adresse https\://YOURNAME.radius-as-a-service.com/settings/server ## Ports et adresses IP ### Vue d’ensemble RADIUSaaS exploite un service RadSec pour fournir une authentification sécurisée dans le cloud à ses utilisateurs. De plus, pour les clients qui ne peuvent pas utiliser RadSec dans leur environnement réseau, par exemple en raison de limitations matérielles et logicielles, RADIUSaaS fournit des proxies RADIUS, qui assurent la conversion du protocole de RADIUS vers RadSec. Les services RadSec et RADIUS offrent tous deux une adresse IP publique qui permet à vos équipements réseau et à vos services de communiquer avec notre service depuis n'importe où via Internet. Ces services fonctionnent sur leurs ports enregistrés uniques. ## RadSec / TCP

#### **DNS RadSec** L'entrée DNS par laquelle le service RadSec peut être atteint. #### **Adresses IP du serveur** Voici l'adresse IP publique du service RadSec. #### **Ports RadSec** Voici le port enregistré pour RadSec : 2083 ### Basculement et redondance Dans les cas où les clients ont besoin de niveaux de redondance plus élevés, plusieurs points de terminaison RadSec peuvent être configurés pour votre instance, fournissant des adresses IP supplémentaires. Veuillez noter qu'il existe un coût supplémentaire pour ce service.

{% hint style="info" %} Il est important de noter que RADIUSaaS **ne fournit PAS de basculement** entre les points de terminaison RadSec. À la place, ce basculement est généralement implémenté sur votre équipement réseau, comme illustré dans l'exemple ci-dessous utilisant Meraki. Il est recommandé de configurer votre scénario de basculement à l'aide d'adresses IP plutôt que du DNS, pour une meilleure visibilité et une moindre dépendance à un service supplémentaire (DNS). {% endhint %} Dans cette configuration, les deux adresses IP RadSec sont listées par ordre de préférence. Lorsque Meraki ne parvient pas à atteindre l'une des adresses IP, il essaiera généralement deux fois de plus, puis passera à la suivante. Pour plus d'informations concernant la capacité de basculement de votre système Meraki (ou autre), veuillez consulter vos propres ressources.

Affichage de plusieurs serveurs RadSec par ordre de priorité (Meraki).

## Paramètres RadSec ### Version maximale de TLS Ce paramètre contrôle la version maximale de TLS utilisée pour votre **interface RadSec**. La version minimale est fixée à 1.2, la version maximale par défaut est définie sur 1.3. TLS 1.3 offre plusieurs avantages par rapport à 1.2, notamment le mécanisme d'authentification post-handshake, qui permet de demander des informations d'identification supplémentaires avant de terminer la négociation. Ceci est important pour les vérifications de certificats RadSec évoquées juste après. ### Version maximale de TLS EAP Ce paramètre contrôle la version maximale de TLS utilisée avec EAP lorsque vos terminaux s'authentifient auprès de votre instance RADIUSaaS à l'aide d'un certificat (EAP-TLS) ou [des identifiants nom d'utilisateur/mot de passe](/fr/portail-dadministration/utilisateurs/users.md#protocols). Pour tous les systèmes d'exploitation modernes, **TLS 1.3 est la valeur par défaut recommandée**. Cependant, certaines versions (anciennes) de Windows 10/11 annonçaient la prise en charge de TLS 1.3 pour EAP-TLS avec une implémentation non conforme. Si des clients Windows sur les versions concernées rencontrent des problèmes de connectivité, limitez la version du protocole négociée à TLS 1.2 pour une compatibilité plus large. ### Vérification de révocation pour les certificats RadSec {% hint style="info" %} Ce paramètre détermine si une vérification de révocation doit être effectuée pour toutes les connexions RadSec. La méthode de vérification de la révocation diffère légèrement de celle utilisée pour les certificats d'authentification client. {% endhint %} Pour un fonctionnement correct de RadSec, des équipements réseau tels que les points d'accès, les commutateurs et les serveurs VPN établissent une connexion protégée par TLS au serveur RadSec. Les déploiements RadSec utilisent généralement le TLS mutuel (mTLS), où les deux pairs s'authentifient mutuellement à l'aide de certificats X.509 pendant la négociation TLS. L'implémentation de RADIUSaaS impose le mTLS. Pour déterminer la validité et l'état de révocation d'un certificat client RadSec, le certificat doit être présenté par le client dans le cadre du processus d'authentification TLS. Ce n'est qu'après réception du certificat que des vérifications de révocation (par exemple via CRL ou OCSP) peuvent être effectuées. #### **TLS 1.2** TLS 1.2 prend en charge l'authentification TLS mutuelle lors de la négociation initiale à l'aide de `CertificateRequest`, `Certificate`, et `CertificateVerify` messages. Lorsque l'authentification client est requise et correctement appliquée, le certificat client RadSec est présenté, validé et vérifié quant à sa révocation avant l'établissement de la session TLS et avant tout échange de trafic RADIUS. \ Cependant, TLS 1.2 autorise également l'authentification client facultative et prend en charge la renégociation. En conséquence, certaines implémentations clientes RadSec peuvent terminer la négociation initiale sans présenter de certificat client. Ce comportement est spécifique à l'implémentation et n'est pas une limitation du protocole TLS 1.2. {% hint style="info" %} Pour atténuer le comportement ci-dessus, le **Vérification de révocation pour les certificats RadSec** paramètre est désactivé lorsque la version maximale de TLS est définie sur 1.2. Veuillez noter que vous pouvez le réactiver manuellement plus tard. {% endhint %} #### **TLS 1.3** TLS 1.3 fournit un modèle plus déterministe et plus rationalisé pour l'authentification TLS mutuelle. Lorsque l'authentification client est demandée, le certificat client RadSec est échangé dans le cadre de la négociation initiale et validé avant l'établissement de la connexion TLS.\ Cela permet au serveur RadSec de vérifier immédiatement le certificat client, y compris son état de révocation, et d'échouer la négociation si le certificat est invalide ou révoqué. Par conséquent, TLS 1.3 permet une application plus stricte et plus prévisible de l'authentification TLS mutuelle pour les connexions RadSec. {% hint style="info" %} Le **Vérification de révocation pour les certificats RadSec** Le paramètre est automatiquement activé lorsque la version maximale de TLS est définie sur 1.3. {% endhint %}

## RADIUS / UDP Cette section est disponible lorsque vous avez configuré au moins un [Proxy RADIUS](/fr/portail-dadministration/settings/settings-proxy.md). Pour chaque proxy, une adresse IP publique distincte est disponible. Les adresses IP publiques de cette section prennent en charge uniquement le protocole RADIUS et écoutent donc sur les ports 1812/1813.

### **Adresses IP et emplacement du serveur** {% hint style="warning" %} Ces adresses IP n'écoutent que sur [RADIUS](/fr/overview.md#what-is-radius) les ports UDP 1812/1813. {% endhint %} Géolocalisation du ou des proxies RADIUS ainsi que de la ou des adresses IP publiques correspondantes. ### **Secrets partagés** Le secret partagé pour le proxy RADIUS correspondant. Par défaut, tous les proxies RADIUS sont initialisés avec le même secret partagé.

Affichage du changement des secrets partagés par proxy

### **Ports** Cette section affiche les ports standard des services d'authentification RADIUS (1812) et de comptabilisation RADIUS (1813). ### **Basculement et redondance** #### Redondance des proxies Notez qu'un seul proxy RADIUSaaS n'offre pas de redondance. Pour garantir la redondance, configurez plusieurs proxies RADIUSaaS comme décrit [ici](/fr/portail-dadministration/settings/settings-proxy.md#load-balancing). #### Redondance du service RadSec pour les proxies Lorsque vous utilisez RADIUSaaS avec plusieurs instances RadSec, les proxies sont automatiquement configurés pour se connecter à toutes les instances RadSec disponibles. Un proxy RADIUSaaS donnera la priorité à la connexion au service RadSec régional le plus proche. Si ce service n'est pas disponible, il basculera vers un autre service RadSec disponible. ## Certificats serveur ### Customer-CA Par défaut, RADIUSaaS génère un **certificat serveur RADIUS** signé par une autorité de certification (CA) disponible sur notre service uniquement à cette fin. Nous l'appelons le **Customer-CA**. La CA client est unique pour chaque client. Pour créer votre CA client, suivez ces étapes simples : 1. Accédez à **Paramètres** > **Paramètres du serveur** 2. Cliquez sur **Ajouter** 3. Choisissez **Laissez RaaS créer une CA pour vous** 4. Cliquez sur **Enregistrer** 5. Après la création, vous verrez un nouveau certificat disponible dans Certificats serveur

### Apportez votre propre certificat Si vous ne souhaitez pas utiliser la **CA client**, vous pouvez téléverser jusqu'à deux de vos propres certificats. #### certificat serveur émis par SCEPman Veuillez suivre ces étapes pour utiliser SCEPman Certificate Master afin de générer un nouveau certificat serveur : 1. Accédez au portail web de SCEPman Certificate Master. 2. Sélectionnez Request Certificate à gauche 3. Sélectionnez **Serveur (Web)** en haut 4. Sélectionnez **Formulaire** 5. Entrez tous les noms alternatifs du sujet (SAN) pour lesquels le certificat doit être valide, séparés par des virgules, des points-virgules ou des retours à la ligne. Générez un certificat serveur comme décrit [ici](https://docs.scepman.com/certificate-deployment/certificate-master/tls-server-certificate-pkcs-12) et fournissez le FQDN de votre choix. Nous recommandons d'adapter le SAN du certificat serveur par défaut, par ex. `radsec-.radius-as-a-service.com`. 6. Définissez le **format du fichier de téléchargement** sur **PEM** 7. Sélectionnez **Inclure la chaîne de certificats** et téléchargez le certificat. 8. Assurez-vous d'inclure **à la fois l'authentification serveur et client** pour l'EKU. 9. **Soumettre** la demande pour télécharger le nouveau certificat serveur. {% hint style="warning" %} **Important**: Notez temporairement le mot de passe, car il ne peut pas être récupéré depuis Certificate Master. {% endhint %}

### Téléversez le nouveau certificat serveur dans **RADIUSaaS** Pour ajouter votre certificat serveur créé aux étapes ci-dessus, accédez à **instance RADIUSaaS** > **Paramètres** > **Paramètres du serveur** > **Ajouter,** puis 1. Choisissez **Certificat encodé PEM ou PKCS#12** (Si vous avez sélectionné PKCS#12 à l'étape 5, il contient à la fois la clé publique et la clé privée) 2. Glissez-déposez votre fichier de certificat ou cliquez pour le parcourir 3. Entrez le mot de passe de votre **clé privée** 4. Cliquez sur **Enregistrer**

{% hint style="info" %} Veuillez noter : par défaut, SCEPman Certificate Master émet des certificats valables 730 jours. Si vous souhaitez modifier cela, veuillez vous reporter à la [documentation](https://docs.scepman.com/advanced-configuration/application-settings/certificates#appconfig-validityperioddays). {% endhint %} ### Activation du certificat {% hint style="warning" %} Veillez à surveiller l'expiration de votre certificat serveur et à le renouveler à temps pour éviter toute interruption de service. {% endhint %} Comme les certificats expirent de temps à autre ou que vos préférences quant aux certificats que vous souhaitez utiliser changent, il est important que vous puissiez contrôler le certificat utilisé par votre serveur. La **Actif** colonne vous indique le certificat que votre serveur utilise actuellement. Pour changer le certificat utilisé par votre serveur, développez la ligne du certificat que vous souhaitez choisir et cliquez sur **Activer**. ### Télécharger Pour télécharger votre **certificat serveur,** vous avez deux options : 1. Cliquez sur **Télécharger le certificat de l'AC** en haut. Cela téléchargera directement l' **AC racine de confiance** du certificat serveur actuellement **actif** . 2. Cliquez sur l' **icône de téléchargement** dans la ligne correspondante.

**Option 2** ouvrira une boîte de dialogue affichant le chemin complet du certificat. Le **certificat racine** sera toujours marqué en vert.

Dans les deux cas, le certificat racine téléchargé est encodé en base64 (PEM). Si votre appareil (par ex. un contrôleur Wi-Fi) a besoin d'un codage binaire (DER), vous pouvez le convertir à l'aide de [OpenSSL](https://openssl.org/): ```sh openssl x509 -inform pem -in -outform der -out ``` ### Supprimer Pour supprimer un certificat, développez la ligne correspondante, cliquez sur **Supprimer** et confirmez votre choix. ### Expiration du certificat {% hint style="danger" %} Ne laissez pas expirer le certificat serveur RADIUS. Cela rompra l'authentification. {% endhint %} Les certificats expirent de temps à autre. Cinq mois avant l'expiration de votre certificat, votre tableau de bord vous en avertira en affichant un symbole d'avertissement à côté. ![Capture d'écran montrant l'expiration du certificat](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/vyZwJeKE1HD6XpnxGymy/image.png) Si le triangle s'affiche à côté du certificat serveur RADIUS actif, suivez ce guide pour le mettre à jour : {% content-ref url="/pages/5cbe9500d96d18d126f16110616ef67537594b26" %} [Renouvellement du certificat serveur](/fr/configuration/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/fr/portail-dadministration/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.