Les certificats intermédiaires portent basicConstraints avec cA à true, souvent une pathLenConstraint, l’utilisation de la clé keyCertSign et cRLSign et, selon les règles actuelles des programmes de certificats racines, des utilisations étendues de la clé qui les restreignent à un seul usage. Le programme de certificats racines de Chrome, par exemple, exige que les nouvelles AC subordonnées utilisées pour TLS ne déclarent que id-kp-serverAuth.
Comme c’est le serveur qui doit les envoyer, les certificats intermédiaires sont la pièce le plus souvent manquante d’un déploiement TLS. Ils changent plus souvent que les racines : Let’s Encrypt a remplacé ses intermédiaires R10–R14 et E5–E9 par les séries YR et YE en 2026, et un serveur dont l’ancienne chaîne est codée en dur sert alors une chaîne incorrecte.
La compromission ou l’émission erronée d’un certificat intermédiaire se traite en le révoquant dans la CRL de son parent et par des listes de blocage diffusées par les navigateurs (OneCRL de Mozilla, CRLSets de Chrome), ce qui est plus rapide que d’attendre que chaque client télécharge les CRL.