> 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 ## Ports & 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 proxys 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** Il s’agit de l’adresse IP publique du service RadSec. #### **Ports RadSec** Il s’agit du 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 que ce service entraîne un coût supplémentaire.
{% 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 mis en œuvre 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 de DNS afin d’obtenir une meilleure visibilité et de moins dépendre d’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 essaie généralement deux fois de plus puis passe à 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 TLS maximale Ce paramètre contrôle la version TLS maximale pour votre **interface RadSec**. La version minimale est fixée à 1.2, la version maximale par défaut est définie à 1.3. TLS 1.3 offre plusieurs avantages par rapport à 1.2, notamment le mécanisme d’authentification après le handshake, qui permet de demander des informations d’identification supplémentaires avant de terminer le handshake. Cela est important pour le paramètre de vérification de révocation des certificats RadSec évoqué ensuite. ### Version TLS maximale pour EAP Ce paramètre contrôle la version TLS maximale utilisée avec EAP lorsque vos points de terminaison s’authentifient auprès de votre instance RADIUSaaS à l’aide d’un certificat (EAP-TLS) ou [d’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 affichaient 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 de 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 des points d’accès, des commutateurs et des serveurs VPN établissent une connexion protégée par TLS avec le 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 le handshake TLS. L’implémentation RADIUSaaS impose 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 les 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 du handshake initial à l’aide des `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é pour la révocation avant l’établissement de la session TLS et avant tout échange de trafic RADIUS. \ Cependant, TLS 1.2 autorise également une authentification client facultative et prend en charge la renégociation. Par conséquent, certaines implémentations cliente RadSec peuvent terminer le handshake initial sans présenter de certificat client. Ce comportement est spécifique à l’implémentation et ne constitue 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 TLS maximale est définie sur 1.2. Veuillez noter que vous pouvez le réactiver manuellement plus tard. {% endhint %} #### **TLS 1.3** TLS 1.3 offre 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 du handshake initial 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 le handshake si le certificat est invalide ou révoqué. En conséquence, 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** paramètre est automatiquement activé lorsque la version TLS maximale 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 du serveur et emplacement** {% hint style="warning" %} Ces adresses IP n’écoutent que sur [RADIUS](/fr/overview.md#what-is-radius) sur les ports UDP 1812/1813. {% endhint %} Géolocalisation du ou des proxys RADIUS, ainsi que de l’adresse ou des adresses IP publiques correspondantes. ### **Secrets partagés** Le secret partagé pour le proxy RADIUS correspondant. Par défaut, tous les proxys RADIUS sont initialisés avec le même secret partagé.

Affichage de la modification des secrets partagés par proxy

### **Ports** Cette section affiche les ports standard pour les services d’authentification RADIUS (1812) et de comptabilisation RADIUS (1813). ### **Basculement et redondance** #### Redondance des proxys Notez qu’un seul proxy RADIUSaaS ne fournit pas de redondance. Pour garantir la redondance, configurez plusieurs proxys RADIUSaaS comme décrit [ici](/fr/portail-dadministration/settings/settings-proxy.md#load-balancing). #### Redondance du service RadSec pour les proxys Lors de l’utilisation de RADIUSaaS avec plusieurs instances RadSec, les proxys 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 de serveur ### Customer-CA Par défaut, RADIUSaaS génère un **certificat de serveur RADIUS** signé par une autorité de certification (CA) disponible sur notre service uniquement dans ce but précis. Nous l’appelons la **Customer-CA**. La Customer-CA est unique pour chaque client. Pour créer votre Customer-CA, 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 sous Certificats de serveur
### Apportez votre propre certificat Au cas où vous ne souhaiteriez pas utiliser la **Customer CA**, vous pouvez téléverser jusqu’à deux de vos propres certificats. #### certificat de serveur émis par SCEPman Veuillez suivre ces étapes pour utiliser SCEPman Certificate Master afin de générer un nouveau certificat de serveur : 1. Accédez au portail web de SCEPman Certificate Master. 2. Sélectionnez Request Certificate sur la gauche 3. Sélectionnez **(Web) Server** en haut 4. Sélectionnez **Form** 5. Saisissez 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 sauts de ligne. Générez un certificat de serveur comme décrit [ici](https://docs.scepman.com/certificate-deployment/certificate-master/tls-server-certificate-pkcs-12) et fournissez n’importe quel FQDN que vous souhaitez. Nous vous recommandons d’adapter le SAN du certificat de serveur par défaut, par exemple `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. Veillez à inclure **à la fois l’authentification serveur et client** pour l’EKU. 9. **Soumettez** la demande pour télécharger le nouveau certificat de 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 de serveur vers **RADIUSaaS** Pour ajouter votre certificat de serveur créé lors des é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, cela 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. Saisissez 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 consulter 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 de serveur et à le renouveler en temps voulu afin d’é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 peuvent changer, il est important que vous puissiez contrôler le certificat utilisé par votre serveur. La **Active** 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, puis cliquez sur **Activer**. ### Télécharger Pour télécharger votre **certificat de serveur,** vous avez deux options : 1. Cliquez sur **Télécharger le certificat CA** en haut. Cela téléchargera directement le **AC racine de confiance** du certificat de serveur **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.

Affichage du certificat racine en vert

Dans les deux cas, le certificat racine téléchargé est encodé en base64 (PEM). Si votre appareil (par exemple un contrôleur WiFi) nécessite un encodage 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** puis confirmez votre choix. ### Expiration du certificat {% hint style="danger" %} Ne laissez pas expirer le certificat de serveur RADIUS. Cela cassera 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é de celui-ci. ![Capture d’écran montrant l’expiration du certificat](/files/4f561f5aae7fcac9a04bd26ec59e30fae663b487) Si le triangle s’affiche à côté du certificat de 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 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/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 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.