Gängige OIDs für Verwendungszwecke (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. Viele Verifizierer werten eine EKU in einem Zwischenzertifikat als Einschränkung für alles darunter; so halten Root-Programme die Hierarchien für TLS, S/MIME und Codesignatur getrennt.
Öffentliches TLS geht zu Hierarchien mit nur einem Zweck über. Die Chrome Root Program Policy (Version 1.8) verlangt, dass Subscriber-Zertifikate, die ab dem 15. März 2027 ausgestellt werden, nur noch id-kp-serverAuth ausweisen, und für untergeordnete CAs, die ab dem 15. Juni 2026 offengelegt werden, gilt dasselbe; große CAs haben 2026 aufgehört, clientAuth in TLS-Zertifikate aufzunehmen. Dienste, die öffentliche TLS-Zertifikate als Client-Zertifikate für mTLS genutzt haben, brauchen eine private CA.
Eine fehlende oder falsche EKU führt zu Fehlern wie x509: certificate specifies an incompatible key usage in Go oder unsupported certificate purpose in OpenSSL.