Termes et concepts

Les termes et les concepts suivants peuvent vous aider lorsque vous utilisez AWS Private Certificate Authority (Autorité de certification privée AWS).

Approbation

Pour permettre à un navigateur Web d'approuver l'identité d'un site Web, le navigateur doit être en mesure de vérifier le certificat de ce site. Toutefois, les navigateurs n'approuvent qu'un petit nombre de certificats appelés certificats d'autorité de certification racine. Un tiers de confiance, appelé autorité de certification (CA), valide l'identité du site Web et émet un certificat numérique signé pour l'opérateur du site Web. Le navigateur peut ensuite vérifier la signature numérique afin de valider l'identité du site Web. Si la validation aboutit, le navigateur affiche une icône de verrouillage dans la barre d'adresse.

Certificats de serveur TLS

Les transactions HTTPS requièrent des certificats de serveur pour authentifier un serveur. Un certificat de serveur est une structure de données X.509 v3 qui lie la clé publique figurant dans le certificat à l'objet du certificat. Un certificat TLS est signé par une autorité de certification (CA). Il contient le nom du serveur, la période de validité, la clé publique l'algorithme de signature, ainsi que d'autres données.

Signature du certificat

Une signature numérique est un hachage chiffré sur un certificat. Une signature est utilisée pour confirmer l'intégrité des données du certificat. Votre autorité de certification privée crée une signature à l'aide d'une fonction de hachage de chiffrement telle que SHA256 sur le contenu du certificat de taille variable. Cette fonction de hachage produit une chaîne de données de taille fixe qu'il n'est, de fait, pas possible de falsifier. Cette chaîne est appelée un hachage. L'autorité de certification chiffre ensuite la valeur de hachage avec sa clé privée et concatène le hachage chiffré avec le certificat.

Autorité de certification

Une autorité de certification émet et, si nécessaire, révoque des certificats numériques. Le type le plus courant de certificat repose sur la norme ISO X.509. Un certificat X.509 confirme l'identité de l'objet du certificat et lie cette identité à une clé publique. L'objet peut être un utilisateur, une application, un ordinateur ou un autre appareil. L'autorité de certification signe un certificat en hachant le contenu, puis en chiffrant le hachage avec la clé privée associée à la clé publique du certificat. Une application cliente, par exemple un navigateur web qui doit confirmer l'identité d'un objet, utilise la clé publique pour déchiffrer la signature du certificat. Ensuite, elle hache le contenu du certificat et compare la valeur hachée à la signature déchiffrée pour déterminer si elles correspondent. Pour plus d'informations sur la signature des certificats, consultez Signature du certificat.

Vous pouvez utiliser Autorité de certification privée AWS pour créer une autorité de certification privée et utiliser l'autorité de certification privée pour émettre des certificats. Votre autorité de certification privée émet uniquement des certificats SSL/TLS privés à utiliser au sein de votre organisation. Pour plus d’informations, consultez Certificat privé. Votre autorité de certification privée nécessite également un certificat avant que vous puissiez l'utiliser. Pour plus d’informations, consultez Certificat CA.

Root CA

Bloc de construction cryptographique et source de confiance à parti desquels des certificats peuvent être émis. Elle est composée d'une clé privée pour la signature (émission) de certificats et d'un certificat racine qui identifie l'autorité de certification racine et lie la clé privée au nom de l'autorité de certification. Le certificat racine est distribué aux magasins de confiance de chaque entité d'un environnement. Les administrateurs construisent des magasins d'approbation pour inclure uniquement les autorités de certification qu'ils approuvent. Les administrateurs mettent à jour ou intègrent les magasins de confiance dans les systèmes d'exploitation, les instances et les images des machines hôtes des entités de leur environnement. Lorsque des ressources tentent de se connecter les unes aux autres, elles vérifient les certificats que présente chaque entité. Un client vérifie la validité des certificats et vérifie si une chaîne existe du certificat vers un certificat racine installé dans le magasin d'approbation. Si ces conditions sont remplies, une « poignée de main » est établie entre les ressources. Cette liaison prouve à l'aide d'un chiffrement l'identité de chaque entité à l'autre et crée un canal de communication chiffré (TLS/SSL) entre elles.

Certificat CA

Le certificat d'une autorité de certification confirme l'identité de l'autorité de certification et la lie à la clé publique figurant dans le certificat.

Vous pouvez utiliser Autorité de certification privée AWS pour créer une autorité de certification racine privée ou une autorité de certification subordonnée privée, chacune basée sur un certificat d'une autorité de certification. Les certificats d'une autorité de certification subordonnée sont signés par un autre certificat d'une autorité de certification supérieur dans une chaîne de confiance. Cependant, le certificat est auto-signé pour les autorités de certification racines. Vous pouvez également établir une autorité racine externe (hébergée sur site, par exemple). Vous pouvez ensuite utiliser votre autorité racine pour signer un certificat d'une autorité de certification racine subordonnée hébergé par Autorité de certification privée AWS.

L'exemple suivant montre les champs classiques que comporte un certificat d'une autorité de certification X.509 Autorité de certification privée AWS. Notez que pour le certificat d'une autorité de certification, la valeur CA: du champ Basic Constraints est définie sur TRUE.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4121 (0x1019)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=Washington, L=Seattle, O=Example Company Root CA, OU=Corp, CN=www.example.com/emailAddress=[e-mail]
        Validity
            Not Before: Feb 26 20:27:56 2018 GMT
            Not After : Feb 24 20:27:56 2028 GMT
        Subject: C=US, ST=WA, L=Seattle, O=Examples Company Subordinate CA, OU=Corporate Office, CN=www.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:c0: ... a3:4a:51
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                F8:84:EE:37:21:F2:5E:0B:6C:40:C2:9D:C6:FE:7E:49:53:67:34:D9
            X509v3 Authority Key Identifier:
                keyid:0D:CE:76:F2:E3:3B:93:2D:36:05:41:41:16:36:C8:82:BC:CB:F8:A0

            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: critical
                Digital Signature, CRL Sign
    Signature Algorithm: sha256WithRSAEncryption
         6:bb:94: ... 80:d8

Certificat racine de l'autorité de certification

Une autorité de certification (CA) existe généralement au sein d'une structure hiérarchique qui contient plusieurs autres autorités de certification avec des relations parent—enfant clairement définies entre elles. Les autorités de certification subordonnées sont certifiées par leurs autorités de certification parent, ce qui crée une chaîne de certificats. L'autorité de certification située en haut de la hiérarchie est appelée l'autorité de certification racine, et son certificat est appelé le certificat racine. En général, ce certificat est auto-signé.

Certificat d'entité finale

Un certificat d'entité finale identifie une ressource, telle qu'un serveur, une instance, un conteneur ou un appareil. Contrairement aux certificats CA, les certificats d'entité finale ne peuvent pas être utilisés pour émettre des certificats. Les autres termes courants pour désigner le certificat d'entité finale sont le certificat « client » ou le certificat « feuille ».

Certificats auto-signés

Certificat signé par l'émetteur au lieu d'une autorité de certification supérieure. Contrairement aux certificats émis à partir d'une racine sécurisée gérée par une autorité de certification, les certificats auto-signés agissent comme leur propre racine et présentent donc des limites importantes : ils peuvent être utilisés pour fournir un chiffrement filaire mais pas pour vérifier l'identité, et ils ne peuvent pas être révoqués. Du point de vue de la sécurité, ils ne sont pas acceptables. Cependant, les organisations les utilisent quand même, car ils sont faciles à générer, qu'ils ne nécessitent aucune expertise ni infrastructure, et que de nombreuses applications les acceptent. Aucun contrôle n'est en place pour l'émission de certificats auto-signés. Les organisations qui les utilisent encourent de plus grands risques de panne étant donné qu'elles n'ont aucun moyen d'effectuer le suivi des dates d'expiration des certificats.

Certificat privé

Autorité de certification privée AWSles certificats sont des certificats SSL/TLS privés que vous pouvez utiliser au sein de votre organisation, mais qui ne sont pas fiables sur l'Internet public. Utilisez-les pour identifier les ressources telles que les clients, les serveurs, les applications, les services, les appareils et les utilisateurs. Lorsque vous établissez un canal de communication chiffré sécurisé, chaque ressource utilise un certificat similaire à l'exemple suivant, ainsi que des techniques cryptographiques pour prouver son identité à une autre ressource. Les points de terminaison des API internes, les serveurs web, les utilisateurs VPN, les appareils IoT et de nombreuses autres applications utilisent des certificats privés pour établir des canaux de communication chiffrés nécessaires pour fonctionner en toute sécurité. Par défaut, les certificats privés ne sont pas approuvés publiquement. Un administrateur interne doit explicitement configurer des applications pour approuver les certificats privés et distribuer les certificats.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            e8:cb:d2:be:db:12:23:29:f9:77:06:bc:fe:c9:90:f8
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, ST=WA, L=Seattle, O=Example Company CA, OU=Corporate, CN=www.example.com
        Validity
            Not Before: Feb 26 18:39:57 2018 GMT
            Not After : Feb 26 19:39:57 2019 GMT
        Subject: C=US, ST=Washington, L=Seattle, O=Example Company, OU=Sales, CN=www.example.com/emailAddress=[e-mail]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00...c7
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Authority Key Identifier:
                keyid:AA:6E:C1:8A:EC:2F:8F:21:BC:BE:80:3D:C5:65:93:79:99:E7:71:65

            X509v3 Subject Key Identifier:
                C6:6B:3C:6F:0A:49:9E:CC:4B:80:B2:8A:AB:81:22:AB:89:A8:DA:19
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://NA/crl/12345678-1234-1234-1234-123456789012.crl

    Signature Algorithm: sha256WithRSAEncryption
         58:32:...:53

Chemin du certificat

Un client qui s'appuie sur un certificat valide l'existence d'un chemin entre le certificat d'entité finale, éventuellement via une chaîne de certificats intermédiaires, et une racine fiable. Le client vérifie que chaque certificat le long du chemin est valide (non révoqué). Il vérifie également que le certificat d'entité finale n'a pas expiré, qu'il est intègre (qu'il n'a pas été falsifié ou modifié) et que les contraintes du certificat sont appliquées.

Contrainte de longueur de chemin

Les contraintes de base pathLenConstraintd'un certificat CA définissent le nombre de certificats CA subordonnés qui peuvent exister dans la chaîne située en dessous. Par exemple, un certificat CA avec une contrainte de longueur de chemin de zéro ne peut pas avoir d'autorité de certification subordonnée. Une autorité de certification avec une valeur un pour la contrainte de longueur de chemin peut avoir jusqu'à un niveau d'autorités de certification subordonnées sous elle. La RFC 5280 définit cela comme « le nombre maximum de certificats non-self-issued intermédiaires qui peuvent suivre ce certificat dans un chemin de certification valide ». La valeur de longueur du chemin exclut le certificat d'entité finale, bien que le langage informel concernant la « longueur » ou la « profondeur » d'une chaîne de validation puisse l'inclure... ce qui prête à confusion.