À voir ces exemples, j'en déduis que le max-age n'est pas géré dynamiquement à l'approche de l'expiration du certificat : si on a pris par exemple la valeur suggérée par la RFC de 60 jours pour le max-age, pendant les deux mois précédant l'expiration du certificat, on continue à annoncer un épinglage sur 60 jours. Le jour de l'expiration :
soit on n'a rien fait, le certificat est invalide et le client ne se posera même pas la question de l'épinglage
soit le certificat a été renouvelé (y compris en avance pendant les 60j avant l'expiration) et dans ce cas là tout dépend du fait que l'on ait changé ou non d'autorité de certification :
si on a gardé la même autorité que celle précédemment annoncée dans l'épinglage, tout va bien se passer
si on a changé d'autorité, alors le client va râler sur l'épinglage.
Bref ça nécessite d'anticiper un peu les changements d'autorité.
# Configuration du serveur web et anticipation du changement d'autorité
Posté par Benoît Sibaud (site web personnel) . En réponse au journal Public Key Pinning Extension for HTTP. Évalué à 3.
Des exemples de configuration Lighttpd, Apache httpd et Nginx sur https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html
À voir ces exemples, j'en déduis que le max-age n'est pas géré dynamiquement à l'approche de l'expiration du certificat : si on a pris par exemple la valeur suggérée par la RFC de 60 jours pour le max-age, pendant les deux mois précédant l'expiration du certificat, on continue à annoncer un épinglage sur 60 jours. Le jour de l'expiration :
Bref ça nécessite d'anticiper un peu les changements d'autorité.