> 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/trusted-roots.md).

# Certificats de confiance

## Types de certificats approuvés

### AC approuvées pour l'authentification du client

Les AC approuvées pour l'authentification du client établissent la confiance entre les AC qui émettent des certificats d'authentification du client pour vos appareils terminaux et RADIUSaaS.

### Certificats de connexion RadSec approuvés

RadSec fonctionne lui-même avec une authentification mutuelle par certificat (mTLS). Cela signifie que, d'une part, vos authentificateurs doivent [faire confiance à RADIUSaaS](/fr/portail-dadministration/settings/settings-server.md#server-certificates) et d'autre part RADIUSaaS doit savoir quels authentificateurs approuver afin qu'une connexion RadSec valide puisse être établie. Les certificats de connexion RadSec approuvés garantissent que RADIUSaaS ne fait confiance qu'aux authentificateurs que vous spécifiez.

## **Certificat RadSec approuvé préinstallé**

En raison de [ce qui précède](/fr/portail-dadministration/settings/trusted-roots.md#trusted-radsec-connection-certificates), vous verrez toujours au moins un certificat RadSec approuvé qui établit la confiance avec vos [proxys RADIUS](https://docs-preview.radiusaas.com/admin-portal/settings/settings-proxy) (agissant en pratique comme des clients RadSec). Pour garantir que vos proxys puissent démarrer correctement et établir une connexion à votre instance, vous ne pouvez pas le supprimer.

## Ajouter&#x20;

{% hint style="warning" %}
Si vous disposez d'une infrastructure PKI hiérarchisée (par ex. une **PKI Microsoft legacy**), veuillez envisager [ceci](#tiered-pki-hierarchy).
{% endhint %}

Pour ajouter un nouveau certificat approuvé, procédez comme suit :

1. Cliquez sur **Ajouter**
2. Sélectionnez si vous souhaitez importer le certificat approuvé&#x20;
   * depuis SCEPman (en fournissant l'URL de votre instance SCEPman), ou
   * depuis toute autre AC (en téléversant un fichier de certificat encodé PEM ou DER)
3. Sélectionnez le [type](#types-of-trusted-certificates) de certificat approuvé sous **À utiliser pour**:
   * [**Authentification du client**](#trusted-cas-for-client-authentication)
   * [**RadSec**](#trusted-radsec-connection-certificates)
   * **Les deux** (utile si la même AC émet à la fois vos certificats d'authentification du client et vos certificats client RadSec)
4. Téléversez le fichier de certificat par glisser-déposer (vous pouvez également cliquer dans la zone bleue et sélectionner votre fichier)
5. Sélectionnez l'option de vérification du certificat :
   * **Détection automatique OCSP**: RADIUSaaS tentera de déduire l'URL du répondeur OCSP à partir de l'extension Authority Information Access (AIA) du certificat client utilisée pour l'authentification réseau. Si aucune URL de répondeur OCSP n'est trouvée ou si le répondeur OCSP n'est pas disponible, RADIUSaaS considérera la [**échec tolérant** ](#ocsp-soft-fail)configuration.
   * **OCSP**: Indiquez manuellement quelle URL de répondeur OCSP sera utilisée pour tout certificat émis par l'AC approuvée. Si le répondeur OCSP n'est pas disponible, RADIUSaaS considérera la [**échec tolérant** ](#ocsp-soft-fail)configuration.
   * **CRL**: Si cette option est sélectionnée, RADIUSaaS utilise une CRL au lieu d'OCSP pour vérifier les certificats émis par cette AC. Indiquez l'encodage de la CRL (**DER** ou **PEM**) et les **points de distribution de la CRL**. RADIUSaaS vérifie la CRL en cache toutes les heures et ne télécharge une nouvelle CRL qu'une fois que son *Mise à jour suivante* est écoulée.
   * **Aucun :** Si votre AC ne prend en charge ni OCSP ni CRL, sélectionnez **Aucun** pour ignorer la vérification.
6. Cliquez sur **Enregistrer**

{% hint style="info" %}
Si votre PKI comporte une hiérarchie multiniveau (AC racine, AC intermédiaire, AC émettrice), veillez à les téléverser toutes dans le magasin de certificats approuvés de RADIUSaaS.
{% endhint %}

## Supprimer

Pour supprimer un certificat, développez la ligne correspondante, cliquez sur **Supprimer** et confirmez votre choix.&#x20;

<figure><img src="https://1168716614-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSWU1DQ4UGkqER7uGNUOm%2Fuploads%2F881Etn4X8SPLFDEUIEaz%2Fimage.png?alt=media&amp;token=1f14289f-0179-45e1-ab9f-72a39f4e2e37" alt=""><figcaption><p>Affichage de la suppression d'un certificat approuvé</p></figcaption></figure>

## Échec tolérant OCSP

Ce paramètre détermine le comportement de RADIUSaaS lorsque le répondeur OCSP de votre AC approuvée est injoignable.&#x20;

{% hint style="danger" %}
Si vous **désactivez** ce paramètre, les demandes d'authentification seront **rejetées** lorsque le répondeur OCSP de votre AC est injoignable.

Veuillez vérifier [Conséquences du mode échec souple d'OCSP](/fr/autre/faqs/consequences-du-mode-echec-souple-docsp.md) pour vous assurer que vous comprenez les implications de ce paramètre.
{% endhint %}

{% hint style="info" %}
Notez que ce paramètre est uniquement disponible lorsque **Détection automatique OCSP** ou **OCSP** est sélectionné pour la vérification des certificats.&#x20;
{% endhint %}

Par défaut, nous **recommandons d'activer l'échec tolérant OCSP** afin d'accroître la disponibilité du service en permettant d'accepter les demandes d'authentification même si le répondeur OCSP est injoignable. Avec ce **échec tolérant** mécanisme, et si OCSP n'est pas accessible, RADIUSaaS vérifiera uniquement si le certificat entrant a été signé par l'une des [AC approuvées](/fr/portail-dadministration/settings/trusted-roots.md) et traite toute [Règles](/fr/portail-dadministration/acces-et-regles/rules.md).

<figure><img src="https://1168716614-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSWU1DQ4UGkqER7uGNUOm%2Fuploads%2FOZsiGA2Azh5szBKobNvd%2Fimage.png?alt=media&amp;token=c5f34e6d-2d2d-49b3-813d-ea8165f8ce52" alt=""><figcaption></figcaption></figure>

## Hiérarchie PKI hiérarchisée

Dans un environnement d'AC hiérarchisée avec plusieurs AC émettrices configurées, les certificats émis par l'AC racine ou par toute AC émettrice obtiendront l'accès, qu'ils aient été émis par l'AC racine ou par une AC émettrice. Cela signifie qu'accorder sa confiance à la racine fera automatiquement confiance aux certificats émis par n'importe laquelle des AC émettrices. \
\
Si l'accès doit être contrôlé en fonction des AC émettrices, cela peut être réalisé en configurant [les règles correspondantes](/fr/portail-dadministration/acces-et-regles/rules.md#certificate-based-authentication).

### Considérations

Lors du téléversement des AC racine et émettrices d'une PKI hiérarchisée, veuillez tenir compte des points suivants :

* La **AC racine doit être téléversée en premier**, avant de téléverser toute AC émettrice dérivée de cette AC racine.
* Les AC racine et émettrices doivent être téléversées dans des fichiers distincts. Le téléversement de chaînes de certificats à partir d'un seul fichier peut entraîner un comportement inattendu.

## Paramètres optionnels

### ID Intune

Il est possible d'utiliser le certificat que chaque machine Windows 10 reçoit d'Intune lorsqu'elle rejoint Microsoft Entra ID (Azure AD).

{% hint style="danger" %}
Ce paramètre est facultatif. Si vous ne connaissez pas les certificats Intune, veuillez ne pas les configurer !
{% endhint %}

#### Pourquoi ne recommandons-nous pas d'utiliser les certificats Intune à des fins d'authentification ?

* Les certificats Intune ne sont pas pris en charge par Microsoft pour d'autres usages que la gestion avec Intune.
* La durée de validité des certificats Intune est de 1 an.
* Il n'existe aucun mécanisme de révocation des certificats (comme OCSP).

Au lieu d'utiliser les certificats Intune, nous recommandons d'utiliser des certificats provenant d'une PKI comme [SCEPman](https://scepman.com/).

#### Configurer les IDs Intune

{% hint style="danger" %}
Utilisez ce paramètre avec prudence. L'un des IDs suivants **doit** exister dans l'extension de certificat 1.2.840.113556.5.14. Tous les autres certificats seront **rejetés**.
{% endhint %}

Pour obtenir votre ID de Tenant Intune, procédez comme suit :&#x20;

* Appuyez sur **Windows + R** et saisissez **certlm.msc**
* Accédez à vos certificats personnels. Il y aura un certificat émis par l'un des émetteurs suivants
  * SC Online Issuing
  * MDM Device Authority&#x20;
* Ouvrez ce certificat, accédez à **Détails** et recherchez l'extension&#x20;

  1.2.840.113556.5.14
* La valeur HEX affichée est votre ID de Tenant Intune.&#x20;

**Exemple :**

L'ID de Tenant du certificat suivant est : **bb4397cb6891c64db17f766487518a6a**

![Affichage du certificat](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/idPvrWmWOtjQuz2my7Yj/image.png)

## XML

{% hint style="info" %}
Le profil XML généré par RADIUSaaS activera [la mise en cache PMK](/fr/deploiement-des-profils/microsoft-intune/wifi-profile/windows.md#fast-roaming).
{% endhint %}

Aujourd'hui, la plupart des plateformes MDM proposent une méthode guidée pour déployer des profils réseau (WiFi et LAN). Si cela n'est pas possible, ou si l'assistant ne propose que des options de configuration limitées, vous pouvez générer directement un profil XML brut sur la plateforme RADIUSaaS.

* Pour générer votre **WiFi** profil XML :&#x20;
  1. Développez le **XML** menu,&#x20;
  2. sélectionnez le protocole de sécurité souhaité (WPA2 ou WPA3),&#x20;
  3. saisissez votre **SSID,**
  4. et cliquez sur **Télécharger**.
* Pour générer votre **Filaire** profil XML, cliquez sur **Télécharger**.

<figure><img src="https://1168716614-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSWU1DQ4UGkqER7uGNUOm%2Fuploads%2FjHbQ9ohBN5f6bMmug00h%2Fimage.png?alt=media&amp;token=ea446f76-6399-41fa-b81c-88414d863dcc" alt=""><figcaption></figcaption></figure>


---

# 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/trusted-roots.md?ask=<question>&goal=<user_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.
