View a markdown version of this page

Problèmes connus liés au fournisseur OpenSSL pour AWS CloudHSM - AWS CloudHSM
Problème : erreurs dans l'interface de ligne de commande OpenSSL lors de l'utilisation avec le fournisseur OpenSSLProblème : Ed25519 et le déchargement ML-DSA TLS ne sont pas pris en charge sur les clusters FIPSProblème : ML-DSA les opérations échouent sur les plateformes avec OpenSSL antérieur à 3.5Problème : échec de la ML-DSA prise de contact TLS sur Amazon Linux 2023 et RHEL avec « aucun algorithme de signature partagé »

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Problèmes connus liés au fournisseur OpenSSL pour AWS CloudHSM

Voici les problèmes connus liés au fournisseur OpenSSL pour. AWS CloudHSM

Problème : erreurs dans l'interface de ligne de commande OpenSSL lors de l'utilisation avec le fournisseur OpenSSL

  • Conséquence : le fournisseur AWS CloudHSM OpenSSL ne prenait pas en charge les opérations de la CLI OpenSSL (création de CSR, signature de certificats). Vous deviez utiliser le moteur dynamique OpenSSL pour les opérations de CSR et de certification.

  • État de la résolution : le SDK client 5.18.0 résout ce problème. Le fournisseur OpenSSL prend désormais en charge les opérations de la CLI OpenSSL pour tous les types de clés (RSA, EC, Ed25519 et). ML-DSA Passez à la version 5.18.0 ou ultérieure pour bénéficier du correctif.

Problème : Ed25519 et le déchargement ML-DSA TLS ne sont pas pris en charge sur les clusters FIPS

  • Conséquence : Ed25519 et les types de ML-DSA clés ne sont pas disponibles sur les clusters. FIPS-mode Les tentatives d'utilisation de ces types de clés pour le déchargement TLS sur un cluster FIPS échouent.

  • Résolution : utilisez Ed25519 et ML-DSA uniquement sur les clusters non FIPS. Pour les clusters FIPS, utilisez les types de clés RSA ou EC pour le déchargement TLS.

Problème : ML-DSA les opérations échouent sur les plateformes avec OpenSSL antérieur à 3.5

  • Conséquence : les types de ML-DSA clés (ML-DSA-44, ML-DSA-65, ML-DSA-87) nécessitent OpenSSL 3.5 ou une version ultérieure pour la création de CSR, la création de certificats et le déchargement du protocole TLS. Sur les plates-formes dotées d'un ancien système OpenSSL, les ML-DSA opérations échouent avec une erreur « algorithme non pris en charge ».

  • Résolution : utilisez une plate-forme avec OpenSSL 3.5 ou version ultérieure, ou créez un binaire OpenSSL 3.5+ personnalisé pour les opérations. ML-DSA

Problème : échec de la ML-DSA prise de contact TLS sur Amazon Linux 2023 et RHEL avec « aucun algorithme de signature partagé »

  • Conséquence : les connexions TLS utilisant ML-DSA des certificats échouent sur les plateformes Amazon Linux 2023, RHEL 9 et RHEL 10 avec cette erreur. tls1_set_server_sigalgs:no shared signature algorithms Cela est dû au fait que le cadre des politiques de chiffrement à l'échelle du système n'inclut pas d'algorithmes de ML-DSA signature (mldsa44,mldsa65,mldsa87) dans la liste d'autorisation par défaut. SignatureAlgorithms Non-TLS les opérations (génération de clés, signature, vérification) ne sont pas affectées. Ubuntu 26.04 LTS n'est pas concerné car il n'utilise pas le framework de politiques de chiffrement.

  • Résolution : Activez la sous-politique de cryptographie post-quantique (PQ) sur votre plateforme :

    • Amazon Linux 2023 (nécessite AL2023.12 +) : Exécutezsudo update-crypto-policies --set DEFAULT:PQ. Pour plus d'informations, consultez les politiques de Post-quantum cryptographie dans le guide de l'utilisateur Amazon Linux 2023.

    • RHEL 9 (nécessite RHEL 9.8+) : Exécutez, puis. sudo dnf update crypto-policies sudo update-crypto-policies --set DEFAULT:PQ Pour plus d'informations, consultez la section Utilisation de politiques cryptographiques à l'échelle du système dans la documentation RHEL 9.

    • RHEL 10 (nécessite RHEL 10.1+) : ML-DSA est automatiquement activé dans la politique. DEFAULT Exécutez sudo dnf update pour vous assurer que vous disposez du dernier package de politiques de cryptographie. Pour plus d'informations, consultez la section Utilisation de politiques cryptographiques à l'échelle du système dans la documentation RHEL 10.