Echecs mTLS Envoy avec CRYPTOLIB_invalid_signature en rotation de certifs

ton erreur sent le mismatch entre la clé privée et le certificat qui sont streamés par sds vers envoy

j'ai dump la config de l'endpoint qui fail et tout a l'air cohérent au niveau du hash

istioctl pc secret my-pod-name -o json

vérifie la chaîne intermédiaire dans ton bundle vault si il manque un cran dans la hiérarchie envoy peut pas valider la signature de l'autre côté

lance un openssl s_client sur le port du sidecar pour voir ce qu'il présente réellement pendant le handshake

j'ai fait le test et voilà le résultat ça pique les yeux

depth=0 CN = my-service.default.svc.cluster.local
verify error:num=20:unable to get local issuer certificate

c'est ce que je craignais ton agent de rotation n'envoie que le leaf certificate sans la chaîne complète

tu utilises quelle version du vault-agent-injector parce que les vieilles versions géraient mal le bundle fullchain

on est en 0.25.0 et on utilise le template standard pour injecter les certifs dans les volumes partagés

montre ton template vault pour voir comment tu récupères les données de l'api

voici le bout de code incriminé

{{ with secret "pki/issue/my-role" "common_name=my-service" }}
{{ .Data.certificate }}
{{ end }}

tu récupères juste .Data.certificate donc tu n'as pas l'intermediate ca c'est pour ça que la validation mtls explose

il faut utiliser .Data.issuing_ca ou alors concaténer les deux pour avoir la full chain exploitable par envoy

si je concatène comme ça ça devrait suffire non

{{ .Data.certificate }}
{{ .Data.issuing_ca }}

oui exactement mais fais attention à l'ordre sinon la lib ssl va encore râler sur le format du pem

test direct en redémarrant un pod après avoir mis à jour ta configmap de template vault et vérifie avec istioctl proxy-status

ça fonctionne enfin les handshakes passent tous et l'erreur a disparu des logs envoy

merci les gars je vais aller corriger tous nos templates avant que la prochaine rotation globale ne casse tout le reste