OID de finalité courants (RFC 5280 §4.2.1.12) : 1.3.6.1.5.5.7.3.1 serverAuth, …3.2 clientAuth, …3.3 codeSigning, …3.4 emailProtection, …3.8 timeStamping, …3.9 OCSPSigning. De nombreux vérificateurs traitent une EKU présente dans un certificat intermédiaire comme une contrainte sur tout ce qui se trouve en dessous : c’est ainsi que les programmes de certificats racines maintiennent séparées les hiérarchies TLS, S/MIME et de signature de code.
Le TLS public évolue vers des hiérarchies à usage unique. La politique du Chrome Root Program (version 1.8) exige que les certificats d’abonné émis à partir du 15 mars 2027 n’indiquent que id-kp-serverAuth, et il en va de même pour les AC subordonnées déclarées à partir du 15 juin 2026 ; les grandes AC ont cessé d’ajouter clientAuth aux certificats TLS en 2026. Les services qui utilisaient des certificats TLS publics comme certificats client mTLS ont besoin d’une AC privée.
Une EKU absente ou incorrecte provoque des erreurs comme x509: certificate specifies an incompatible key usage de Go ou unsupported certificate purpose d’OpenSSL.