Pendant la période de transition, on contacte des serveurs avec l'un ou l'autre des certificats, mais pas les deux. On peut pas utiliser l'ancien.
En apparence, les deux phrases se contredisent ; mais je comprends ce que tu entends par là : une partie des instances présentent l'ancien une autre le nouveau.
Si il est toujours possible de présenter l'ancien, on peux utiliser la méthode que je décris précédemment : utilisation de l'ancien certificat pendant le premier handshake puis, après l'établissement du canal sécurisé, demande de renégociation [1] en présentant un nouveau certificat.
Par contre, la fausse alerte apparaît s'il n'est, réellement, plus possible de présenter l'ancien (typiquement par perte de la clé privée) et qu'il n'est pas encore révoqué par la CA.
De plus, cette solution souffre du problème dont je parle précédemment puisque le serveur doit être configuré de manière à permettre l'épinglage.
[^] # Re: Politique de confiance client
Posté par ealprr . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à 0. Dernière modification le 19 avril 2015 à 17:12.
En apparence, les deux phrases se contredisent ; mais je comprends ce que tu entends par là : une partie des instances présentent l'ancien une autre le nouveau.
Si il est toujours possible de présenter l'ancien, on peux utiliser la méthode que je décris précédemment : utilisation de l'ancien certificat pendant le premier handshake puis, après l'établissement du canal sécurisé, demande de renégociation [1] en présentant un nouveau certificat.
Par contre, la fausse alerte apparaît s'il n'est, réellement, plus possible de présenter l'ancien (typiquement par perte de la clé privée) et qu'il n'est pas encore révoqué par la CA.
De plus, cette solution souffre du problème dont je parle précédemment puisque le serveur doit être configuré de manière à permettre l'épinglage.
[1]: rfc5246 section-7.4.1.1 The HelloRequest message MAY be sent by the server at any time.