Распространённые OID назначений (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. Многие реализации проверки рассматривают EKU в промежуточном сертификате как ограничение для всего, что ниже него в цепочке; так корневые программы (root programs) разделяют иерархии TLS, S/MIME и подписи кода.
Публичная PKI для TLS переходит к иерархиям с единственным назначением. Политика Chrome Root Program (версия 1.8) требует, чтобы сертификаты абонентов, выпущенные 15 марта 2027 года и позже, содержали только id-kp-serverAuth; то же касается подчинённых CA, раскрытых начиная с 15 июня 2026 года. Крупные CA перестали добавлять clientAuth в TLS-сертификаты в 2026 году. Сервисам, которые использовали публичные TLS-сертификаты как клиентские сертификаты mTLS, нужен частный CA.
Если EKU отсутствует или указан неверно, возникают ошибки вроде x509: certificate specifies an incompatible key usage в Go или unsupported certificate purpose в OpenSSL.