[17/03/2025] Problème environnement Atos
Mise à jour du 28 mars 2025
Problème résolu
Nous avons résolu notre problème et pouvons accéder de nouveau à dev1 en authentification par carte CPS. La signature que nous générions n’était pas validée par openSSL3.
Les versions corrigées sont :
- Les versions 5.21.0 et supérieures
- Les versions 6.1.2 et supérieures
Pour le détail de la résolution :
OpenSSL 1.x (utilisé dans les anciens environnements) était plus tolérant sur l’absence du parametre optionnel NULL dans l’encodage ASN.1 des AlgorithmIdentifier. Mais depuis OpenSSL 3.x, la validation est devenue plus stricte, respectant pleinement RFC 5280 et RFC 4055, qui imposent la présence explicite de NULL :
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY OPTIONAL
}
L’absence de ce paramètre NULL générait un décalage de deux octets de la séquence à signer par la cryptolib. On peut regretter le message d’erreur d’openssl qui est loin d’être explicite :
342F0100:error:02000068:rsa routines:ossl_rsa_verify:bad signature:../openssl-3.2.1/crypto/rsa/rsa_sign.c:426:
342F0100:error:1C880004:Provider routines:rsa_verify:RSA lib:../openssl-3.2.1/providers/implementations/signature/rsa_sig.c:785:
Notre correction :
Problème rencontré le 17 mars 2025
Le nouvel environnement de dev d’ATOS, a été mis à disposition ce 17 mars 2025.
Ce nouvel environnement bloque toutes les connexions TLS de la devbox-santé avec les cartes CPS, Vous ne pouvez donc pas utiliser de cartes CPS sur cet environnement :
Je vous invite vivement à faire des tests de votre côté et de remonter le problème au centre de services, car apparemment nous ne sommes pas écoutés
Pour information supplémentaire, nous avions eu un problème similaire avec l’opérateur mailiz qui avait fini par corriger le problème suite à la plainte d’un autre éditeur
