> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/powershell-universal/fr/config/hosting.md).

# Hébergement

Hébergez PowerShell Universal en tant que service Windows, dans IIS, dans Azure ou de façon autonome, et configurez les ports Kestrel, les certificats HTTPS et les en-têtes de sécurité.

Vous pouvez héberger PowerShell Universal en tant que service Windows, dans IIS, en tant qu'application web Azure ou simplement en tant qu'application autonome. Si vous fonctionnez sous Windows, nous suggérons soit un service Windows, soit IIS.

## Hébergement en tant que service Windows

Pour héberger en tant que service Windows, vous pouvez télécharger et installer le MSI de PowerShell Universal. Le MSI installera automatiquement le service PowerShell Universal et le démarrera. Les tâches s'exécuteront sous le compte système par défaut, mais vous pouvez configurer le service pour qu'il s'exécute sous un autre compte après l'installation.

Une fois l'installation du MSI terminée, votre navigateur web par défaut s'ouvrira à l'adresse <http://localhost:5000> pour la connexion. Les identifiants de connexion par défaut sont Admin et n'importe quel mot de passe.

### Configurer un service Windows manuellement

Vous n'avez pas besoin d'utiliser le MSI pour configurer Universal en tant que service Windows. Vous pouvez également le faire manuellement avec le script PowerShell suivant.

```powershell
New-Service -Name "PowerShellUniversal" -BinaryPathName "Universal.Server.exe --service" -Description "PowerShell Universal server service." -DisplayName "PowerShell Universal" -StartupType Automatic
Start-Service PowerShellUniversal
```

## Hébergement dans Azure

Consultez notre [guide d'hébergement Azure](/powershell-universal/fr/config/hosting/azure.md).

## Hébergement manuel

Vous pouvez également héberger le serveur Universal en tant qu'application autonome. Exécutez simplement `Universal.Server.exe` à partir du répertoire binaire pour utiliser l'[implémentation du serveur web Kestrel dans ASP.NET Core](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1) afin de démarrer le serveur web.

## Configuration du serveur web

{% hint style="info" %}
Cette section s'applique à Universal lorsqu'il est hébergé en dehors d'IIS.
{% endhint %}

### Définir le port et l'adresse d'écoute

Vous pouvez définir le port du serveur Universal en modifiant le fichier `appsettings.json`. Nous recommandons de créer un fichier `appsettings.json` dans le [dossier de configuration par défaut](/powershell-universal/fr/readme.md).

**Windows**

`%ProgramData%\PowerShellUniversal`

**Linux**

`%HOME%/.PowerShellUniversal`

Pour définir le port, modifiez la section des terminaux Kestrel du fichier `appsettings.json`. Par défaut, la configuration est définie pour écouter sur le port 5000 et sur n'importe quelle adresse.

```javascript
    "Kestrel": {
    "Endpoints": {
      "HTTP": {
        "Url": "http://*:5000"
      }
    }
  },
```

### Configurer HTTPS

Pour configurer HTTPS, vous pouvez ajuster le fichier `appsettings.json` afin d'utiliser un certificat et un port particuliers. La configuration ci-dessous utilise le fichier `testCert.pfx` et `testPassword`, et écoute sur le port 5463.

#### Certificats PFX

```javascript
{
  "Kestrel": {
    "Endpoints": {
       "HTTP": { "Url": "http://*:5000" },
           "HTTPS": {
              "Url": "https://*:5463",
              "Certificate": {
                  "Path": "testCert.pfx",
                  "Password": "testPassword"
              }
          }
    }
}
```

#### Magasin de certificats

Pour configurer un certificat dans un emplacement et un magasin particuliers, vous pouvez utiliser une configuration comme celle-ci. Lorsque vous sélectionnez le certificat par nom de sujet, assurez-vous d'utiliser le nom commun sans le préfixe `CN=`.

```javascript
{
  "Kestrel": {
    "Endpoints": {
      "HTTPS": {
         "Url": "https://*:443",
           "Certificate": {
             "Subject": "windows-server.ironman.local",
             "Store": "My",
             "Location": "LocalMachine",
             "AllowInvalid": "true"
           }
      }
   }
}
```

L'emplacement peut être soit `CurrentUser`, soit `LocalMachine`.

#### Magasin de certificats par empreinte

Vous pouvez utiliser l'empreinte plutôt que le sujet dans la version 3.4 et les versions ultérieures.

```powershell
{
  "Kestrel": {
    "Endpoints": {
      "HTTPS": {
         "Url": "https://*:443",
           "Certificate": {
             "Thumbprint": "SDFSDFSDFSDFSDFSDFSDFFSD",
             "Store": "My",
             "Location": "LocalMachine",
             "AllowInvalid": "true"
            }
         }
      }
   }
}
```

#### Certificats PEM et clé

Certains fournisseurs, comme Let's Encrypt et GoDaddy, émettent des certificats sous forme de fichiers texte PEM et clé. Vous pouvez utiliser ces types de certificats directement avec le serveur web Kestrel. Vous devrez spécifier la section `HttpsFromPem` dans les `Endpoints` de Kestrel.

```json
{
  "Kestrel": {
    "Endpoints": {
      "HTTP": {
        "Url": "http://*:5000"
      },
      "HttpsFromPem": {
        "Url": "https://*:5001",
        "Certificate": {
          "Path": "C:\\Users\\adamr\\Desktop\\cert.pem",
          "KeyPath": "C:\\Users\\adamr\\Desktop\\key.pem"
        }
      }
    },
    "RedirectToHttps": "true"
  },
}
```

#### Permissions

Sous Windows, l'utilisateur qui exécute le service PowerShell Universal devra avoir accès au certificat afin de fournir correctement la prise en charge HTTPS. Cela pose généralement problème si le service utilise un compte de service géré de groupe. Vous pouvez utiliser le script PowerShell suivant pour accorder les permissions appropriées.

```powershell
$thumbprint = "<<THUMBPRINT>>"
$certPath = "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys"
$cert = Get-ChildItem -Path Cert:\LocalMachine\My\$thumbprint
$acl = Get-Acl -Path (Join-Path $certPath $cert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName)
$gmSaAccount = "Domain\<<GMSA_Account>>$"
$accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule($gmSaAccount, "Read", "Allow")
$acl.SetAccessRule($accessRule)
Set-Acl -Path (Join-Path $certPath $cert.PrivateKey.CspKeyContainerInfo.UniqueKeyContainerName) -AclObject $acl
```

### Protocole

Par défaut, Universal écoute sur HTTP1 et HTTP2. Vous pouvez ajuster les protocoles écoutés par le serveur en définissant la propriété Protocols. Par exemple, vous pouvez définir spécifiquement la prise en charge de HTTP1 et HTTP2 avec le paramètre suivant.

```javascript
"Kestrel": {
  "Endpoints": {
    "HTTP": {
      "Url": "http://*:5000",
      "Protocols": "Http1AndHttp2"
    }
  },
  "RedirectToHttps": "false"
},
```

Certaines versions de Windows Server (comme 2012R2) ne prennent pas en charge HTTP2. Pour désactiver la prise en charge de HTTP2, configurez l'écouteur pour qu'il écoute uniquement sur HTTP1.

```javascript
"Kestrel": {
  "Endpoints": {
    "HTTP": {
      "Url": "http://*:5000",
      "Protocols": "Http1"
    }
  },
  "RedirectToHttps": "false"
},
```

Pour un ensemble complet d'options d'écoute, vous pouvez consulter la [documentation ASP.NET Core](https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1#listenoptionsusehttps).

### En-têtes de sécurité

Les organisations peuvent exiger que PowerShell Universal fournisse certains en-têtes de sécurité dans les réponses HTTP provenant du serveur, ce qui peut inclure :

* Strict-Transport-Security
* Content-Security-Policy
* X-Frame-Options
* X-Content-Type-Options
* X-XSS-Protection
* Referrer-Policy

Vous pouvez utiliser la section Kestrel \ Headers pour définir ces valeurs.

```json
{
    "Kestrel" : {
       "Headers": {
          "X-Content-Type-Options": "nosniff",
          "Content-Security-Policy": "default-src 'self';",
          "X-XSS-Protection": "block",
          "X-Frame-Options": "DENY"
       }
    }
}
```

{% hint style="warning" %}
Soyez prudent lors de la configuration de ces en-têtes, car ils modifient le comportement de chaque requête web retournée par PowerShell Universal.
{% endhint %}

## Exemple : certificat auto-signé

Dans cet exemple, nous montrerons comment créer un certificat auto-signé et l'utiliser avec PowerShell Universal.

Tout d'abord, créez un certificat auto-signé et stockez-le dans le magasin de votre machine locale. Vous devrez exécuter PowerShell en tant qu'administrateur. Le magasin de la machine locale est requis, car PowerShell Universal peut s'exécuter en tant que service et non sous votre compte.

```powershell
New-SelfSignedCertificate -DnsName localhost -CertStoreLocation cert:\LocalMachine\My
```

Ensuite, vous devrez configurer PowerShell Universal pour qu'il utilise le certificat. Cela peut se faire en modifiant ou en créant le fichier `appsettings.json` dans `%ProgramData%\PowerShellUniversal`. Ce fichier devrait déjà exister si vous avez effectué l'installation avec l'installateur MSI. Le contenu du fichier doit inclure le nom DNS de votre certificat et l'emplacement.

Pour les certificats auto-signés, vous devrez inclure l'option `AllowInvalid`.

```json
{
  "Kestrel": {
    "Endpoints": {
      "HTTPS": {
         "Url": "https://*:443",
           "Certificate": {
             "Subject": "localhost",
             "Store": "My",
             "Location": "LocalMachine",
             "AllowInvalid": "true"
           }
      }
   }
}
```

Une fois que vous avez mis à jour le fichier `appsettings.json`, redémarrez le service PowerShell Universal. Vous devriez maintenant pouvoir accéder à votre site web PowerShell Universal à l'adresse `https://localhost`.

### Voir aussi

* [Devolutions Academy – Créer un terminal de base](https://academy.devolutions.net/student/activity/3466014-creating-a-basic-endpoint)


---

# 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.devolutions.net/powershell-universal/fr/config/hosting.md?ask=<question>&goal=<endgoal>
```

`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.
