OID de propósito habituales (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. Muchos verificadores tratan un EKU en un certificado intermedio como una restricción para todo lo que está por debajo, y así los programas raíz mantienen separadas las jerarquías de TLS, S/MIME y firma de código.
El TLS público avanza hacia jerarquías de un solo propósito. La política del programa raíz de Chrome (versión 1.8) exige que los certificados de suscriptor emitidos a partir del 15 de marzo de 2027 declaren solo id-kp-serverAuth, y lo mismo para las CA subordinadas comunicadas desde el 15 de junio de 2026; las principales CA dejaron de añadir clientAuth a los certificados TLS en 2026. Los servicios que usaban certificados TLS públicos como certificados de cliente mTLS necesitan una CA privada.
Un EKU ausente o incorrecto produce errores como x509: certificate specifies an incompatible key usage en Go o unsupported certificate purpose en OpenSSL.