OIDs de finalidade comuns (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. Muitos verificadores tratam um EKU em um certificado intermediário como uma restrição para tudo o que está abaixo dele, e é assim que os programas de certificados raiz mantêm separadas as hierarquias de TLS, S/MIME e assinatura de código.
O TLS público está migrando para hierarquias de finalidade única. A política do Chrome Root Program (versão 1.8) exige que os certificados de assinante emitidos a partir de 15 de março de 2027 declarem apenas id-kp-serverAuth, e o mesmo vale para as CAs subordinadas divulgadas a partir de 15 de junho de 2026; as principais CAs deixaram de incluir clientAuth nos certificados TLS em 2026. Os serviços que usavam certificados TLS públicos como certificados de cliente mTLS precisam de uma CA privada.
Um EKU ausente ou errado gera erros como x509: certificate specifies an incompatible key usage, do Go, ou unsupported certificate purpose, do OpenSSL.