Cette page a été traduite par l'API Cloud Translation.

Configurer l'accès TLS à une API pour le cloud privé

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Un hôte virtuel sur Edge définit les domaines et les ports sur lesquels un proxy d'API est exposé et, par , l'URL que les applications utilisent pour accéder à un proxy d'API.

Un hôte virtuel définit également si le proxy d'API est accessible à l'aide du protocole HTTP ou par le protocole HTTPS chiffré qui utilise TLS. Lorsque vous configurez un hôte virtuel pour qu'il utilise HTTPS et TLS, vous créez un hôte virtuel sur Edge et configurez l'hôte virtuel pour utiliser un keystore et Truststore.

En savoir plus:

Remarques :

Cet article sur les produits Cloud répertorie les algorithmes de chiffrement SSL valides pour TLS 1.2: Empirical Analysis of Valid Values for VirtualHost ssl_ciphers for Testing TLS 1.2.
Depuis Edge for Private Cloud version 4.16.01, vous devez spécifier un alias d'hôte lorsque créer un hôte virtuel. Dans les versions antérieures à 4.16.01, l'alias d'hôte était facultatif.
La combinaison du nom d'alias d'hôte et du numéro de port pour l'hôte virtuel doit être unique. pour tous les hôtes virtuels dans l'installation Edge.
Si vous configurez un numéro de port (autre que 80 ou 443), il doit être unique et ne doit pas présenter une configuration de port qui se chevauche avec une un hôte existant.
Si votre installation utilise un équilibreur de charge et que celui-ci est responsable de la gestion du trafic chiffré, vous devez toujours créer l’hôte virtuel. Cependant, la configuration de votre réseau déterminera si l'hôte virtuel doit prendre en charge TLS entre l'équilibreur de charge et le routeur. Voir la section Utilisation du protocole TLS dans une installation de cloud privé.

Éléments nécessaires pour créer un hôte virtuel

Avant de créer un hôte virtuel, vous devez disposer des informations suivantes:

Nom de domaine public de l'hôte virtuel. Par exemple, vous devez savoir si le nom public est api.myCompany.com, myapi.myCompany.com, etc. Ces informations est utilisé lors de la création de l'hôte virtuel et de l'enregistrement DNS pour hôte virtuel.
Pour le protocole TLS unidirectionnel, vous devez créer un keystore contenant les éléments suivants: <ph type="x-smartling-placeholder">
- Certificat TLS : certificat signé par une autorité de certification (CA), ou une chaîne de certificats où le dernier certificat est signé par une autorité de certification.
- Clé privée : Edge prend en charge des tailles de clé jusqu'à 2 048 bits. La phrase secrète est facultative.
Pour le protocole TLS bidirectionnel, vous avez besoin d'un keystore et d'un Truststore pour contenir le certificat du client et, éventuellement, la chaîne d'autorité de certification du certificat. Vous avez besoin du Truststore, même si le certificat est signé par une autorité de certification.

Voir Keystores et Truststores pour en savoir plus sur la création de keystores et de Truststores.

Configuration d'hôte virtuel pour TLS

Pour créer un hôte virtuel, créez un objet XML qui définit l'hôte virtuel. L'objet XML suivant utilise l'élément <SSLInfo> pour définir un objet pour une configuration TLS unidirectionnelle via HTTPS:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>apiTLS.myCompany.com</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>9006</Port>
    <OCSPStapling>off</OCSPStapling>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <KeyStore>ref://myTestKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
    </SSLInfo>
</VirtualHost>

Remarque: Comme Edge était à l'origine compatible avec SSL, le tag que vous utilisez pour configurer TLS s'appelle <SSLInfo>.

Dans cet exemple, l'élément <Enabled> est défini sur "true" activer le protocole TLS unidirectionnel, et les éléments <KeyStore> et <KeyAlias> spécifient le keystore et la clé utilisées par la connexion TLS.

Pour activer le protocole TLS bidirectionnel, définissez l'élément <ClientAuthEnabled> sur true, et spécifiez un truststore à l'aide de l'<TrustStore> . Le Truststore contient le certificat du client et, éventuellement, l'autorité de certification du certificat. de la chaîne.

Décider comment spécifier le keystore et le nom du truststore dans l'hôte virtuel

Dans l'exemple d'hôte virtuel ci-dessus, vous avez spécifié le keystore à l'aide d'une référence. A "reference" est une variable qui contient le nom du keystore au lieu de spécifier le le nom du keystore.

L'avantage d'utiliser une référence est que vous pouvez modifier sa valeur keystore utilisé par l'hôte virtuel, généralement parce que le certificat du keystore actuel est arrivant à expiration dans un avenir proche. Modifier la valeur de la référence ne nécessite pas de redémarrer le routeur Edge.

Vous pouvez également utiliser un nom de keystore littéral dans l'hôte virtuel. Cependant, si jamais vous modifier l'hôte virtuel pour modifier le nom du keystore, vous devez redémarrer les routeurs Edge.

Restrictions concernant l'utilisation de références aux keystores et au truststore

Vous devez tenir compte de la restriction suivante lorsque vous utilisez des références à des keystores et Truststores:

Vous ne pouvez utiliser des références keystore et truststore dans des hôtes virtuels que si vous acceptez l'extension SNI et vous terminez SSL sur les routeurs Apigee.
Si vous avez un équilibreur de charge devant les routeurs Apigee et que vous arrêtez le protocole TLS sur le vous ne pouvez pas utiliser de références keystore et truststore dans des hôtes.

Modifier un hôte virtuel existant pour utiliser des références au keystore et au truststore

Apigee recommande vivement aux hôtes virtuels d'utiliser une référence aux keystores et aux truststores. Les références vous permettent de modifier le keystore et le truststore utilisés par l'hôte virtuel sans devoir redémarrer les routeurs Edge.

Si vos hôtes virtuels sont actuellement configurés pour utiliser le nom littéral du keystore ou vous pouvez les convertir pour utiliser des références. Pour ce faire, mettez à jour l'hôte virtuel références, puis redémarrez les routeurs Edge.

Définition des algorithmes de chiffrement et des protocoles TLS pour Edge 4.15.07 et versions antérieures

Si vous utilisez Edge version 4.15.07 ou antérieure, vous définissez le protocole et les algorithmes de chiffrement TLS. utilisé par l'hôte virtuel à l'aide des balises enfants <Ciphers> et <Protocols> du Balise <SSLInfo>. Ces tags sont décrits dans le tableau ci-dessous.

Exemple :

    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <KeyStore>myTestKeystore</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>false</ClientAuthEnabled>
            <KeyStore>myTestKeystore</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
            <Ciphers>
                <Cipher>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA</Cipher>
                <Cipher>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256</Cipher>
            </Ciphers>
            <Protocols>
                <Protocol>TLSv1.2</Protocol>
            </Protocols>
        </SSLInfo>
   </SSLInfo>

La balise <Cipher> utilise les noms Java et JSSE du chiffrement. Par exemple, pour Java 8, voir http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#ciphersuites.

Spécification des algorithmes de chiffrement et des protocoles TLS pour Edge 4.16.01 à 4.16.09

Dans Edge 4.16.01 à 4.16.09, vous définissez les algorithmes de chiffrement et les protocoles par défaut pour les hôtes virtuels dans le monde entier sur le routeur. Ces valeurs par défaut s'appliquent ensuite à tous les hôtes virtuels.

Utilisez des jetons pour spécifier les protocoles et les algorithmes de chiffrement par défaut:

Pour spécifier les protocoles par défaut, utilisez le jeton conf_load_balancing_load.balancing.driver.server.ssl.protocols.
Pour spécifier les algorithmes de chiffrement par défaut pour le routeur, utilisez le jeton conf_load_balancing_load.balancing.driver.server.ssl.ciphers.

La valeur par défaut du jeton conf_load_balancing_load.balancing.driver.server.ssl.protocols est:

conf_load_balancing_load.balancing.driver.server.ssl.protocols=TLSv1 TLSv1.1 TLSv1.2

Ce paramètre indique que le routeur est compatible avec les versions 1.0, 1.1 et 1.2 de TLS. Spécifiez un délimitées par des espaces au jeton.

La valeur par défaut du jeton conf_load_balancing_load.balancing.driver.server.ssl.ciphers est:

conf_load_balancing_load.balancing.driver.server.ssl.ciphers=HIGH:!aNULL:!MD5:!DH+3DES:!RSA+3DES

Ce paramètre spécifie:

Clé de 128 bits ou plus requise (HIGH).
Exclure les algorithmes de chiffrement sans authentification (!aNULL)
Exclure les suites de chiffrement à l'aide de MD5 (!MD5)
Exclure les suites de chiffrement à l’aide du DH (y compris le DH anonyme, le DH éphémère et le DH fixe) ET triple DES (!DH+3DES)
Exclure les suites de chiffrement à l’aide de l’échange de clés RSA ET du triple DES (!RSA+3DES)

Pour en savoir plus sur la syntaxe et les valeurs autorisées par ce jeton, consultez la page sur les algorithmes de chiffrement OpenSSL. Notez que ce jeton utilise les noms de chiffrement OpenSSL, tels que AES128-SHA256, et non le Noms des algorithmes de chiffrement Java/JSSE, tels que TLS_RSA_WITH_AES_128_CBC_SHA256.

Pour définir le jeton du routeur:

Modifier /opt/apigee/customer/application/router.properties . Si ce fichier n'existe pas, créez-le.
Définir l'élément conf_load_balancing_load.balancing.driver.server.ssl.ciphers à partir d'un jeton d'accès. Par exemple, pour spécifier uniquement TLSv1.2 et exclure les suites de chiffrement utilisant des clés pré-partagées, add!PSK:
```
conf_load_balancing_load.balancing.driver.server.ssl.protocols=TLSv1.2
conf_load_balancing_load.balancing.driver.server.ssl.ciphers=HIGH:!aNULL:!MD5:!DH+3DES:!RSA+3DES:!PSK
```

Assurez-vous que le fichier router.properties appartient à Apigee:

chown apigee:apigee /opt/apigee/customer/application/router.properties

Redémarrez le routeur Edge:

/opt/apigee/apigee-service/bin/apigee-service edge-router restart

Vérifiez la valeur du jeton:

/opt/apigee/apigee-service/bin/apigee-service edge-router configure -search conf_load_balancing_load.balancing.driver.server.ssl.ciphers

Paramètre Paramètres d'hôte virtuel TLS pour Edge 4.17.01 et versions ultérieures

Si vous utilisez Edge version 4.17.01 ou ultérieure, vous pouvez définir certaines propriétés TLS pour une un hôte virtuel individuel, tel que le protocole et l'algorithme de chiffrement TLS, à l'aide de la balise enfant <Properties> du <VirtualHost> . Ces tags sont décrits dans la documentation de référence sur la propriété d'hôte virtuel.

Exemple :

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>apiTLS.myCompany.com</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>9006</Port>
    <OCSPStapling>off</OCSPStapling>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <KeyStore>ref://myTestKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
    </SSLInfo>
    <Properties>
        <Property name="proxy_read_timeout">50</Property>
        <Property name="keepalive_timeout">300</Property>
        <Property name="proxy_request_buffering">off</Property>
        <Property name="proxy_buffering">off</Property>
        <Property name="ssl_protocols">TLSv1.2 TLSv1.1</Property>
        <Property name="ssl_ciphers">HIGH:!aNULL:!MD5:!DH+3DES:!kEDH</Property>
    </Properties>
</VirtualHost>

Pour en savoir plus sur la syntaxe et les valeurs autorisées par le jeton ssl_ciphers, consultez la page sur les algorithmes de chiffrement OpenSSL. Notez que ce jeton utilise les noms de chiffrement OpenSSL, tels que AES128-SHA256, et non les noms des algorithmes de chiffrement Java/JSSE, tels que TLS_RSA_WITH_AES_128_CBC_SHA256.

Créer un hôte virtuel qui utilise HTTPS

Cet exemple spécifie le keystore pour l'hôte virtuel à l'aide d'une référence. Avec un référence vous permet de modifier le keystore sans avoir à redémarrer les routeurs.

Procédez comme suit pour créer l'hôte virtuel:

Créez et configurez un keystore nommé myTestKeystore à l'aide de la propriété la procédure décrite ici: Keystores et Truststores : Assurez-vous que le keystore utilise un nom d'alias myKeyAlias pour le certificat et la clé privée.

Utilisez l'appel d'API POST suivant pour créer la référence keystoreref vers le keystore que vous avez créé ci-dessus:

curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
  -d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
  </ResourceReference>'
  -u email:password

La référence spécifie le nom du keystore et le type de référence en tant que KeyStore.

Utilisez l'appel d'API GET suivant pour afficher la référence :

curl -X GET https://api.enterprise.apigee.com/v1/o/[org_name}/e/{env_name}/references/keystoreref -u uname:password

Créez l'hôte virtuel en utilisant la fonction Créer un API Virtual Host, où <ms-IP> est l'adresse IP ou le nom de domaine du nœud du serveur de gestion.

Veillez à spécifier la référence du keystore et l'alias de clé appropriés:
```
curl -X POST -H "Content-Type:application/xml" \
  http://<ms-IP>:8080/v1/o/{org_name}/environments/{env_name}/virtualhosts \
  -d '<VirtualHost  name="newTLSTrustStore2">
    <HostAliases>
      <HostAlias>apiTLS.myCompany.com</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>9005</Port>
    <OCSPStapling>off</OCSPStapling>
    <SSLInfo>
      <Enabled>true</Enabled>
      <ClientAuthEnabled>false</ClientAuthEnabled>
      <KeyStore>ref://keystoreref</KeyStore>
      <KeyAlias>myKeyAlias</KeyAlias>
    </SSLInfo>
  </VirtualHost>' \
  -u email:password
```
Remarque : Si vous exécutez le protocole TLS bidirectionnel avec le client, Définissez ensuite <ClientAuthEnabled> sur true et spécifiez le truststore à l'aide de l'élément <TrustStore>. La client doit être correctement configuré pour TLS bidirectionnel, ce qui signifie que Edge dispose d’un Truststore contenant le certificat et la chaîne de certificats du client. Créez le Truststore à l'aide de la procédure décrits ici: Keystores et Magasins de confiance :
Créez pour l'hôte virtuel un enregistrement DNS correspondant à l'alias d'hôte.
Si vous disposez de proxys d'API existants, ajoutez l'hôte virtuel à l'élément <HTTPConnection> dans le ProxyEndpoint L'hôte virtuel est ajouté automatiquement à tous les nouveaux proxys d'API.

Consultez la section Mettre à jour un proxy d'API après la création d'un hôte virtuel dans À propos des hôtes virtuels

Avertissement:Tous les hôtes virtuels sont automatiquement ajoutés Proxys d'API Par conséquent, si vous créez un proxy d'API qui ne doit pas être accessible via un un hôte virtuel particulier, vous devez modifier le proxy d'API pour supprimer cet hôte virtuel son ProxyEndpoint.

Après avoir mis à jour un proxy d'API pour utiliser l'hôte virtuel et créé l'enregistrement DNS pour l'hôte vous pouvez accéder au proxy d'API comme indiqué ci-dessous:

https://apiTLS.myCompany.com/v1/{project-base-path}/{resource-path}

Exemple :

https://apiTLS.myCompany.com/v1/weather/forecastrss?w=12797282

Créer et modifier des références à un keystore ou à un Truststore

Vous pouvez éventuellement configurer l'hôte virtuel pour qu'il utilise une référence au keystore ou « Truststore ». L'avantage d'utiliser une référence est que vous pouvez la mettre à jour pointer vers un autre keystore ou un autre Truststore pour mettre à jour le certificat TLS sans avoir à redémarrer sur un routeur Cloud Router.

L'exemple ci-dessous montre un hôte virtuel qui utilise une référence au keystore:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>apiTLS.myCompany.com</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>9006</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <KeyStore>ref://keystoreref</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
    </SSLInfo>
</VirtualHost>

Utilisez l'appel d'API POST suivant pour créer la référence nommée keystoreref:

curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
  -d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
  </ResourceReference>'
  -u email:password

La référence spécifie le nom du magasin de clés et son type.

Utilisez l'appel d'API GET suivant pour afficher la référence :

curl -X GET https://api.enterprise.apigee.com/v1/o/[org_name}/e/{env_name}/references/keystoreref -u uname:password

Pour modifier ultérieurement la référence afin qu'elle pointe vers un magasin de clés différent, assurez-vous que l'alias porte le même nom, utilisez l'appel PUT suivant :

curl -X PUT -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references/keystoreref \
  -d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
  </ResourceReference>'
  -u email:password